Umfragen | | | | |  | So, zweiter Versuch:
...bis in einige Versionen von Windows2000/XP hinein scheint es ohne weiteres möglich zu sein, sich als User mit eingeschräkten Rechten oder als Gast in einen Rechner einzulogen und dann seinem eigenen Account Administrationsrechte zu geben und so das komplette Sicherheitssystem unbrauchbar zu machen.
Das Tool [...]  bietet eine sehr gute Möglichkeit, zu testen ob dies bei der eigenen Windowsversion möglich ist.
1.) Tasks and Token starten.
2.) Auf Prozesse, Threads und DLLs klicken
3.) Auf den Tasks and Token Prozess klicken.
4.) Doppelklick auf den Tasks and Token Prozess.
5.) Auf den ersten Thread von Tasks and Token klicken.
6. ) Doppelklick auf den ersten Thread von Tasks and Token.
7.) Irgenein Fenster unter diesem Thread auswählen.
8.) Rechtsklick in Treeview und Message senden auswählen.
9.) Im Fenster, das dann erscheint, den Button Message senden anklicken.
Ist dann eine Messagebox zu sehen? Bei denen, die keine Messagebox sehen, bitte Servicepack und Windowsversion posten! |
| | | | | | |
| |  | | Keine MSGBox, im mom mit XPPro SP2 unterwegs... |
| | | | | | |
| | | | SP 2 ist (im Augenblick noch) sicher. Besten Dank. |
| | | | | | |
| | | Meine Tests im Augenblick:
XP Pro ohne SP => nicht sicher.
XP Pro mit SP 1 => nicht sicher.
XP Home ohne SP => nicht sicher.
Windows 2000 SP 2 => nicht sicher.
Besonders Interesse habe ich im Augenblick an Windows2000 |
| | | | | | |
| | | | Windows2000 SP 4 => keine Messagebox. |
| | | | | | |
| | | Das werde ich noch mal brauchen, deswegen schreibe ichs hier hin:
[quote:bdd8486fa2]
Shatter-proofing Windows
Tyler Close, Alan H. Karp, Marc Stiegler
Mobile and Media Systems Laboratory
HP Laboratories Palo Alto
HPL-2005-87
May 9, 2005*
Microsoft
Windows security,
Shatter attack
The Shatter attack uses the Windows API to subvert processes running
with greater privilege than the attack code. The author of the Shatter code
has made strong claims about the difficulty of fixing the underlying
problem, while Microsoft has, with one exception, claimed that the attack
isnt a problem at all. Whether or not Shatter is indeed an exploit worth
worrying about, it uses a feature of Windows that has other malicious
uses, such as keystroke logging. This paper presents a means of defeating
this entire family of attacks with minimal breaking of applications and
effect on the look and feel of the user interface.
* Internal Accession Date Only
Approved for External Publication
© Copyright 2005 Hewlett-Packard Development Company, L.P.
Page 2
1
Shatter-proofing Windows
Tyler Close, Alan H. Karp, Marc Stiegler
Hewlett-Packard Laboratories
Palo Alto, California
Abstract
The Shatter attack uses the Windows API to subvert processes running with greater
privilege than the attack code. The author of the Shatter code has made strong claims
about the difficulty of fixing the underlying problem, while Microsoft has, with one
exception, claimed that the attack isn’t a problem at all. Whether or not Shatter is indeed
an exploit worth worrying about, it uses a feature of Windows that has other malicious
uses, such as keystroke logging. This paper presents a means of defeating this entire
family of attacks with minimal breaking of applications and effect on the look and feel of
the user interface.
1. Introduction
Shatter [1], so called because it “breaks” Windows, uses the Windows API to send
messages to windows associated with processes that have greater authority than the
process running the attacker’s code. In the example exploits, the target is a system
service that has a window on the interactive desktop. The attack uses Windows messages
to remove the length restrictions on an input field in the target window and insert code
into the service’s address space. The final step sends a WM_TIMER message that
induces the service to branch to the exploit.
Microsoft initially denied that the attack exploits an architectural flaw in Windows [2],
citing three points:
• Privileged services should not have windows on the interactive desktop.
• Shatter requires that the attacker be able to log onto the system.
• No privileges are gained on the domain.
That note also states that “all services within the interactive desktop are peers”, which
implies that processes with different privilege levels should not be placed on the same
desktop. Microsoft also notes that it has long recommended that processes with system
privileges not have windows on the visible desktop. A response [4] points out that
several services, some supplied by Microsoft, violate this rule.
Microsoft’s second and third points appear disingenuous. Logging onto the system is not
the most common way for attackers to run code. Viruses, worms, and ActiveX controls
on web pages are far easier methods than finding passwords. Also, not exposing the
domain to attack will be small comfort to users who have had all their local files
corrupted.
Page 3
2
Microsoft later released a security bulletin [3] that fixed the WM_TIMER flaw. This
message informs the application that a kernel timer event has occurred and tells the
application what address to jump to. The flaw was that the application did not check this
address. Hence, once the exploit code was installed in the target application’s address
space, a WM_TIMER message would cause that code to be executed. The fix added a
check to see if the address specified in the WM_TIMER message was registered as a call-
back before taking the branch. The author of Shatter agreed that this fix largely blocked
the attack [4], but claimed that this patch didn’t totally solve the problem. A later paper
[5] demonstrated that other Windows messages, such as EM_SETWORDBREAKPROC,
can also be used in Shatter-like attacks.
The paper reporting Shatter makes several strong claims about the difficulty of making
changes to prevent the attack from succeeding. The suggested solutions all break
applications or change the behavior of the system. “Basically, there is no simple
solution.” summarizes the author’s opinion.
We have found a feature in the Windows API that defeats Shatter while having minimal
impact on application behavior or the user’s interaction with the system. First, this paper
describes how Windows is structured in Section 2. Next, Section 3 describes several
rejected approaches to defeating Shatter. Our proposed solution and the tests showing
that it works are presented in Section 4.
2. Windows Structure
Most people are aware that every window appears on a desktop. Fewer people know that
there may be multiple desktops. For example, the login window appears on a dedicated
desktop. Even fewer know that every desktop is assigned to a window station [8].
Understanding Microsoft’s response to Shatter [8] and our approach to defeating it
requires knowledge of the interaction among these structures.
The user interface component of Windows consists of a number of parts. One is the
windows station [7], which is a securable object containing a clipboard, one or more
desktop objects, and some other state accessible to objects in the window station. Each
logon session is associated with a window station. A desktop is a securable object
attached to a windows station that holds UI objects, such as windows, menus, and hooks.
Note that windows are not securable objects in the Windows API.
Only one window station, called Winsta0, can interact with the user display, keyboard,
and mouse, except on the Terminal Services version of the operating system where each
session has such a window station. Only one desktop at a time can interact with the user,
and that desktop must necessarily be associated with Winsta0. Every process is
associated with a window station, and every thread is associated with a desktop. Threads
can move between desktops, and processes can move between window stations, but
windows are tied to the window station where they started.
Page 4
3
3. Rejected Options
We considered a number of approaches to defeat Shatter. In addition to merely blocking
Shatter, we felt that we also had to maintain the system’s usability. After all, we’d get no
security if nobody used our software. All the options described in this section failed that
test.
1. Desktops
Microsoft states that “all services in the interactive desktop effectively have privileges
commensurate with the most highly privileged service there” [2]. The implication is that
processes with different privilege levels should run on different desktops. So, our first
idea was to follow Microsoft’s suggestion and run applications with different privileges
on different desktops within Winsta0. However, the window station contains the name
space of desktops. Although a thread can only enumerate windows on its desktop, it can
switch itself to another desktop in its window station if it has the handle to one. It’s even
possible to guess a desktop name. For example, most systems have a desktop named
DEFAULT. Once a thread has a handle to a desktop, it can assign itself to it,
circumventing any security benefits.
We tested this attack by creating an alternate desktop, imaginatively named “alternate”,
and opened three windows on it. We then wrote attack code that did an OpenDesktop,
specifying “alternate” for the desktop name and getting back a handle to the desktop.
The code then did a SetThreadDesktop, enumerated the windows on that desktop, and
sent them SW_MINIMIZE messages. None of the operations used require any
privileges. While this attack did no harm and involved no escalation of privilege, it
shows that Microsoft’s instructions about not putting privileged applications on the
“interactive desktop” are incomplete at best.
2. Window Stations
If desktops aren’t the answer, perhaps Microsoft was really referring to window stations,
not desktops. Unfortunately, using windows stations as the unit of protection instead of
the desktop doesn’t work for interactive applications running at different privilege levels,
as done by Polaris [13]. Since only Winsta0 has access to the display, and windows can’t
move between window stations, there is no way to interact with such applications running
on other window stations.
3. Terminal Server
A given login session has only one window station with access to user interactions, and
the standard versions of Windows have only one interactive window station. The Server
versions don’t have this restriction, though. Hence, we can run each application in its
own login session with its own displayable window station.
There are two problems with this approach. The first is cost. A single license for
Windows XP Professional sells for $300 on the Microsoft web site. One for Server 2003
carries a $1,000 price tag, with an additional charge for Client Access Licenses (CALs)
Page 5
4
beyond the first five. It’s not clear from the Microsoft description of the CAL whether
one is needed for each login session.
The second problem arises primarily in corporate environments. A company’s IT staff
may spend many hours validating their software environment for desktop machines.
Today, that effort is spent on the desktop version of the operating system. Many
applications have not been tested on the Server version.
4. Virtual Machines
Virtual machines, such as VMWare [8], provide all the isolation needed to block Shatter.
All that’s needed is to run every application in a separate virtual machine. Unfortunately,
virtual machines are expensive, almost $200 for a copy of VMWare. They also take
considerable resources; VMWare specifies a minimum of 128 MB RAM for each running
instance. It’s clear that a machine with a standard configuration won’t be able to run very
many instances.
5. Virtual OSes
Defeating Shatter doesn’t require the full emulation of the hardware done by virtual
machines. Virtualizing the operating system, as done by Xen [10] and Virtuozzo [11],
should suffice. A virtual OS is light-weight, allowing a machine to run a large number of
instances. Unfortunately, OSes in widespread distribution, such as Linux and Microsoft
Windows XP, need to be modified in order to run under Xen or Virtuozzo. There is no
Windows version of Xen, and Virtuozzo only supports the Terminal Server 2003 version
of Windows.
6. Common problem
The rejected solutions just described all share a common characteristic; they put windows
into separate environments. That means that producing the look and feel of using
Windows would be hard. The problem is manageable for applications that run in full
screen mode. In those cases, we only need to provide something that looks like the user’s
task bar to allow switching between environments. However, many people prefer to have
overlapping windows, but windows that can overlap necessarily can be used to mount
Shatter attacks against each other.
An alternative to overlapping the actual windows is to use screen scraping and keyboard
stuffing. Say that file explorer is running on the default desktop and a System service is
running on another. An interactive window opened by the service won’t be visible to the
user as long as the default desktop is active. However, we can write code that captures
the bitmap of the service’s interactive window and display those bits on the default
desktop. Note that we have to monitor the window for changes in case it contains
something like a progress bar. Windows messages sent to the window containing the
bitmap won’t reach the service. Keystrokes and mouse events that appear in it can be
forwarded to a daemon running on the alternate desktop for forwarding to the actual
interactive window. Implementing this scheme is a major effort with significant
performance and usability risks.
Page 6
5
4. Defeating Shatter
The process-handling part of the Windows API contains a feature that can be used to
block Shatter. A Job object [12] is designed to allow control of a group of processes.
Once a process has been assigned to a job object, the association cannot be removed, nor
can it be changed. Child processes are part of the same job unless a breakaway privilege
is granted explicitly.
Various restrictions can be placed on processes running within a job. In particular, we
can set the JOB_OBJECT_UILIMIT_HANDLES restriction (UILIMIT for short), which
prevents a process in the job from using handles to windows associated with processes
outside the job. Figure 1 shows Shatter running without the UILIMIT restriction
successfully changing the length field in a dialog box to 4. What you don’t get from this
figure is the beep heard when trying to type a fifth character, which demonstrates the
success of a key step in the attack.
Figure 1. Shatter changed length field with no UI limit.
Figure 2 shows Shatter running in a job with the UI limit. First, you’ll see that the attack
succeeds in getting the window handle, which is the same as the one shown in Figure 1.
However, this time the window message that changes the length of the input field to 4
fails, as shown by the error message and the typed text.
Page 7
6
Figure 2. Shatter unable to change length field with UI limit.
We also tried passing a window handle into a job. A process in a job with UILIMIT was
unable to use the handle. We even tried sending Windows messages using
PostThreadMessage() instead of PostMessage(). These messages were silently dropped
by the receiving thread as expected, based on the API and default implementation of the
message queue.
We conclude that UILIMIT on job objects defeats all shatter-like attacks. That doesn’t
mean that there aren’t flaws in Windows that can’t be exploited using other messaging
methods. However, using this restriction prevents the use of Window messaging, the
defining characteristic of Shatter.
We have built a version of Polaris [13], a package that configures applications to run in
restricted user accounts, to run processes in jobs with the UILIMIT. For the most part,
there are no problems. We did find one problem. Although we haven’t applied the
available clipboard restrictions, processes running with UILIMIT are unable to read text
from the clipboard. Since they can read bitmaps, we believe this problem is caused by a
bug in the Windows implementation, and we are developing a work-around.
Unfortunately, there is a more serious bug in the Windows XP implementation. If you do
a PostMessage() from within a job, specifying HWND_BROADCAST as the target
window handle, the Windows message is delivered to all top level windows, both inside
the job and outside the job. A test program assigned to a job with UILIMIT that sends
WM_CLOSE to HWND_BROADCAST results in all open windows closing. While this
denial of service attack is just an annoyance, it means that windows messages are
escaping the confines of the job and could be used in Shatter attacks.
Page 8
7
This behavior is in direct contradiction to that specified for UILIMIT [9]. The Remarks
section for this restriction says:
If you specify the JOB_OBJECT_UILIMIT_HANDLES flag, when a process
associated with the job broadcasts messages, they are only sent to top-level
windows owned by processes associated with the same job.
We reported this behavior to Microsoft. Their response states
“I have forwarded this information to the product group for further research as a
bug. It appears after researching this, that this is not a security vulnerability. If
this is not the case and I have overlooked the security implications, please send
me details on how an attacker might able to exploit this vulnerability and what the
results of an (sic) successful exploit might be.”
It seems surprising that circumventing a restriction isn’t considered a security
vulnerability, but this position is consistent with Microsoft’s original response to Shatter
[2].
5. Conclusions
The Shatter attack is based on the ability of a process to send a Windows message to
windows associated with processes running at a higher privilege level. While the
WM_TIMER flaw exploited by the original attack has been closed, users are at risk that
other such flaws might be discovered. Microsoft’s response that the desktop is the unit of
protection is at best incomplete. There appear to be ways to break that model.
We have shown that it is possible to defeat Shatter by assigning processes to jobs with
UILIMIT that correspond to their privilege levels. Since UILIMIT restricts the use of
window handles by those in the job, attacks like Shatter are blocked. Any attack based
on the use of Windows messages would be evidence of a bug in the implementation that
Microsoft would be compelled to fix.
Programs running in jobs with UILIMIT appear to behave normally, with two exceptions.
Drag/drop only works between windows in the same job with UILIMIT. However,
processes running with different privileges will most likely run in different logon
sessions, and drag/drop doesn’t work across sessions. The second difference is clearly
due to a bug in the behavior of the clipboard. These jobs cannot paste text, although
there is no problem pasting bitmaps. We believe Microsoft will eventually fix this bug.
In any case, applications appear to run normally under UILIMIT, contrary to the opinion
of the author of Shatter.
References
1. Foon, “Exploiting design flaws in the Win32 API for privilege escalation”,
[...]
Page 9
8
2. Microsoft, “Information About Reported Architecural Flaw in Windows”,
[...] September
2002
3. Microsoft, “Microsoft Security Bulleting MS02-071: Flaw in Windows
WM_TIMER Message Handling Could Enable Privilege Elevation (328310),
[...] December
2002, updated April 2003
4. Foon, “Shatter attacks – more techniques, more detail, more juicy goodness”,
[...]
5. Lavery, Oliver, “Win32 Message Vulnerabilities Redux: Shatter Attacks Remain
a Threat”, iDefense Inc., Reston, VA,
[...] July 2003
6. Brown, Keith, Programming Windows Security, Addison-Wesley, Boston, 2000
7. Microsoft, MSDN Library, [...]
us/dllproc/base/window_stations_and_desktops.asp
8. VMWare, [...]
9. Microsoft, MSDN Library,
[...]
us/dllproc/base/jobobject_basic_ui_restrictions_str.asp
10.
Xen, [...]
11.
SWSoft, Virtuozzo, [...]
12. Microsoft, [...]
13. Stiegler, M., Karp, A. H., Yee, K.-P., Close, T., and Miller, M, “Polaris: Toward
Virus Safe Computing for Windows XP”, HP Labs Tech Report HPL-2004-221,
[...] 2004
[/quote:bdd8486fa2] |
| | | | | | |
| | 
Michael
Wodrich |  [quote:96e3dd9e4d]In Stücke brechen dichtmachendes Windows
Tyler Nahe, Alan H. Karp, Marc Stiegler
Beweglich und Mediasystemlaboratorium
HP-Laboratorien Palo Altstimme
HPL-2005-87
Am 9. Mai, 2005*
Microsoft
Windows-Sicherheit,
Zerschmettern Sie Angriff
Der Zerschmettern Angriff verwendet die Windows-API, um das Prozess-Ausführen zu stürzen
mit dem größeren Vorzug als der Angriffscode. Der Autor des Zerschmettert Codes
hat starke Ansprüche über die Schwierigkeit erhoben, das zu Grunde liegende zu befestigen
Problem, während Microsoft, mit einer Ausnahme, dass der Angriff behauptet hat
ist nicht ein Problem überhaupt. Ungeachtet dessen ob In Stücke brechen, ist tatsächlich ein Großtat-Wert
sich über sorgend, verwendet es eine Eigenschaft von Windows, das anderes böswilliges hat
Gebrauch, wie Anschlag-Protokollierung. Dieses Papier präsentiert ein Mittel des Besiegens
diese komplette Familie von Angriffen mit dem minimalen Brechen von Anwendungen und
Wirkung auf den Blick und das Gefühl der Benutzeroberfläche.
* Internes Zugangsdatum Nur
Genehmigt für die Außenveröffentlichung
© Copyright 2005 Entwicklungsgesellschaft von Hewlett Packard, L.P.
Seite 2
1
In Stücke brechen dichtmachendes Windows
Tyler Nahe, Alan H. Karp, Marc Stiegler
Laboratorien von Hewlett Packard
Palo-Altstimme, Kalifornien
Auszug
Der Zerschmettern Angriff verwendet die Windows-API, um Prozesse zu stürzen, die mit größer laufen
Vorzug als der Angriffscode. Der Autor des Zerschmettert Codes hat starke Ansprüche erhoben
über die Schwierigkeit, das zu Grunde liegende Problem zu befestigen, während Microsoft, mit einem hat
Ausnahme, gefordert, dass der Angriff nicht ein Problem überhaupt ist. Ungeachtet dessen ob In Stücke brechen, ist tatsächlich
ein Großtat-Wert, der sich darüber sorgt, es verwendet eine Eigenschaft von Windows, das anderes böswilliges hat
Gebrauch, wie Anschlag-Protokollierung. Dieses Papier präsentiert ein Mittel, das komplett zu vereiteln
Familie von Angriffen mit dem minimalen Brechen von Anwendungen und Wirkung auf den Blick und das Gefühl dessen
die Benutzeroberfläche.
1. Einführung
Brechen Sie [1], so genannt in Stücke, weil es Windows bricht, die Windows-API verwendet, um zu senden
Nachrichten zu Fenstern verkehrten mit Prozessen, die größere Autorität haben als
Prozess, der den Code des Angreifers ausführt. In den Beispiel-Großtaten ist das Ziel ein System
Dienst, der ein Fenster auf dem interaktiven Desktop hat. Der Angriff verwendet Windows-Nachrichten
die Länge-Beschränkungen eines Eingabefeldes im Zielfenster und Einsatz-Code zu entfernen
in den Adressraum des Dienstes. Der Endschritt sendet eine WM_TIMER Nachricht das
veranlasst den Dienst zum Zweig zur Großtat.
Microsoft bestritt am Anfang, dass der Angriff einen architektonischen Fehler in Windows [2] ausnutzt,
das Zitieren von drei Punkten:
· Privilegierte Dienstleistungen sollten nicht Fenster auf dem interaktiven Desktop haben.
· Brechen Sie in Stücke verlangt, dass der Angreifer im Stande ist, auf das System zu loggen.
· Keine Vorzüge werden auf dem Gebiet gewonnen.
Dieses Zeichen stellt auch fest, dass alle Dienstleistungen innerhalb des interaktiven Desktops Gleiche, welch sind
deutet an, dass Prozesse mit verschiedenen Vorzug-Niveaus auf demselben nicht gelegt werden sollten
Desktop. Microsoft bemerkt auch, dass es lange dass Prozesse mit dem System empfohlen hat
Vorzüge nicht haben Fenster auf dem sichtbaren Desktop. Eine Antwort [4] weist darauf hin
mehrere Dienstleistungen, einige geliefert von Microsoft, verletzen diese Regel.
Die zweiten und dritten Punkte des Microsofts scheinen unaufrichtig. Die Protokollierung auf das System ist nicht
der allgemeinste Weg für Angreifer, um Code auszuführen. Viren, Würmer, und ActiveX-Steuerungen
auf Webseiten sind viel leichtere Methoden als Entdeckung von Kennwörtern. Außerdem nicht das Herausstellen
Gebiet, um anzugreifen, wird kleine Bequemlichkeit Benutzern sein, die alle ihre lokalen Dateien gehabt haben
verdorben.
Seite 3
2
Microsoft veröffentlichte später eine Sicherheitsmeldung [3], der den WM_TIMER-Fehler befestigte. Das
Nachricht informiert die Anwendung, dass ein Kernzeitmesser-Ereignis vorgekommen ist und erzählt
Anwendung welche Adresse, dazu zu springen. Der Fehler war, dass die Anwendung das nicht überprüfte
Adresse. Folglich, sobald der Großtat-Code in der Zielanwendungsadresse installiert wurde
Raum, eine WM_TIMER Nachricht würde diesen Code veranlassen, durchgeführt zu werden. Die üble Lage fügte a hinzu
überprüfen Sie, um zu sehen, ob die in der WM_TIMER Nachricht angegebene Adresse als ein Anruf registriert wurde-
zurück vor der Einnahme des Zweigs. Der Autor dessen Bricht zugegeben In Stücke, dass diese üble Lage größtenteils blockierte
der Angriff [4], aber gefordert, dass dieser Fleck das Problem nicht völlig behob. Ein späteres Papier
[5] demonstriert dass andere Windows-Nachrichten, wie EM_SETWORDBREAKPROC,
kann auch darin verwendet werden Zerschmettern artige Angriffe.
Der Papierbericht bricht In Stücke erhebt mehrere starke Ansprüche über die Schwierigkeit zu machen
Änderungen, um den Angriff zu hindern, erfolgreich zu sein. Die vorgeschlagenen Lösungen die ganze Brechung
Anwendungen oder Änderung das Verhalten des Systems. Grundsätzlich, dort ist nicht einfach
Lösung. fasst die Meinung des Autors zusammen.
Wir haben eine Eigenschaft in der Windows-API gefunden, die Niederlagen Zerschmettern, indem sie minimal haben
Einfluss auf Anwendungsverhalten oder die Wechselwirkung des Benutzers mit dem System. Zuerst, dieses Papier
beschreibt, wie Windows in der Abteilung 2 strukturiert wird. Dann beschreibt Abteilung 3 mehrerer
zurückgewiesene Annäherungen an das Besiegen brechen In Stücke. Unsere vorgeschlagene Lösung und die Testvertretung
dass es arbeitet, werden in der Abteilung 4 präsentiert.
2. Windows-Struktur
Die meisten Menschen sind bewusst, dass jedes Fenster auf einem Desktop erscheint. Weniger Menschen wissen das
es kann vielfache Desktops geben. Zum Beispiel erscheint das Anmeldungsfenster auf einem bestimmten
Desktop. Sogar weniger weiß, dass jeder Desktop einer Fensterstation [8] zugeteilt wird.
Das Verstehen der Antwort des Microsofts [um 8] und unsere Annäherung an das Besiegen davon In Stücke zu brechen
verlangt Kenntnisse der Wechselwirkung unter diesen Strukturen.
Die Benutzeroberfläche-Komponente von Windows besteht aus mehreren Teilen. Man ist
Fensterstation [7], der ein Securable-Objekt ist, das eine Zwischenablage, ein oder mehr enthält
Tischobjekte, und ein anderer Zustand zugänglich für Objekte in der Fensterstation. Jeder
Anmeldungssitzung wird mit einer Fensterstation vereinigt. Ein Desktop ist ein Securable-Objekt
beigefügt einer Fensterstation, die UI-Objekte, wie Fenster, Menüs, und Haken hält.
Bemerken Sie, dass Fenster nicht securable Objekte in der Windows-API sind.
Nur eine Fensterstation, genannt Winsta0, kann mit der Benutzeranzeige, Tastatur interagieren,
und Maus, außer auf der Enddienstleistungsversion des Betriebssystems wo jeder
Sitzung hat solch eine Fensterstation. Nur ein Desktop kann auf einmal mit dem Benutzer interagieren,
und dieser Desktop muss mit Winsta0 notwendigerweise vereinigt werden. Jeder Prozess ist
vereinigt mit einer Fensterstation, und jedem Faden wird mit einem Desktop vereinigt. Fäden
kann sich zwischen Desktops bewegen, und Prozesse können sich zwischen Fensterstationen bewegen, aber
Fenster werden an die Fensterstation gebunden, wo sie starteten.
Seite 4
3
3. Zurückgewiesene Optionen
Wir dachten, dass mehrere Annäherungen, um zu vereiteln, In Stücke brechen. Zusätzlich zum bloßen Blockieren
Brechen Sie in Stücke, wir fanden, dass wir auch die Brauchbarkeit des Systems aufrechterhalten mussten. Immerhin würden wir nein bekommen
Sicherheit, wenn niemand unsere Software verwendete. Alle in dieser Abteilung beschriebenen Optionen fehlten dem
Test.
1. Desktops
Microsoft stellt fest, dass alle Dienstleistungen im interaktiven Desktop effektiv Vorzüge haben
entsprechend dem am höchsten privilegierten Dienst dort [2]. Die Implikation ist das
Prozesse mit verschiedenen Vorzug-Niveaus sollten auf verschiedenen Desktops laufen. Also, unser erstes
Idee war, dem Vorschlag des Microsofts zu folgen und Anwendungen mit verschiedenen Vorzügen auszuführen
auf verschiedenen Desktops innerhalb von Winsta0. Jedoch enthält die Fensterstation den Namen
Raum von Desktops. Obwohl ein Faden nur Fenster auf seinem Desktop aufzählen kann, kann es
Schalter selbst zu einem anderen Desktop in seiner Fensterstation, wenn es den Griff zu einem hat. Das ist sogar
möglich, einen Tischnamen zu erraten. Zum Beispiel ließen die meisten Systeme einen Desktop nennen
VERZUG. Sobald ein Faden einen Griff zu einem Desktop hat, kann es sich dazu zuteilen,
das Überlisten irgendwelcher Sicherheitsvorteile.
Wir prüften diesen Angriff, indem wir einen abwechselnden Desktop, fantasievoll genannt Stellvertreter schufen,
und geöffnet drei Fenster darauf. Wir schrieben dann Angriffscode, der einen OpenDesktop tat,
das Spezifizieren des Stellvertreters für den Tischnamen und einen Griff zum Desktop zurückbekommend.
Der Code tat dann einen SetThreadDesktop, zählte die Fenster auf diesem Desktop auf, und
gesandt sie SW_MINIMIZE Nachrichten. Keine der verwendeten Operationen verlangt irgendwelchen
Vorzüge. Während dieser Angriff keinem Schaden zufügte und keine Eskalation des Vorzugs, seiner einschloss
Shows dass die Instruktionen des Microsofts darüber, privilegierte Anwendungen nicht anzuziehen
interaktiver Desktop ist unvollständig bestenfalls.
2. Fensterstationen
Wenn Desktops nicht die Antwort sind, vielleicht bezog sich Microsoft auf Fensterstationen wirklich,
nicht Desktops. Leider, Fensterstationen als die Einheit des Schutzes statt verwendend
der Desktop arbeitet für Dialoganwendungen nicht, die an verschiedenen Vorzug-Niveaus laufen,
wie getan, durch den Polarstern [13]. Da nur Winsta0 Zugang zur Anzeige hat, und Fenster nicht können
Bewegung zwischen Fensterstationen, es gibt keine Weise, mit solchem Anwendungsausführen zu interagieren
auf anderen Fensterstationen.
3. Endserver
Eine gegebene Anmeldungssitzung hat nur eine Fensterstation mit dem Zugang zu Benutzerwechselwirkungen, und
die Standardversionen von Windows haben nur eine interaktive Fensterstation. Der Server
Versionen haben diese Beschränkung nicht, dennoch. Folglich können wir jede Anwendung in seinem ausführen
eigene Anmeldungssitzung mit seiner eigenen displayable Fensterstation.
Es gibt zwei Probleme mit dieser Annäherung. Das erste wird gekostet. Eine einzelne Lizenz dafür
Windows XP Fachmann verkauft für 300 $ auf der Website von Microsoft. Ein für den Server 2003
trägt ein Preisschild von 1.000 $, mit einem Zuschlag für Clientzugriffslizenzen (CALs)
Seite 5
4
außer den ersten fünf. Das ist von der Beschreibung von Microsoft des CALS ob nicht klar
man ist für jede Anmeldungssitzung gefragt.
Das zweite Problem entsteht in erster Linie in korporativen Umgebungen. Eine Gesellschaft besetzt ES
kann viele Stunden ausgeben, ihre Softwareumgebung für Tischmaschinen gültig machend.
Heute wird diese Anstrengung für die Tischversion des Betriebssystems ausgegeben. Viele
Anwendungen sind auf der Server-Version nicht geprüft worden.
4. Virtuelle Maschinen
Virtuelle Maschinen, wie VMWare [8], stellen die ganze Isolierung zur Verfügung musste blockieren brechen In Stücke.
Alles es ist gefragt, soll jede Anwendung in einer getrennten virtuellen Maschine ausführen. Leider,
virtuelle Maschinen sind teuer, für eine Kopie von VMWare fast 200 $. Sie nehmen auch
beträchtliche Ressourcen; VMWare gibt ein Minimum des 128-Mb-RAM für jedes Ausführen an
Beispiel. Es ist klar, dass eine Maschine mit einer Standard-Konfiguration nicht im Stande sein wird, sehr zu laufen
viele Beispiele.
5. Virtueller OSes
Das Besiegen bricht In Stücke verlangt den vollen Wetteifer der Hardware getan durch virtuell nicht
Maschinen. Virtualizing das Betriebssystem, wie getan, durch Xen [10] und Virtuozzo [11],
sollte genügen. Ein virtueller OS ist Leichtgewichtler, eine Maschine erlaubend, eine große Anzahl dessen auszuführen
Beispiele. Leider, OSes im weit verbreiteten Vertrieb, wie Linux und Microsoft
Windows XP, Bedürfnis, modifiziert zu werden, um unter Xen oder Virtuozzo zu laufen. Es gibt nein
Windows-Version von Xen, und Virtuozzo unterstützen nur die Endserver-2003-Version
Windows.
6. Allgemeines Problem
Die zurückgewiesenen Lösungen beschrieben gerade den ganzen Anteil eine allgemeine Eigenschaft; sie stellen Fenster
in getrennte Umgebungen. Das bedeutet dass, den Blick und das Gefühl des Verwendens produzierend
Windows würde hart sein. Das Problem ist für Anwendungen lenksam, die vollständig laufen
Bildschirmmodus. In jenen Fällen müssen wir nur etwas zur Verfügung stellen, was wie der Benutzer aussieht
Startleiste, um zu erlauben, zwischen Umgebungen umzuschalten. Jedoch ziehen viele Menschen es vor zu haben
Überschneidung auf Fenster, aber Fenster, die notwendigerweise überlappen können, kann verwendet werden, umzu steigen
Zerschmettern Sie Angriffe gegen einander.
Eine Alternative zur Überschneidung auf die wirklichen Fenster soll Bildschirm kratzend und Tastatur verwenden
Füllung. Sagen Sie, dass Dateiforscher auf dem Verzug-Desktop läuft und ein Systemdienst ist
das Ausführen auf einem anderen. Ein interaktives durch den Dienst geöffnetes Fenster wird zu nicht sichtbar sein
der Benutzer so lange der Verzug-Desktop ist aktiv. Jedoch können wir Code schreiben, der gewinnt
die Bitmap des interaktiven Fensters des Dienstes und Anzeige jene Bit auf dem Verzug
Desktop. Bemerken Sie, dass wir das Fenster für Änderungen kontrollieren müssen, im Falle dass es enthält
etwas wie eine Fortschritt-Bar. Windows-Nachrichten gesandt zum Fenster, das enthält
Bitmap wird den Dienst nicht erreichen. Anschläge und Maus-Ereignisse, die darin erscheinen, können sein
nachgeschickt einem Dämon, der auf dem abwechselnden Desktop läuft, um zum wirklichen nachzuschicken
interaktives Fenster. Das Einführen dieses Schemas ist eine Hauptanstrengung mit bedeutend
Leistung und Brauchbarkeitsgefahren.
Seite 6
5
4. Das Besiegen bricht In Stücke
Der Prozess behandelnde Teil der Windows-API enthält eine Eigenschaft, die dazu verwendet werden kann
Block bricht In Stücke. Ein Job-Objekt [12] wird entworfen, um Kontrolle einer Gruppe von Prozessen zu erlauben.
Sobald ein Prozess einem Job-Objekt zugeteilt worden ist, kann die Vereinigung nicht entfernt werden, noch
kann es geändert werden. Kind geht in einer Prozession sind ein Teil desselben Jobs es sei denn, dass ein Absplitterungsvorzug
wird ausführlich gewährt.
Verschiedene Beschränkungen können auf Prozessen gelegt werden, die innerhalb eines Jobs laufen. Insbesondere wir
kann die JOB_OBJECT_UILIMIT_HANDLES Beschränkung (UILIMIT für kurz), welch setzen
verhindert einen Prozess im Job davon, Griffe zu mit Prozessen vereinigten Fenstern zu verwenden
außerhalb des Jobs. Shows der Abbildung 1 Zerschmettern das Ausführen ohne die UILIMIT Beschränkung
erfolgreich das Länge-Feld in einem Dialogfeld zu 4 ändernd. Was Sie davon nicht bekommen
Zahl ist der Signalton hörte versuchend, ein fünftes Zeichen zu tippen, das demonstriert
der Erfolg eines Schlüssels geht im Angriff.
Abbildung 1. Zerschmettern Sie geändertes Länge-Feld ohne UI-Grenze.
Shows der Abbildung 2 Zerschmettern das Ausführen in einem Job mit der UI-Grenze. Zuerst werden Sie dass der Angriff sehen
schafft, den Fenstergriff zu bekommen, der dasselbe als ein gezeigter in der Abbildung 1 ist.
Jedoch, dieses Mal die Fensternachricht, die die Länge des Eingabefeldes zu 4 ändert
scheitert wie gezeigt, durch die Fehlermeldung und den getippten Text.
Seite 7
6
Abbildung 2. Brechen Sie unfähig in Stücke, Länge-Feld mit der UI-Grenze zu ändern.
Wir versuchten auch, einen Fenstergriff in einen Job zu passieren. Ein Prozess in einem Job mit UILIMIT war
unfähig, den Griff zu verwenden. Wir versuchten sogar, das Windows-Nachrichtenverwenden zu senden
PostThreadMessage () statt der Postnachricht (). Diese Nachrichten waren still fallen gelassen
durch den Empfang-Faden, wie erwartet, beruhend auf die API und Verzug-Durchführung
Nachrichtenwarteschlange.
Wir beschließen, dass UILIMIT auf Job-Objekten vereitelt, zerschmettern alle artige Angriffe. Das tut nicht
meinen Sie, dass es nicht Fehler in Windows gibt, das nicht ausgenutzt werden kann, andere Nachrichtenübermittlung verwendend
Methoden. Jedoch verhindert das Verwenden dieser Beschränkung den Gebrauch der Fensternachrichtenübermittlung,
das Definieren der Eigenschaft dessen bricht In Stücke.
Wir haben eine Version des Polarsterns [13], ein Paket gebaut, das Anwendungen konfiguriert, um darin zu laufen
eingeschränkter Benutzer rechnet ab, Prozesse in Jobs mit dem UILIMIT auszuführen. Größtenteils,
es gibt keine Probleme. Wir fanden wirklich ein Problem. Obwohl wir uns nicht gewandt haben
verfügbare Zwischenablage-Beschränkungen, Prozesse, die mit UILIMIT laufen, sind außer Stande, Text zu lesen
aus der Zwischenablage. Da sie Bitmaps lesen können, glauben wir, dass dieses Problem durch a verursacht wird
Programmfehler in der Windows-Durchführung, und entwickeln wir eine Arbeit - ringsherum.
Leider gibt es einen ernsteren Programmfehler in der Durchführung des Windows XP. Wenn Sie tun
eine Postnachricht () aus einem Job, HWND_BROADCAST als das Ziel angebend
Fenstergriff, die Windows-Nachricht wird an alle Spitzenniveau-Fenster, beides Inneres geliefert
der Job und außerhalb des Jobs. Ein Testprogramm teilte einem Job mit UILIMIT zu, der sendet
WM_CLOSE zu HWND_BROADCAST läuft auf das ganze offene Fensterschließen hinaus. Während das
die Leugnung des Dienstangriffs ist gerade ein Ärger, es bedeutet, dass Fensternachrichten sind
das Entgehen den Grenzen des Jobs und konnte darin verwendet werden Zerschmettern Angriffe.
Seite 8
7
Dieses Verhalten ist im direkten Widerspruch dazu angegeben für UILIMIT [9]. Die Bemerkungen
die Abteilung für diese Beschränkung sagt:
Wenn Sie die JOB_OBJECT_UILIMIT_HANDLES Fahne, wenn ein Prozess angeben
vereinigt mit dem Job überträgt Nachrichten, sie werden nur zu auf höchster Ebene gesandt
Fenster besessen durch mit demselben Job vereinigte Prozesse.
Wir meldeten dieses Verhalten bei Microsoft. Ihre Ansprechzustände
Ich habe diese Information zur Produktgruppe für die weitere Forschung als a nachgeschickt
Programmfehler. Es erscheint nach der Forschung davon, dass das nicht eine Sicherheitsverwundbarkeit ist. Wenn
das ist nicht der Fall, und ich habe die Sicherheitsimplikationen überblickt, senden Sie bitte
ich berichten darauf ausführlich, wie ein Angreifer fähig könnte, diese Verwundbarkeit und was auszunutzen
Ergebnisse einer (sic) erfolgreichen Großtat könnten sein.
Es scheint überraschend, dass das Überlisten einer Beschränkung als eine Sicherheit nicht betrachtet wird
Verwundbarkeit, aber diese Position ist mit der ursprünglichen Antwort des Microsofts übereinstimmend, um In Stücke zu brechen
[2].
5. Beschlüsse
Der Zerschmettern Angriff beruht auf der Fähigkeit eines Prozesses, eine Windows-Nachricht daran zu senden
Fenster verkehrten mit Prozessen, die an einem höheren Vorzug-Niveau laufen. Während
Durch den ursprünglichen Angriff ausgenutzter WM_TIMER-Fehler ist geschlossen worden, Benutzer sind gefährdet das
andere solche Fehler könnten entdeckt werden. Die Antwort des Microsofts, deren der Desktop die Einheit ist
Schutz ist an am besten unvollständig. Es scheint, Weisen zu geben, dieses Modell zu brechen.
Wir haben gezeigt, dass es möglich ist zu vereiteln, brechen In Stücke, Prozesse Jobs damit zuteilend
UILIMIT, die ihren Vorzug-Niveaus entsprechen. Da UILIMIT den Gebrauch dessen einschränkt
Fenstergriffe durch diejenigen im Job, Angriffe mögen brechen In Stücke werden blockiert. Jeder beruhende Angriff
auf dem Gebrauch von Windows Nachrichten würde Beweise eines Programmfehlers in der Durchführung das sein
Microsoft würde dazu gezwungen zu befestigen.
Programme, die in Jobs mit UILIMIT laufen, scheinen, sich normalerweise mit zwei Ausnahmen zu benehmen.
Schleifen Sie nur Arbeiten zwischen Fenstern in demselben Job mit UILIMIT/fallen Sie. Jedoch,
Prozesse, die mit verschiedenen Vorzügen laufen, werden am wahrscheinlichsten in der verschiedenen Anmeldung laufen
Sitzungen, und Schinderei/Fall arbeiten über Sitzungen nicht. Der zweite Unterschied ist klar
wegen eines Programmfehlers im Verhalten der Zwischenablage. Diese Jobs können nicht Text, obwohl aufkleben
es gibt kein Problem, das Bitmaps aufklebt. Wir glauben, dass Microsoft schließlich diesen Programmfehler befestigen wird.
Jedenfalls scheinen Anwendungen, normalerweise unter UILIMIT gegen die Meinung zu laufen
des Autors dessen brechen In Stücke.
Verweisungen
1. Foon, Design Ausnutzend, macht in der Win32 API für die Vorzug-Eskalation, rissig
[...]
Seite 9
8
2. Microsoft, Information Über Berichteten Architecural Flaw in Windows,
[...] September
2002
3. Microsoft, Sicherheit von Microsoft Bulleting MS02-071: Fehler in Windows
WM_TIMER-Nachrichtenbehandlung Konnte Vorzug-Erhebung (328310) Ermöglichen,
[...] Dezember
2002, aktualisierter April 2003
4. Foon, Zerschmettern Angriffe - mehr Techniken, mehr Detail, saftigere Güte,
[...]
5. Lavery, Oliver, Win32 Nachrichtenverwundbarkeit Redux: Brechen Sie In Stücke Angriffe Bleiben
eine Drohung, iDefense Inc., Reston, VA,
[...] Juli 2003
6. Braun, Keith, Windows-Sicherheit Programming, Addison-Wesley, Boston, 2000
7. Microsoft, MSDN Bibliothek, [...]
us/dllproc/base/window_stations_and_desktops.asp
8. VMWare, [...]
9. Microsoft, MSDN Bibliothek,
[...]
us/dllproc/base/jobobject_basic_ui_restrictions_str.asp
10.
Xen, [...]
11.
SWSoft, Virtuozzo, [...]
12. Microsoft, [...]
13. Stiegler, M., Karp, A. H., Yee, K.-P. Nahe, T., und Müller, M, Polarstern: Dazu
Virus-Safe, der für Windows XP, HP-Laboratorium-Technologie-Bericht HPL-2004-221 Rechnet,
[...] 2004[/quote:96e3dd9e4d]
Schöne Grüße
Michael Wodrich |
| | | | Programmieren, das spannendste Detektivspiel der Welt. | 27.08.2006 ▲ |
| | |
| | | Micha find ich gut ...  ...
Wenn man es selbst übersetzt, gibt es auf jedenfall mehr Sinn. 
Da ich sowieso überall meinen Senf dazugeben muß, will ich auch diesen (englischen ) Text nicht ganz unkommentiert lassen.
Hier ist unter anderem von der Message EM_SETWORDBREAKPROC die Rede. Da EM_SETWORDBREAKPROC - anders als WM_TIMER -aber ziemlich aggressiv mit Zugriffsverletzungen reagiert, ist die Gefahr die von EM_SETWORDBREAKPROC ausgeht wohl extrem klein.
Daran Schuld, das Microsoft die WM_TIMER Problematik erst ziemlich spät erkannt hat, ist meiner Meinung nach der Autor der Shatter Attack selbst. Die Verfahrensweise über ein Edit Quelltext einzuschleusen ist in der Praxis kaum praktikabel - aber die API bietet da noch viel bessere und gefährlichere Möglichkeiten einen Rechner anzugreifen, und die scheint MS zum Schluß auch endlich erkannt zu haben.
Zum Bugfix selbst:
Microsoft ist unter XP Servicepack 2 sehr vorsichtig geworden und hat einiges sehr gut gefixt, was mir vorher gewaltig auf den Magen geschlagen ist. Das Senden der WM_TIMER Message an fremde Fenster wurde an mehreren Stellen unterbunden - ich bin zur Zeit noch dabei zu testen, ob diese fixes irgendwie zu umgehen sind (einige Sachen, von denen Microsoft behauptet, sie seien nicht möglich, gehen scheinbar doch - z.B. ältere Betriebssystem-DLLs in den Prozess laden und die in den DLLs befindlichen Exportfunktionen ansprechen z.B. ).
Sowohl MS als auch die Hersteller von Sicherheitssoftware halten sich scheinbar daran, keine angreifbaren Fenster in ihren Services zu erzeugen - bei anderen Softwareanbietern (Gafiktreibern z.B.) sieht das aber leider ganz anders aus! |
| | | | | | |
|
AntwortenThemenoptionen | 3.425 Betrachtungen |
ThemeninformationenDieses Thema hat 3 Teilnehmer: |
(767)
Deutsch
English
Français
Español
Italia