[MS/Win32-API] Lokale Privilegienerweiterung möglich
(2002-09-06 14:44:26.179984+02) Druckversion
Quelle: http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00101.html
Lokal am System angemeldete Benutzer können über Dienste, die in einem anderen Sicherheitskontext ausgeführt werden
(z.B. mit SYSTEM-Rechten) und eine
Interaktion des Benutzers vorsehen, ihre Privilegien erweitern.
Betroffene Systeme
- Programme/Dienste auf Microsoft Windows Systemen, die mit erweiterten Privilegien ausgeführt werden und eine Interaktion des Benutzers vorsehen
Einfallstor
lokaler Benutzeraccount
Auswirkung
Ausführung beliebigen Programmcodes mit erweiterten Privilegien
(z.B. mit SYSTEM-Privilegien)
Typ der Verwundbarkeit
design flaw (allerdings bei den Anwendungen)
Gefahrenpotential
niedrig bis hoch
(Hinweise zur
Einstufung
des Gefahrenpotentials.)
Beschreibung
Die unbedachte Verwendung der Win32-API kann insbesondere bei Programmen/Diensten, die
während ein Benutzer am System angemeldet ist und in anderem Sicherheitskontext
ausgeführt werden (z.B. SYSTEM-Privilegien), zu einer lokalen
Privilegienerweiterung führen.
Die von Windows NT abgeleiteten Win32-Plattformen unterstützen sogenannte Services, die gewöhnlich im Hintergrund und ohne Benutzereingriff Dienste zur Verfügung stellen (z.B. ein automatisches Backup). In manchen Fällen (z.B. wenn ein Virenscanner den Benutzer über eine möglicherweise befallene Datei, oder eine Personal Firewall über einen blockierten Zugriff informieren soll) müssen solche Services jedoch mit dem Benutzer kommunizieren. Dies geschieht in der Regel dadurch, daß Fenster auf dem gewöhnlichen Desktop des Nutzers angelegt werden. Dies führt zu Problemen, da dann solche Services bedingt durch Eigenheiten der Win32-API nicht mehr sauber von den Anwendungen des Benutzers getrennt sind (siehe z.B. Q115825 von 1994).
Derzeit ist von einigen Programmen bekannt, daß sie die beschriebene Schwachstelle aufweisen und Angreifer darüber Programmcode in anderem Sicherheitskontext ausführen können. Betroffen sind z.B:- Network Associates VirusScan v4.5.1
- VNC v3.3.3R9, TightVNC v1.2.5, TridiaVNC 1.5.4
- NetDDE
- Messenger
Der von Microsoft empfohlene Ansatz, auf einen
RPC-Mechanismus zurückzugreifen und die GUI im Kontext des Anwenders
laufen zu lassen, funktioniert nur zum Schutz des Systems vor
böswilligen Anwendern bzw. von ihnen gestarteter Software.
Es ist damit nicht möglich, daß ein Service den Anwender zuverlässig
warnen kann, nachdem dieser böswillige Software gestartet hat, die
seinen Account kompromittiert und damit alle Software, die in diesem
Sicherheitskontext läuft, manipulieren kann. Zahlreiche Anwender
erwarten aber genau dies von Personal Firewalls oder von
Programmen zum Schutz vor sogenannten Dialern. Eine sichere
Benachrichtigung des Nutzers ist nur über separate Desktops und
"window stations" zu erreichen, was sich den Nutzern aber
wahrscheinlich nicht verkaufen läßt:
Dazu muß auf einen komplett separaten Desktop umgeschaltet werden
(mit demselben Mechanismus, der aktiv wird, wenn ein Benutzer
Strg+Alt+Entf drückt), was vermutlich einen zu großen Komfortverlust
darstellt. Diese Maßnahme wäre jedoch in dieser Situation unbedingt
erforderlich, denn sonst können böswillige Anwendungen verwirrende
Hinweise auf dem Bildschirm anzeigen, die den Nutzer (für den die typischen Sicherheitsmeldungen bereits
hinreichend schwer verständlich sind) so verwirren, daß er eine falsche Entscheidung
trifft.
Entgegen der landläufigen Meinung ermöglicht das auf UNIX-Systemen häufig verwendete X Window System ähnliche Angriffe. Auch hier sollte nicht davon ausgegangen werden, daß Anwendungen mit unterschiedlichen Privilegien auf demselben Display ausgeführt werden können, ohne daß sie sich beeinflussen können.
Workaround
Systemadministratoren sollten auf Dienste, die mit erweiterten Privilegien ausgeführt werden
und eine Interaktion mit dem Benutzer vorsehen, verzichten. Davon sind
offenbar auch die Windows 2000 Dienste "Messenger" und "Network DDE" betroffen (die deshalb deaktiviert werden sollten).
Falls möglich, sollten Dienste, die eine Benutzerinteraktion erfordern (z.B. Virenscanner) nicht
mit SYSTEM-Privilegien ausgeführt werden, sondern ggf. im Sicherheitskontext eines
ebenfalls eingeschränkten Accounts gestartet werden.
Gegenmaßnahmen
Da es sich bei dieser Schwachstellenfamilie um einen Designfehler
handelt, der von verschiedenen Herstellern nicht als solcher
eingeschätzt wird oder der als minderschwer eingestuft wird, gibt es
keine Patches oder es werden aus Sicht des RUS-CERT ungenügende
Gegenmaßnahmen ergriffen.
Softwarehersteller sind daher aufgefordert auf Dienste, die mit erweiterten Privilegien
(z.B. SYSTEM-Rechten) arbeiten und eine Interaktion mit dem Benutzer vorsehen (d.h. interactive desktop verwenden),
zu verzichten. Nach Angaben von Microsoft
werden zukünftige Windows-Versionen interaktive Dienste möglicherweise
nicht mehr unterstützen. Softwarehersteller sollen stattdessen Technologien
wie RPC, Sockets, named pipes, window stations oder COM zur Interaktion mit dem
Benutzer verwenden (siehe Q327618).
Weitere Information zu diesem Thema
- Information About Reported Architectural Flaw in Windows (Microsoft)
- Tackling Two Obscure Security Issues (Microsoft)
- Microsoft System Journals March 1997 (Microsoft)
- White paper: Exploiting the Win32 API (BUGTRAQ-Thread)
- Shatter attacks - more techniques, more detail, more juicy goodness
- Windows fuzz (VULN-DEV-Thread)
- A New Avenue of Attack: Event-driven system vulnerabilities
- Security Vulnerabilities in Event-Driven Systems
- A New Avenue of Attack: Event-driven System Vulnerabilities
- Exploiting design flaws in the Win32 API for privilege escalation
- Win32 API 'shatter' vulnerability found in VNC-based products (BUGTRAQ)
Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der
Universität Stuttgart recherchiert und zusammengestellt. Die Universität
Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel
darf ausschließlich in unveränderter Form und nur zusammen mit diesem
Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine
Veröffentlichung unter diesen Bedingungen an anderer Stelle ist
ausdrücklich gestattet.
Copyright © 2013 RUS-CERT, Universität Stuttgart, http://cert.uni-stuttgart.de/
| Vorherige Meldung | Weitere Meldungen... | Nächste Meldung |
Bitte lesen Sie auch die Grundsätze, nach denen das RUS-CERT Tickermeldungen veröffentlicht. Der regelmäßige Bezug von Tickermeldungen über E-Mail und RSS-Feed ist ebenfalls möglich.