Virus oder Trojaner installierbar, wenn man USB Stift einsteckt?

[MacMark]

Ich hatte diese Stelle sehr wohl gelesen, die Frage war etwas provokanter Natur, da die DOS Schiene tatsächlich einen monolithischen Kernel hatte, ebenso wie frühe UNIX Versionen.

Gut, dann hier ein Zitat aus einer Quelle, die es am besten Wissen muss: Win NT Architecture

Unix oder nicht Unix hat nichts mit Kerneldesign zu tun.

Liest Du auch Deine Quellen? Sehen wir mal da rein:

NT 3.5.1 war schon ziemlich monolithisch, weil es viele Dienste im Kernel laufen hat:
"From its earliest days Windows NT has implemented its memory manager, integrated cache manager, file systems (including network redirectors), object/security manager, network protocols, network server, and all thread/process management as kernel-mode subsystems while retaining a highly modular design."

Eine Mikrokernel-Architektur hingegen hat beispielsweise Dateisysteme im Userspace, aber das schreibt Mircosoft auch selbst:
"In a pure microkernel operating system the file system implementation is run in user mode, so theoretically it can't crash the entire operating system."

NT 4.0 wurde noch monolithischer, weil es weitere Dienste, unter anderem die GUI, auch noch in den Kernel verlegte:
"… because the graphics and windowing subsystems have a very high rate of interaction with hardware …, the Windows NT 4.0 design team decided to move that common functionality from user mode into kernel mode. … With this new release, the Window Manager, GDI, and related graphics device drivers have been moved to the Windows NT Executive running in kernel mode. … In the current change, a set of services previously implemented in user mode are now operating in kernel mode. "

Und sie haben sogar vorausgeahnt, was später passieren würde: Bugs in der GUI (!) gefährden ab NT 4.0 den Kernel und damit das gesamte System:
"One of the side effects of this change is that now Window Manager, GDI, and graphics drivers have the potential to write directly to other spaces within the Executive, and thereby possibly disrupting the stability of the whole system."

Und wie ich ebenfalls auf meiner Seite schreibe, haben sie die Architektur der Performance geopfert:
"So what does moving Window Manager and GDI from their place as user-mode subsystems to kernel-mode Executive services really mean to the user? To the administrator? To the systems developer? Simply put, the move delivers improved performance and increased functionality with a decrease in memory requirements!"

 

[astrophys]

Was ein Unix ist, ist nicht genau definiert. Es gibt etwa 376 verschiedene Unices, was ein Grund dafür war, dass MS mit seinem NT System so erfolgreich wurde.

Aus meiner zitierten Quelle hast du deine Auszüge jedenfalls nicht. Sehen wir uns Auszüge aus meiner Quelle einmal an:

"In the Windows NT Workstation 4.0 release, the Window Manager and GDI processes are still protected because applications cannot write to memory locations occupied by kernel mode code and data, as is shown above."

"Consequently, there is no change in stability or reliability resulting from poorly behaved applications, because kernel-mode code and data is protected by the Windows NT architecture and the processor's memory protection system."

"Note that in this respect of total isolation of critical operating system data from user-mode application code, Windows NT Workstation 4.0 remains unchanged in being architecturally more robust than other PC-based operating systems, such as Microsoft Windows 95, IBM OS/2 Warp, and Apple Macintosh operating systems."

"From an architectural standpoint, Windows NT continues to be a modified microkernel operating system. In fact, the kernel itself is largely unaffected by this change. It is a testament to the architectural design of Windows NT that a change like this to a critical operating system component can be made without major structural changes."

Und einen Kernel "Nanokernel" zu nennen ist eine schöne Wortschöpfung ohne weitere Informationen. Wie wärs mit Piko oder Femtokernel, oder, besser noch iKernel

 

[MacMark]

Was ein Unix ist, ist nicht genau definiert.

Wenn Du etwas nicht weißt, dann benutze doch bitte vor dem Antworten eine Suchmaschine, um wenigstens die ganz groben Peinlichkeiten zu vermeiden. ;-)

Natürlich ist genau spezifiziert (siehe auch meine Seite dazu), was ein Unix ist: In der "Single UNIX Specification V3".

Aus meiner zitierten Quelle hast du deine Auszüge jedenfalls nicht.

Du liest Deine Quellen tatsächlich nicht selbst, unglaublich. Natürlich sind die Auszüge aus "Deiner" Quelle. Und wenn Du mal darin danach suchen würdest, würdest Du sie auch wiederfinden.

Sehen wir uns Auszüge aus meiner Quelle einmal an:

Danke, aber ich kenne den Artikel vollständig, offenbar im Gegensatz zu Dir. Sie beschreiben, was NT von einer Mikrokernel-Architektur unterscheidet und warum sie beim Wechsel von NT 3.5.1 auf NT 4.0 noch weiter von einer Mikrokernel-Architektur abgewichen sind und den Window-Manager und weitere Dienste in den Kernelspace geschoben haben.

Ich kenne kein Betriebssystem, welches mehr Aufgaben im Kernel laufen hat als Windows. Oder kennst Du noch eines, bei dem ein Window-Manager und ein Webserver im Kernelspace liefen? Monolithischer geht es nur noch, wenn man Word und Excel auch noch in den Kernel integrieren würde … oder den Internet Explorer.

Und einen Kernel "Nanokernel" zu nennen ist eine schöne Wortschöpfung ohne weitere Informationen. Wie wärs mit Piko oder Femtokernel …

Das ist keine Wortschöpfung, denn diese gibt es tatsächlich. Und die Namen sind nicht von Apple. Hauptsächlich geht es um die Größe.

 

[astrophys]

Wenn Du etwas nicht weißt, dann benutze doch bitte vor dem Antworten eine Suchmaschine, um wenigstens die ganz groben Peinlichkeiten zu vermeiden. ;-)

Natürlich ist genau spezifiziert (siehe auch meine Seite dazu), was ein Unix ist: In der "Single UNIX Specification V3".

Entweder du tust nur so, oder du weisst wirklich nicht, was ich meine....

Du liest Deine Quellen tatsächlich nicht selbst, unglaublich. Natürlich sind die Auszüge aus "Deiner" Quelle. Und wenn Du mal darin danach suchen würdest, würdest Du sie auch wiederfinden.

Ich kenne den Artikel. Deine Zitate verfälschen allerdings die Aussage des Artikels

Danke, aber ich kenne den Artikel vollständig, offenbar im Gegensatz zu Dir.

Möglich, deine angeführten Zitate sind allerdings nicht dazu geeignet, den Inhalt sachlich wiederzugeben.

Das ist keine Wortschöpfung, denn diese gibt es tatsächlich. Und die Namen sind nicht von Apple. Hauptsächlich geht es um die Größe.

Sicher ist das eine Wortschöpfung und ich habe nirgendwo geschrieben, dass der Begriff von Apple stammt. Lies mal den Artikel von Jonathan Shapiro, in dem er den Begriff einführt. Und dann musst vielleicht auch du Schmunzeln und verstehst, was du da eigentlich auf deiner Seite so geschrieben hast.

Ich respektiere ja deine Fleißarbeit, um zu zeigen, dass Apple das ultimative System erschaffen hat, welches ausschließlich Vorteile aufweist. Ich weiß nicht, warum du das tust, bin mir aber ziemlich sicher, dass du noch nie ein Betriebssystem auf die Beine gestellt hast. Wenn man auf deiner Seite liest, dann versteht man sehr schnell, dass hier ein glühender Applefan am Werk ist, der seine Quellen und Zitate sehr einseitig auswählt.

Was ein Mikrokernel ist, ist weit gefasst. Manche Monolithischen Systeme werden nicht so genannt. Namen sind nur Schall und Rauch. Ein sehr schönes Beispiel darüber, welchen Kernel die Fachwelt für besser erachtet findest du hier.

Vielleicht verstehst du dann den akademischen Charakter der ganzen Diskussion.

 

[tau]

Hat jemand 'ne Idee für einen neuen Thread-Titel und in welches Forum ich ihn schieben soll?

 

[ProUser]

Höchstens in "OS X - UNIX" Unterforum, ich finde, hier passt es aber auch gut, denn es geht ja vorwiegend um die Sicherheit des Systems. Ein passenderer Titel ist mir aber auch noch nicht eingefallen, vllt. haben andere eine Idee..

 

[Dalgliesh]

Lieber MacMark!

Langsam wird Deine Seite sehr komisch: Du nimmst allen Ernstes die Tatsache, daß DU nicht in der Lage bist, einen Virus für MacOS X unter 10.5 und 10.6 zu KOMPILIEREN, als Beweis dafür, daß es schwierig ist, einen Virus für MacOS X zu schreiben??? Der Virus läßt sich, wenn ich Dich richtig verstehe, sehr wohl unter 10.4 kompilieren und läuft dann auch unter 10.5 und 10.6.

Idee: Wenn nun jemand kommt, der sich ein kleines bißchen besser auskennt als Du, könnte es nicht ganz eventuell möglich sein, daß er den Programmcode so anpaßt, daß das Kompilieren überhaupt kein Problem ist?

 

[meghi]

ich muss gestehen, ich hatte nicht die Energie, alle Beitraege hier zu lesen, von denen zu viele der Frage gewidmet sind "ist Apple das bessere Betriebssystem oder nicht" (Klar doch!) meine Frage: ich hab auf meinem Mac Windows XP in einer bootcamp partition installiert und greife darauf auch mit Parallels zu. Jetzt hab ich mir im Windows einen Trojaner eingehandelt und bin dabei, ihn zu erledigen.
Muss ich mir auch Sorgen um mein OSX machen? Wo muss ich nachsuchen ob das Teil sich auch dort eingenistet hat? (Trojaner: lt AVIRA TR/Spy.Gampass.LW)

 

[Rupp]

Windows hat keinerlei Schreibrechte auf die OSX Partition. Weder über Parallels noch wenn du nativ bootest. Ein Schädling kann sich also nich auf der OSX Partition „einnisten“.

 

[meghi]

Dein Wort in Gottes Gehoergang (oder in dem von Steve Jobs?) naja, ich hoffe mal dass es gut geht. Bei Windows ist die Sache klarer, denn da gibt es das Problem so haeufig, dass auch die Gegenmittel und Rezepte an jeder Ecke zu haben sind, und notfalls (ich hoffe es kommt nicht so weit) muss ich halt die Partition platt machen, wichtige Daten sind eh nicht drauf, nur Programme die es unter Mac nicht gibt...

 

[MacMark]

… Langsam wird Deine Seite sehr komisch: Du nimmst allen Ernstes die Tatsache, daß DU nicht in der Lage bist, einen Virus für MacOS X unter 10.5 und 10.6 zu KOMPILIEREN, als Beweis dafür, daß es schwierig ist, einen Virus für MacOS X zu schreiben??? Der Virus läßt sich, wenn ich Dich richtig verstehe, sehr wohl unter 10.4 kompilieren und läuft dann auch unter 10.5 und 10.6.

Ich habe mit dem Viren-Autoren gesprochen und er bestätigte meine Analyse. Er kann es selbst nicht. Außerdem ist das ja nicht der einzige Grund. Der Virenautor sagt selbst, daß es schwer ist, einen OS X Virus zu schreiben. Mein Artikel ist auch noch nicht fertig. Da kommen noch mehr (Hinter-) Gründe.

Idee: Wenn nun jemand kommt, der sich ein kleines bißchen besser auskennt als Du, könnte es nicht ganz eventuell möglich sein, daß er den Programmcode so anpaßt, daß das Kompilieren überhaupt kein Problem ist?

Klar, dann compiliert der Code, aber dann funktioniert die Infektion nicht mehr. Deshalb ist das die falsche Baustelle. Man müßte den Code des Compilers und Linkers anpassen, damit dieser Infektionsweg wieder übersetzbar ist. Wie bereits gesagt: Der Virenautor stimmte mir zu.

Und andere denkbare Infektionswege, die er versucht hat, sind gescheitert. Und er hat schon einige Viren geschrieben …

 

[below]

Der Virenautor sagt selbst, daß es schwer ist, einen OS X Virus zu schreiben. Mein Artikel ist auch noch nicht fertig. Da kommen noch mehr (Hinter-) Gründe.

Da warte ich mal, was da so kommt. Kannst Du sagen, wer der Virenautor ist?

Alex

 

[astrophys]

Er meint vermutlich Charlie Miller, einer der Autoren des Buches "The Mac Hacker's Handbook".

Es ist in diesem Zusammenhang ausserordentlich amüsant zu sehen, wie Macmark einen im Buch des Autors gefundenen Fehler in voller Breite auf seiner Homepage darstellt. Es ist üblich, dass Fachbücher mehr oder weniger Fehler enthalten. In der Regel wird ein gefundener Fehler per Email an den Autor geschickt und die Sache ist gegessen. Habe ich selbst schon mehrfach gemacht. Ich wäre aber nie auf die Idee gekommen, jeden Fehler auf meiner Website groß und breit darzustellen und mit die Irrtümer bekannter Professoren zu titulieren

Wie dieser Umstand zu bewerten ist, muss jeder selbst entscheiden.

 

[berbel01]

Der erste ernstzunehmende Virus ist da!!!!

>... ich bin en häcker aus Leipzig un dies iss en
>selbstprögrammirder bösartiger Gombjüdervirüs.

>Da isch noch net sö viel weiß vom Gombjüder iss des en manueller
>virüs.

>Also löschen se alle Dateien von de festpladde und schiggn se den
>virüs an alle die se gennen

>geht lös nü

 

[ProUser]

Er meint vermutlich Charlie Miller, einer der Autoren des Buches "The Mac Hacker's Handbook".

Es ist in diesem Zusammenhang ausserordentlich amüsant zu sehen, wie Macmark einen im Buch des Autors gefundenen Fehler in voller Breite auf seiner Homepage darstellt. Es ist üblich, dass Fachbücher mehr oder weniger Fehler enthalten. In der Regel wird ein gefundener Fehler per Email an den Autor geschickt und die Sache ist gegessen. Habe ich selbst schon mehrfach gemacht. Ich wäre aber nie auf die Idee gekommen, jeden Fehler auf meiner Website groß und breit darzustellen und mit die Irrtümer bekannter Professoren zu titulieren

Wie dieser Umstand zu bewerten ist, muss jeder selbst entscheiden.

Du hast anscheinend eine Leseschwäche: Auf MacMarks Webseite steht deutlich, dass er Charlie Miller u. Dino Dai Zovi darauf aufmerksam gemacht hat.

Und natürlich ist das nicht genug, denn die Bücher sind gedruckt und befinden sich im Umlauf, d.h. falsche Informationen wurden verbreitet! Dem muss/sollte natürlich entgegengewirkt werden, und es öffentlich richtig gestellt werden.

Und daran ist gar nichts amüsant. Das einzige, was wirklich amüsant ist, dass es Dich offenbar zu stören scheint..

 

[MacMark]

… Kannst Du sagen, wer der Virenautor ist? …

Habe ich dort.

Er meint vermutlich Charlie Miller, einer der Autoren des Buches "The Mac Hacker's Handbook".

Es ist in diesem Zusammenhang ausserordentlich amüsant zu sehen, wie Macmark einen im Buch des Autors gefundenen Fehler in voller Breite auf seiner Homepage darstellt. Es ist üblich, dass Fachbücher mehr oder weniger Fehler enthalten. In der Regel wird ein gefundener Fehler per Email an den Autor geschickt und die Sache ist gegessen. Habe ich selbst schon mehrfach gemacht. Ich wäre aber nie auf die Idee gekommen, jeden Fehler auf meiner Website groß und breit darzustellen und mit die Irrtümer bekannter Professoren zu titulieren

Wie dieser Umstand zu bewerten ist, muss jeder selbst entscheiden.

Nein, Charlie und Dino schreiben keine Viren. Die beiden suchen Schwachstellen und führen vor, wie man sie nutzt.

Ich hatte Charlie und Dino auf einen Fehler angesprochen. Charlie wußte es nicht besser und hat in seiner ersten Reaktion mir auch nicht glauben wollen. Ich habe ihm dann gesagt, wie er es prüfen kann und auch Dino (Co-Autor des Buches) hat ihm gesagt, daß ich richtig liege. Dann hat es Charlie eingesehen.

Charlie ist ein bekennender "narcissistic vulnerability pimp",

der jede (vermeintliche) Schwachstelle an die große Glocke hängt, um berühmt und reich zu werden. (Wenn Du daran Zweifel hast, frage ihn selbst.) Daher ist es nur fair, irrtümliche Schwachstellen auch genauso öffentlich zu korrigieren. Zumal es sogar etwas war, worauf er explizit in dem Buch herumreitet und was er mir erst nicht glauben wollte.

 

[below]

Nehmen wir das alles mal so hin: Dem Nutzer ist es doch wahrscheinlich ziemlich egal, ob das System durch einen Virus, oder einfach durch Öffnen einer harmlos erscheinenden Website infiziert wird.

Und wenn ich mir einerseits die Liste von geschlossenen Lücken im letzen Sicherheitsupdate ansehe, und andererseits sehe, dass bisher jede Version von iOS innerhalb kürzester Zeit ge-jailbreak-ed wurde, dann finde ich das Argument "Marktanteil" doch ziemlich valide.

Das iPhone hat einen hohen Marktanteil, es gibt eine Gruppe, die ein grosses Interesse an Sicherheitslücken hat (eben das devteam et.al) und, siehe da, sie finden auch immer wieder welche

Alex

 

[MacMark]

Die Schädlingsarten haben völlig andere Möglichkeiten und Grenzen.

Der Jailbreak basiert auf dem Austausch der Firmware, nicht auf einem Sicherheitsfehler. Das Vorgehen setzt Hardware-Zugriff oder wahlweise root voraus.
Das "Jailbreak-Me"-Ding nutzte einen (jetzt gefixten) Bug, um auf root zu eskalieren.

Das iPhone ist ein Paradebeispiel für Angriffe trotz geringem Marktanteil: SSH Wurm gegen 1,2% aller Smartphones und weniger als 0,3% aller Mobiltelephone.

 

[below]

Der Jailbreak basiert auf dem Austausch der Firmware, nicht auf einem Sicherheitsfehler. Das Vorgehen setzt Hardware-Zugriff oder wahlweise root voraus.

Wenn ich richtig informiert bin, dann ist genau der Austausch der Firmware nur möglich, wenn es eine Sicherheitslücke im iPhone gibt. Aber ich kann mich irren.

Und das Argument mit dem SSH Wurm ist ja doch etwas merkwürdig. Hier wird eine wirklich extrem einfach auszunutzende Lücke angegriffen. Da muss ich nur einen IP Block abgrasen, das kann ein minderbegabtes Script-Kid.

Was sagst Du denn zu den von Apple geschlossenen Lücken, die Angriffe über Webseiten erlaubt haben? Gibt es hier einen Vergleich mit Problemen in z.B. IE oder Firefox?

Alex

 

[MacMark]

Jailbreak funktioniert so: Das iPhone bekommt seine neue Firmware von iTunes per Kabel. Man lädt also erstmal die neue Original-Firmware-Version von Apple runter auf die Mac-Platte. Dann verändert man diese Firmware, wie man sie haben möchte mit den bekannten Tools. Die Tools beseitigen in der Firmware die Prüfung der iPhone-Apps. Dann spielt man mit iTunes die neue Firmware von Platte auf das iPhone, aber nicht das Original, sondern die gerade veränderte Firmware. Das iPhone ist in dem Moment nur ein externes Speichermedium. Der Unterschied ist lediglich, daß die Firmware verändert wird, bevor man sie aufs iPhone kopiert. Der Vorgang und der Effekt sind vergleichbar mit dem Einspielen einer "region-free" Firmware ins DVD-Laufwerk. Das kann sich auch nicht dagegen wehren, weil es ein vorgesehener Vorgang ist. Und anschließend kann es mehr abspielen.

Meine Ansicht ist, daß angegriffen wird, was angreifbar ist, unabhängig vom Marktanteil. Die Viren (-Versuche), die ich mir für OS X angesehen habe, sind entstanden, um rauszufinden ob es geht und wie es geht.

Ein Skript-Kiddie kann so einen iPhone-SSH-Wurm nicht erstellen, weil es das iPhone nicht programmieren kann. Der Wurm hat sich per SSH rüberkopiert, installiert und selbsttätig weiterverbreitet. Dafür gab es keinen Baukasten, jedenfalls nicht fürs iPhone. Skript-Kiddie bedeutet ja, daß es ein fertiges Programm oder Skript gibt, was ein Kind nur noch auszuführen braucht ohne selbst programmieren zu müssen.

Der web-basierte Jailbreak war der Super-GAU. Eine besuchte Webseite konnte offenbar Code einschleusen und diesen unter root-Rechten laufen lassen. Allerdings ist der SSH-Wurm für gejailbreakte und mit Standard-Paßwort laufende iPhones noch schlimmer, weil er keine Mithilfe des User braucht. Beide Exploits machen nichts Böses, aber es wäre leicht gewesen, sonstwas Beliebiges zu machen. Ich fand erschreckend, daß sich die Leute über Jailbreak-Me per Web gefreut haben. Denen war nicht bewußt, daß jede Website die volle Kontrolle über ihr iPhone haben könnte.

Der Angriff über Webseiten ist nicht allein über Safari möglich, denn Safari läuft nicht unter root, sondern unter einem User namens "mobile":

MacMarkiPhone:~ root# ps axj | sort 
USER       PID  PPID  PGID   SESS JOBC STAT   TT       TIME COMMAND
_mdnsresponder    13     1    13 c1ebfaf8    0 Ss     ??    2:11.93 /usr/sbin/mDNSResponder -launchd
_securityd  2036     1  2036 c1ebf750    0 Ss     ??    0:00.28 /usr/libexec/securityd
mobile      17     1    17 c1ebf618    0 Ss     ??    1:20.30 /usr/sbin/BTServer
mobile      24     1    24 c30ef750    0 Ss     ??    1:26.13 /usr/sbin/mediaserverd
mobile      28     1    28 c30ef4e0    0 Ss     ??    0:09.09 /usr/sbin/accessoryd
mobile      29     1    29 c30ef270    0 Ss     ??   20:22.63 /System/Library/CoreServices/SpringBoard.app/SpringBoard
mobile      49     1    49 c30efaf8    0 Ss     ??    7:16.24 /System/Library/PrivateFrameworks/ApplePushService.framework/apsd
mobile      88     1    88 c1ebf4e0    0 Ss     ??    1:17.42 /Applications/MobilePhone.app/MobilePhone
[B]mobile      96     1    96 c30ef618    0 Ss     ??    0:42.54 /Applications/MobileSafari.app/MobileSafari
[/B]mobile     359     1   359 c30efea0    0 Ss     ??    4:39.97 /Applications/MobileMail.app/MobileMail
mobile    1549     1  1549 c30efd68    0 Ss     ??    0:03.37 /Applications/MobileMusicPlayer.app/MobileMusicPlayer
root         1     0     1 c1ebfea0    0 Ss     ??    1:01.41 /sbin/launchd
root        12     1    12 c1ebfc30    0 Ss     ??    0:47.81 /usr/sbin/notifyd
root        14     1    14 c1ebf9c0    0 Ss     ??    3:04.63 /usr/sbin/syslogd
root        15     1    15 c1ebf888    0 Ss     ??   26:35.09 /usr/libexec/configd
root        19     1    19 c1ebf3a8    0 Ss     ??    0:00.17 /usr/bin/sbsettingsd
root        23     1    23 c1ebf138    0 Ss     ??    0:51.44 /usr/libexec/lockdownd
root        27     1    27 c30ef3a8    0 Ss     ??    0:01.03 /usr/sbin/fairplayd
root        33     1    33 c30ef9c0    0 Ss     ??    7:44.39 /System/Library/PrivateFrameworks/CoreTelephony.framework/Support/CommCenter
root        50     1    50 c30efc30    0 Ss     ??    0:55.29 /System/Library/Frameworks/SystemConfiguration.framework/SCHelper
root      2024     1  2024 c1ebfd68    0 S      ??    0:01.03 /usr/sbin/sshd -i
root      2025  2024  2025 c30ef888    0 Ss   s000    0:00.22 -sh
root      2037     1  2037 c1ebf000    0 Ss     ??    0:00.08 /usr/sbin/mDNSResponderHelper
root      2038  2025  2038 c30ef888    1 R+   s000    0:00.01 ps axj

Demnach ist zwingend ein Bug außerhalb von Safari nötig, der lokalen Code auf root eskaliert. Der lokale Code wurde per Safari durch einen Safari-Bug reingebracht und dann durch einen System-Bug eskaliert. Andere Browser ermöglichten auch schon das Einschleusen von Code und könnten Safari problemlos vertreten.

Kurz recherchiert, hier sind die beiden Fehler. Einschleusen ging also über Anzeigen eines manipulierten PDFs in Safari. Eskalation auf root über einen Integer-Overflow im IOSurface.framework.