Mit Firefox passiert nichts (da könnt ihr euch also auch die Infos zu den Problemen in Ruhe durchlesen) – Safari jedoch crasht ohne Vorwarnung!




Hier reicht leider schon der Besuch der Seite (jede WebKit-basierte Applikation wird durch das Bild "jag_towcar.jpg" z.Z. zum Absturz gebracht).





Hier muss man Ctrl + a drücken um Safari crashen zu lassen.



Der erste Bug ist ärgerlich, da ein ähnlicher Fehler mit dem letzten Security-Update beseitigt wurde (http://www.drunkenblog.com/drunkenblog-archives/000635.html).

Der zweite ist umso ärgerlicher, da er seit Monaten NICHT gefixt ist!

hoschi
Sagt wer?

hoschi

Rechthaberei habe ich bisher bei MacMark nicht erkennen können - und ich lese ihn schon lange.

Tom Ferris liefert mittlerweile weitere Details zu seinen neu entdeckten bzw. weiterhin vorhandenen Bugs:



Es lässt sich also weiterhin durch einen Heap Overflow potentiell Schadcode einschleusen und mit den Rechten des angemeldeten Benutzers ausführen!

Genauere Details, wie in solchen Fällen immer wieder von MacMark gefordert, veröffentlicht Ferris allerdings nach wie vor nicht…

Ferris bedient sich der sogenannten "Fuzzing-Methode". Spezielle Tools erzeugen hierbei für Dateiformate und Protokolle fehlerhafte Daten und füttern ein Programm so lange, bis ein Fehler auftritt.
Daraufhin wird dieser Fehlerfall mit einem Debugger genauer untersucht, um zu sehen, worauf er zurückzuführen ist und ob er sich eventuell missbrauchen lässt.



Auch die beiden auf JavaScript zurückzuführenden Bugs, welche Safari ohne Vorwarnung zum Absturz bringen (aktuelle Links gepostet am 12.05.06 um 22:14), sind nach wie vor nicht beseitigt.

Da im aktuellen Entwickler-Build des kommenden 10.4.7 (8J111) u.a. auch einige Fixes in Safari/Webkit vorgenommen wurden, bleibt zu hoffen, dass diese Bugs bis zum finalen 10.4.7 der Vergangenheit angehören.

PS: Dieser originale Proof-of-Concept von Tom Ferris funktioniert seit dem Security-Update nicht mehr (ist also gefixt):



Eine leichte Modifizierung reichte jedoch aus, um Safari erneut zum Absturz bringen zu können (VORSICHT!):



Diese "Qualität" von Fixes seitens Apple erinnert traurigerweise an Probleme, die wir bisher nur in Redmond vermuteten…

@ Marcel_75@work

nur mal bezogen auf

"Es lässt sich also weiterhin durch einen Heap Overflow potentiell Schadcode einschleusen und mit den Rechten des angemeldeten Benutzers ausführen!"
und
"Eine leichte Modifizierung reichte jedoch aus, um Safari erneut zum Absturz bringen zu können (VORSICHT!)"


Wie kommst du eigentlich darauf, dass das alles gefährlich ist, nur weil man Safari reproduzierbar ab saufen lassen kann. Kann, muss das noch lange nicht stimmen, dass man dort auch Schadcode einschleusen könnte.

Übrigens kannst du ja mal das öffentliche Webkit-Bugzilla durchschauen - dort sind noch einige Bugs mehr die Safari reproduzierbar ab saufen lassen - auch hier sagt ja niemand das das alles potentielle Overflow Lücken sind.

Ansonsten mal einer mit offensichtlich mehr Ahnung dazu - aus dem Heiseforum - und weil soweiso niemand Links aufmacht mal den ganzen Text:


Sturm im Wasserglas!
killingfields (mehr als 1000 Beiträge seit 20.6.01)
Bewertung dieses Beitrags: [Beitragsbewertung: 62%]


Leider kann man die aktuellen Sicherheitshinweise inzwischen fast
nicht mehr ernst nehmen, wenn es um Linux und insbesondere um Mac OS
X geht. Da werden aus eigentlich nicht erwähnenswerten
Programmabstürzen, in fast panikmachender Form, kritische
Sicherheitslücken. Egal wie seriös die Quelle auch immer sein mag, es
wird daraus eine Meldung. Liegt dieses eventuell am Sponsor?

Betrachten wir exemplarisch zwei der angeblichen Sicherheitslücke:

1. BOM ArchiveHelper .zip Heap Overflow:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x756e8897
[Switching to process 411 thread 0x3a03]
0x94498c14 in BOMStackPop ()
(gdb) bt
#0 0x94498c14 in BOMStackPop ()
#1 0x944994e4 in _copyDir ()

Der obige Auszug aus dem Error-Log zeigt eindeutig, dass die
Anwendung versucht auf einen geschützten Speicherbereich zu
zugreifen, mit der Folge, dass die Anwendung vom System ins Nirvana
geschickt wird. Wo ist da bitte schön die Sicherheitslücke?

2. "Apple OS X 10.4.6 .tiff"-Fehler

Jede tiff-Datei fängt mit einer 2 Byte-Folge an, die die Byte-Order
festlegt und zwar einmal "II" für little endian und "MM" für big
endian. Diese Zeichenkette wurde durch eine ungültige ersetzt,
wodurch sich folgender Error-Log ergibt:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
Cannot access memory at address 0x0
#1 0x91c71da4 in _cg_TIFFSetField ()
Cannot access memory at address 0x0
#2 0x91c73390 in TIFFFetchNormalTag ()

Wie man leicht sieht, handelt es sich bei dem Fehler lediglich um
einen nicht abgefangenen Nullpointer! Ein Zeichen dafür, dass
irgendetwas in einer Anwendung nicht initialisiert werden konnte, wo
soll da bitte ein Sicherheitsrisiko sein?

Jede Programmiersprache die Zeiger kennt, besitzt auch ein
Sprach-Attribut "NULL" oder auch "NIL", den so genannten Nullpointer.
Dieser wird immer dann von einer Funktion zurückgeliefert, wenn es
für die übergebenen Eingangsparameter keine gültiges Resultat gibt.

Also ganz einfach ausgedrückt, man stopft die Zeichenkette "MM" in
die Funktion und erhält den Dekodierer für "big endian" und bei "II"
den Dekodierer für "little endian". Bei jeder anderen Zeichenkette
wird ein Nullpointer zurückgeliefert, wodurch der Absturz
vorprogrammiert ist.

Dieses als mögliches Sicherheitsrisiko hinzustellen ist einfach nur
peinlich und zeugt nur davon, dass der entsprechende Herr/Dame keine
Ahnung von Software-Entwicklung hat.

Mag sein, dennoch zwei Anmerkungen dazu, die ich auch schon weiter oben ansprach:

1. Die Vergangenheit, unabhängig vom Betriebssystem, zeigt, dass schadhafter Code oftmals über zum Absturz gebrachte Applikationen ins System geschleust werden kann. Alles, was im Kontext des angemeldeten Benutzers läuft, ist dann prinzipiell gefährdet.

2. Wenn die auch schon vorher von Ferris aufgezeigten Bugs "so ungefährlich" gewesen wären, hätte Apple doch gar nicht darauf reagieren müssen – denn immerhin gab es auch im April keine Details zu den Möglichkeiten, die sich ergeben könnten.
Da die Bugs, die Ferris aufdeckte, aber auch von Apple als Lücken eingestuft wurden und mit dem letzten Security-Update (teilweise) gefixt wurden, waren es wohl doch "eventuell ausnutzbare Bugs".

Zugegeben, reine Spekulation. Und mit 10.4.7 hoffentlich abgehakt.

Ach und 3.: Die "Qualität" von Bug-Fixes lässt offensichtlich auch bei Apple zu wünschen übrig, siehe Posting vom 17.05.06 um 23:32.
Und blicken wir auf den Anfang dieses Threads, zeigt sich dort auch ein Bug, der mit dem Security-Update 002-2006 gefixt sein sollte, aber offensichtlich auch nur "geflickschustert" war.

4. Wäre noch die Reaktionszeit seitens Apple (stellenweise Monate) bzw. die allgemeine Herangehensweise (Stichwort: "Security by Obscurity") zu bemängeln… Aber das führt sicher zu weit bzw. zu nichts.

…und bei mir jetzt zum Ausklinken (Abmelden der Benachrichtigung) hier.


(Und Dank an Aronnax für die konkret nachvollziehbaren Beispiele oben.)

Na dann - auch noch mal eine Anmerkung

Apple fixt diese Dinge bestimmt alleine schon deshalb, um solche Theads wie diesen hier nicht ausarteten zu lassen - einfach Imagepflege sozusagen

Wenn man Safari damit ab saufen lassen kann, reicht das schon als Grund den Fehler zu beheben - ist dann auch ganz egal ob es eine potentielle Lücke sein könnte

----
und ansonsten
ich will ja nicht behaupten, das ich hier ein großer "Sicherheitsexperte" bin - zumindest verfolge ich es seit langen und da gibt es eigenes, was immer wieder auffällt. Nur ein winziger Bruchteil der gefundenen Lücken wird überhaupt jemals ausgenutzt und somit zu einer echten Gefahr. Zum einen liegt das daran, dass es sehr häufig extrem kompliziert ist, diese auch in praktischer Anwendung zu überführen - z.B. weil zu viele Schritte notwendig sind (zum Teil nur wenn der Nutzer ganz bestimmte Schritte in bestimmter Reihenfolge ausführt) u.s.w.

ist dann auch der Grund warum das Lesen dieser Lücken sehr lustig sein kann - die Leute kommen häufig auf die seltsamsten auf Dinge - denken nicht selten um sieben Ecken, irgendwie

----

Bei deinen Beispielen hat auch noch niemand den nötigen zweiten Schritt auch nur teilweise angedacht. Ziemlich viel Wind um fast gar nichts würde ich mal sagen. Wenn man sich immer so lange um ungelegte Eier kümmert, kommt man übrigens nicht mehr dazu die bereits gelegten auszubrüten

Da hast Du auch wieder recht…

Marcel_75@work
Ursache und Wirkung verdreht.

* Zum Einschleusen von Code werden gerne Pufferüberläufe verwendet. Manchmal, aber nicht zwingend, kann ein Programm dabei abstürzen.

* Ein Programmabsturz an sich führt in keiner Weise zur Möglichkeit, irgendwelchen Angriffscode einschleusen und ausführen zu können.

* Ein Programmabsturz an sich bedeutet nicht zwingend, daß das Programm Ziel eines Angriffs war.

Oder anders formuliert: Wenn Schadcode eingeschleust wird, dann kann ein Programm abstürzen, muß es aber nicht. Ein Programmabsturz ist also eine mögliche Auswirkung des Angriffs. Ein Programmabsturz ist nicht die Quelle, sondern allenfalls das Resultat eines Angriffs.

Apple nennt fremde Helfer in Begleittexten zu Sicherheitsupdates. Zeig mir mal die Stelle, wo sein Name steht.
So ist es.

Habe mit Tom Ferris Kontakt aufgenommen, hier Auszüge aus seiner Mail:


I can speak for all of the issues I reported on my site. All of them are
in fact security issues, which even Apple has acknowlegded this within the
release notes of Security Update 2006-003. Example of the BOM Issue:

"Impact: Expanding an archive may lead to arbitrary code execution"

The latest bmp issue I reported is the same issue I reported to Apple a
few months ago. The problem is that, Apple did not fix the core issue of
that flaw as I stated on my blog.

[…] any type of heap overflow, int overflow, stack overflow, buffer
overflow will _always_ have a application seg fault.


> […] people want to see some credits to you from Apple, but within this
> Security Update 2006-003 informations
>
>
>
> and also this QuickTime 7.1 Update informations
>
>
>
> I can only find credits to Damien Bobillot, Brent Simmons of NewsGator
> Technologies, Inc., Tobias Hahn of HU Berlin, Ben Low of the University of
> New South Wales, Mike Price of McAfee AVERT Labs and ATmaCA,
> Mu Security research team, eEye Digital Security.
>
> So Apple "forgot" you, Tom Ferris or Security-Protocols?

Apple stated in many emails that they would _not_ give me credit on the
advisory if I did not abide they there disclosure policy. So, since I
released the advisories on my site they did not give me credit. Which is
fine... I would rather let the community know that issues do exist
within OS X, and Apple has been notified over 3 months ago. So you know
have detailed information to mitigate the issues until Apple releases a
patch.

> A lot of people […] say, that you never showed a real security-hole but
> only bugs, because you never showed, how these bugs could be exploited.
>
> So […] people […] say, that an application-crash not
> afford malicious-code-execution.

Well, people always love to say these kinds of things. What they need to
do is, read Apples Security Update 2006-003 release notes a little closer.

I hope this helps...

Marcel_75@work
Dann lies mal eine passende Stelle daraus vor.

MacMark, das ist doch nun wirklich nicht so schwer…

Was er höchstwahrscheinlich meint (u.a.), ist z.B. folgender Hinweis:

AppKit, ImageIO
CVE-ID: CVE-2006-1982, CVE-2006-1983, CVE-2006-1984

Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.6, Mac OS X Server v10.4.6

Impact: Viewing a maliciously-crafted GIF or TIFF image may lead to arbitrary code execution

Description: The handling of malformed GIF or TIFF image may lead to arbitrary code execution when parsing a maliciously-crafted image. This affects applications that use the ImageIO (Mac OS X v10.4 Tiger) or AppKit (Mac OS X v10.3 Panther) framework to read images. This update addresses the issue by performing additional validation of GIF and TIFF images.

Der erste Satz dieser Beschreibung kommt von Apple höchstpersönlich und sagt eindeutig aus, dass beliebiger Code ausgeführt werden könnte!


Auch bei BOM (CVE-ID: CVE-2006-1985) und vielen anderen:

An attacker may be able to trigger a heap buffer overflow in BOM. This may result in arbitrary code execution.


Ich frage mich ehrlich gesagt wirklich, was es da noch zu diskutieren gibt, wenn Apple selbst so etwas schreibt!

may != can

Das ist mir klar und dies habe ich auch nie angezweifelt…

May heißt, es könnte, aber es ist nicht nachgewiesen. Also kein Nachweis, daß es möglich ist bzw. daß man definitiv "kann".

Wenn Ferris sich schon nicht mit Apple arrangieren will, dann kann ja auch gleich einen Exploit erstellen, denn daß würde ja in seinem Sinne 1. eine Lücke beweisen und 2. Apples Arbeit beschleunigen. Daß er es trotzdem nicht tut bedeutet wohl, daß es nicht möglich ist oder zu schwierig für ihn.

May heißt, es könnte, aber es ist nicht nachgewiesen. Also kein Nachweis, daß es möglich ist bzw. daß man definitiv "kann".

Wenn Ferris sich schon nicht mit Apple arrangieren will, dann kann er ja auch gleich einen Exploit erstellen, denn das würde ja in seinem Sinne 1. eine Lücke beweisen und 2. Apples Arbeit beschleunigen. Daß er es trotzdem nicht tut bedeutet wohl, daß es nicht möglich ist oder zu schwierig für ihn.

Aber dazu forderst Du ihn bitte auf…

So, ich muss diesen Thread aus gegebenen Anlass leider wieder an die Oberfläche holen...

Da hat sich Apple nun so viel Zeit gelassen mit dem Update auf 10.4.7 und auch das WebKit wurde ja gefixt bzw. Safari von 2.0.3 (417.9.3) auf 2.0.4 (419.3) aktualisiert…

Und dennoch wurden diese Bugs nicht behoben!



Hier stürzt Safari nach wie vor sofort ab!



Und hier muss man Ctrl + a drücken um Safari crashen zu lassen.

Vielleicht wird es ja erst mit einem kostenpflichtigen Update auf 10.5.x gefixt...

Also das wundert mich ja so: In einem "daily build" von vor ca. 3 Wochen funktionierte es schon einmal ohne Absturz.

Hab jetzt aber keinen aktuellen getestet…

Theoretisch erwarte ich ja nichts weiter, als das Safari auch bei solchen fehlerhaften Seiten "stabil bleibt" und nicht einfach ohne Vorwarnung abstürzt...

Zumal Firefox, Opera usw. keine Probleme mit diesen Seiten haben. (Und auch OmniWeb war (ist?) nicht von diesem Problem betroffen, obwohl dies auch auf WebKit aufbaut.)

PS: Hatte es Ende Mai / Anfang Juni mit dem "sneaky peak 12" von OmniWeb 5.5 getestet. Und auch mit dem aktuellen "sneaky peak 16" stürzt OmniWeb bei den beiden Seiten nicht ab!

2nd PS: Zitat aus dem Drunkenblog "it's in their system, and fixed in the nightly builds, which means this page won't crash in a forthcoming version of Safari".

Tja, so kann man sich täuschen...

Mir ist es unbegreiflich, warum es in den nightly builds von Safari gefixt ist (oder war?), und in einer finalen Version nach wie vor nicht! amp;

Ach und noch etwas: Apple hat wieder einmal Sicherheitsaktualisierungen abseits der Security-Updates vorgenommen (in dem Fall in 10.4.7 integriert).



Warum ich dies bedenklich finde, hatte ich in diesem Thread am 22.04.06 um 09:17 beschrieben.

Das aktuelle WebKit vom 28.06. lässt sich bei mir leider nicht starten:



Funktioniert es bei jemand anderen und kann sie / er es mal testen mit den beiden Links? Danke!

Marcel_75@work
Das funzt genauo wie den vorhergehen problemlos bzw. die Bugs sind weiterhin raus

übrigens
"Mir ist es unbegreiflich, warum es in den nightly builds von Safari gefixt ist (oder war?), und in einer finalen Version nach wie vor nicht!"

Steht irgendwo, das es Änderungen in 10.4.7 auch für Safari gibt?
Nein, du solltest dich also, wenn überhaupt nur darüber aufregen das sie sich soviel Zeit damit lassen. Ansonsten ist es doch normal, das Bugs in Entwicklerversionen bereits Monate vorher gefixt werden - zu sehen bekommt man das Ergebnis eben erst wenn auch sonst alles getestet haben.

Aronnax
Ja, auch Safari wurde aktualisiert.

Hier auch noch einmal der direkte Link zu Apple:



.
.
.
- Address Book, AppleScript, Automator, Dictionary, Font Book, iCal, iChat, DVD Player, Keynote, Mail, Preview, Safari, and Stickies
- Disk Utility, Keychain Access, Migration Assistant, and Software Update
.
.
.

Davon abgesehen hatte ich es ja bereits heute um 11:23 geschrieben:
... Safari von 2.0.3 (417.9.3) auf 2.0.4 (419.3) ...

PS: Danke für den Test mit dem aktuellen Nightly Build.

Habe heute übrigens auch noch einmal den nightly build vom 29.06. probiert und kann bestätigen – beide Links führen damit nicht mehr zum Absturz (wie auch schon die nightly builds Anfang Juni).

Schade nur, dass die Safari-Version in 10.4.7 noch nicht so stabil ist – warten wir also auf 10.4.8…

So, aktueller Stand nach dem 10.4.8-Update:

Hier



stürzt Safari nun nicht mehr ab.


Aber hier



crasht Safari nach wie vor, nachdem man Ctrl + a gedrückt hat… amp;

MacMark

Trotz installierten Security-Update 2006-007 funktioniert das hier leider immer noch:



(Ctrl + a drücken…)

Auch die kürzlich aufgetauchten manipulierten DMGs führen nach wie vor zu einem eingefrorenen Mac bzw. einem Kernel Panic…

Und gestern kam beim "Month of the Kernel Bug" der 8. Fehler in Mac OS X zu Tage:

Aronnax

Dein Humor ist klasse.

Lachmichschlapp
Premker

macmark
kein wunder das die jungs von sy...a
so froh waren als du die firma verlassen hast....
deine rechthaberei wird irgendwann jedem unerträglich.

Marcel_75@work Geht's mit den Daily Builds von Safari oder auch da vorhanden?

Nun, vielleicht hat die Änderung andere Nebenwirkungen. Wird nicht so leicht sein an einer Renderengine was zu ändern ohne das 1000 kaputte Webseiten dann wieder nicht mehr gehen. Hätten Netscape und M$ nicht den fehlertoleranten Browser erfunden hätten wir heute nicht so einen Irrsinn...