Kritische Sicherheitslücken in Mac OS X

S

spritebyte

Aktives Mitglied
Thread Starter
Dabei seit
16.10.2004
Beiträge
104
Reaktionspunkte
16
Hallo Leute.

Der folgende Beitrag bei Heise hat mich doch etwas beunruhigt.

http://www.heise.de/newsticker/meldung/72245

Weiß jemand, wie ich feststellen kann, ob ich einen Trojaner auf der Platte habe und auch, wie ich ihn wieder loswerden kann?

Viele Grüße

spritebyte
 
1. Gabs schon
2. Aaaaalt
3. Du hast keinen Trojaner
4. Du hast wirklich keinen Trojaner
5. Nein, wirklich nicht
 
spritebyte schrieb:
Weiß jemand, wie ich feststellen kann, ob ich einen Trojaner auf der Platte habe und auch, wie ich ihn wieder loswerden kann?
Zum Vergrößern anklicken....
Das weiss derzeit noch niemand da der "Trojaner" noch gar nicht in der freien Wildbahn aufgetaucht ist.
Ausser Tom Ferris, der seine Beobachtungen anscheinend an Apple weitergeleitet hat, scheinen diese "Sicherheitslücken" unbekannt oder bereits behoben zu sein.

Solution:
This issue was silently fixed by Apple in update 10.4.6.
http://docs.info.apple.com/article.html?artnum=303411
 
najah....alte windas gewohnheiten eben.........
 
Man kann die Lücke nutzen um einen Trojaner zu installieren. Das heißt nicht das es jetzt schon einen gibt...
 
Lua schrieb:
Ausser Tom Ferris, der seine Beobachtungen anscheinend an Apple weitergeleitet hat, scheinen diese "Sicherheitslücken" unbekannt oder bereits behoben zu sein.
Zum Vergrößern anklicken....
Übrigens schon im Januar!!
 
Na, wunderbar! Ja, das scheint wirklich noch die alte Windows-Paranoia zu sein!
Vielen Dank für die Infos!
 
Hier noch schnell ein Kommentar aus dem Heise Forum der mir recht interessant erscheint, den ich aber mangels Fachkenntnis nicht beurteilen kann:

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?
Zum Vergrößern anklicken....

Ich hoffe ich verstosse gegen keine Forumregeln durch dieses Zitat.
 
Lua schrieb:
Hier noch schnell ein Kommentar aus dem Heise Forum der mir recht interessant erscheint, den ich aber mangels Fachkenntnis nicht beurteilen kann:
Zum Vergrößern anklicken....
Zu "2. "Apple OS X 10.4.6 .tiff"-Fehler":
Oh Gott, der Autor der Funktion war ein echter Superheld - mannoman, das bekommt man in der 10. Klasse Informatik beigebracht, was da missachtet wurde...
 
BalkonSurfer schrieb:
...mannoman, das bekommt man in der 10. Klasse Informatik beigebracht, was da missachtet wurde...
Zum Vergrößern anklicken....
Sorry, habe ich leider nie besucht. :(
Was wurde da von wem misachtet?
 
Jeder Mensch macht Fehler.

Der größte Fehler zur Zeit ist es die Programmiersprache C für sowas wie Bibliotheken usw. einzusetzen. Was man dort alles für sicheres Programmieren machen muss, ist einfach für so komplexe Systeme nicht mehr tragbar. Das ging vielleicht vor 20 Jahren mal... hier müssen modernere Wege ran und sei es C++. Dort hat man wenigstens etwas wie Typsicherheit und Exceptions.

Damals noch verständlich, da C++ alles andere als Plattformunabhängig war, aber dank GCC hat sich das heute auch erledigt. Klar ist es teuer "funktionierende" Systeme umzustellen, aber dann kann man es wenigstens richtig machen und dann hat man später nicht mehr so großen Ärger mit Sicherheitslücken in Form von Buffer-Overflows usw. Denn mit Sprachen wie C++ ist es relativ leicht eine Bereichsprüfung vorzunehmen. In der STL ist das auch alles drinnen...

Man muss es nur nutzen.
 
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?
Zum Vergrößern anklicken....
In der heise Meldung steht, daß sich die ZIP-Lücke zur Code-Einschleusung auf -Ausführung missbrauchen lässt. Schlimmer geht es nicht. Es steht klipp und klar in der heise-Meldung; die aktuelle c´t hat sogar einen interessanten Artikel, wie Heap-Overflows im Detail funktionieren. Und Stack-Overflows werden mittlerweile sogar in der wikipedia demonstriert.

Darauf geht der "Kommentator" nicht ein. Genauso wenig wie die I...... von macdailynews.com, bei denen die Advisories von security-protocols unter "minor flaws" laufen.
 
Zuletzt bearbeitet:
BalkonSurfer schrieb:
Oh Gott, der Autor der Funktion war ein echter Superheld - mannoman, das bekommt man in der 10. Klasse Informatik beigebracht, was da missachtet wurde...
Zum Vergrößern anklicken....
Deinen Informatikunterricht hätte ich gerne...
 
Sry - hab den Artikel nicht rechtzeitig gesehen und jetzt nen 2. Thread angefangen - evtl. kann sich ja einer der Mods drum kümmern.

Übrigens: Richtig ist das Ferris diese Lücken bereits im Januar mitgeteilt hat.

Falsch ist das sie "silently" fixed sind - _jede_ einzelne der aktuellen Lücken kann ich auf meinem voll-gepatchten System nachvollziehen.

Windows Paranoia ist meiner Meinung nach mehr als gerechtfertigt.

bye
defa
 
defa schrieb:
Falsch ist das sie "silently" fixed sind - _jede_ einzelne der aktuellen Lücken kann ich auf meinem voll-gepatchten System nachvollziehen.
Zum Vergrößern anklicken....
Der Vollständigkeit halber:
Sie wurden mit dem aktuellen Security Update 2006-003 gefixt berichtet Tom Ferris auf den sich die Meldung auf Heise bezog.
 
Jo hab die Heise-Mail nochmal ausprobiert, und es öffnete sich diese Meldung:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten