macOS: Mögliche Malware durch modifizierte Beschreibungsdateien

Bereits vor OS X setzten NeXT-Systeme auf Beschreibungsdateien im Property-List-Format – und Apple übernahm in OS X das Konzept dieser Dateien, welche sich auf allen Apple-Plattformen wiederfinden. Zwar führte Apple zwei neue Formate (Binär oder XML) ein, doch der Aufbaue ist nach wie vor sehr ähnlich. Diese plist-Dateien werden zum Beispiel genutzt, um Nutzervoreinstellungen zu speichern oder als Beschreibungsdatei für Apps, in denen sich die Versionsnummer, der Entwickler und die unterstützten Dateiformate wiederfinden.


Leider sind die Methoden, welche Apple zum Auslesen dieser plist-Dateien verwendet, alles andere als sicher: Bereits die Manipulation von einzelnen Bytes in diesen Dateien führt zum Absturz des Programms, welches die Datei lesen soll. Dies fanden nun Sicherheitsforscher von OSCartography heraus und veröffentlichten einen Bericht zu diesem Thema.

Falscher Eintrags-Typ
Für einen Absturz genügt es bereits, im Binärformat den Typ eines Eintrages auf einen unsinnigen Wert zu ändern: Statt einer Zeichenkette passt man den Typ auf "Datum" an – und schon verabschiedet sich die Lesemethode und reißt den ausführenden Prozess mit in den Abgrund. Die Lesemethoden führen keine Typen-Validierung durch – daher kommt es hier zu abstürzen. Schon seit vielen Jahren trichtert Apple Entwicklern bei der Umsetzung von Lesemethodiken ein, sich genau gegen solche Angriffsvektoren zu schützen und bietet sogar Erweiterungen der eigenen APIs in Form des NSSecureCoding-Protocols an – doch hier beherzigt Apple die eigenen Ratschläge anscheinend nicht.

Alles nicht dramatisch?
Eine einzelne App durch die Anpassung einer Beschreibungsdatei zum Absturz zu bringen, ist nicht sonderlich spektakulär. Doch schleust man ins System eine App mit einer derart präparierten Beschreibung ein, hat das weitgehende Auswirkungen: Spotlight übernimmt die Beschreibung in den Index – und dadurch stürzen ständig die mds-Prozesse ("Meta-Data-Search", die Indexierungs-Prozesse von Spotlight) ab. Sogar ein Neustart behebt das Problem nicht.

Ferner führt dies auch zu Abstürzen des Launch-Services-Daemons "LDS", welcher sich kontinuierlich neu startet und weitere Betriebssystemfunktionen und unter Umständen auch sicherheitsrelevante Features beeinträchtigt. Somit ist es möglich, aus einem normalen Nutzerkonto wichtige Betriebssystem-Hintergrundprozesse zu stören und die Stabilität des gesamten Systems herabzusetzen.

Kommentare

aMacUser
aMacUser27.10.20 09:42
Wenn ich das richtig verstanden habe, dann wird im Zweifel "nur" das Betriebssystem instabil. Aber wirklich kritische Dinge (Code ausführen, feindliche Übernahme) gehen damit nicht.
+2
awk27.10.20 10:18
aMacUser
Wenn ich das richtig verstanden habe, dann wird im Zweifel "nur" das Betriebssystem instabil. Aber wirklich kritische Dinge (Code ausführen, feindliche Übernahme) gehen damit nicht.

Das ist wohl war. Es geschieht das, was die Ur-Viren gemacht haben, dein Rechner ist ohne Neuinstallation unbrauchbar, wenig tröstlich.
Und das schon wieder auf recht triviale Weise. Apple sind in letzter Zeit einige triviale Fehler unterlaufen. Einer Firma die sich Sicherheit auf die Fahnen schreibt dürfte derartiges nicht wiederholt unterlaufen.
+1
Mecki
Mecki27.10.20 12:29
aMacUser
Wenn ich das richtig verstanden habe, dann wird im Zweifel "nur" das Betriebssystem instabil. Aber wirklich kritische Dinge (Code ausführen, feindliche Übernahme) gehen damit nicht.
Nicht direkt, aber man kann solche Lücken als Grundlage nutzen, um derartige Angriffe zu entwickeln.

Ein Stacküberlauf führt im Normalfall auch nur dazu, dass der Prozess abstürzt. Direkt kann man damit also einen Nutzer nur ärgern. Aber wenn man den Stack gezielt im richtigen Moment auf die richtige Art überlaufen lässt, dann stürzt der Prozess nicht ab, aber man kann damit z.B. Code in den Prozess einschleusen, den man dann durch einen weiteren Überlauf an anderer Stelle zur Ausführung bringen kann.

Und fehlende Typsicherheit ist immer ein Problem, daher halte ich nichts von Sprachen, die das auch noch als einen Vorteil verkaufen wollen, weil das ist es nie in der Praxis. Es macht nur mehr Arbeit, wenn man es richtig machen will, es führt zu massiven Problemen, wenn man sich die Arbeit sparen will und es unterstützt schlechtes API Design, was man den APIs dann auch oft ansieht. Apple hat hier durchaus aus eigenen Fehlern gelernt, denn Swift ist durch die Bank typsicher und wäre das alles in Swift geschrieben, dann würde es diese Problem gar nicht geben. Daher hoffe ich, das Apple in Zukunft zunehmend auch den Code ihrer Betriebssysteme auf Swift migrieren wird (bis auf den Kernel selber sollte das überall möglich sein).
0
ND27.10.20 18:33
Die Frage bleibt für mich als Laien: Wie schütze ich mich?
0
aMacUser
aMacUser27.10.20 20:58
ND
Die Frage bleibt für mich als Laien: Wie schütze ich mich?
Lass keinen Fremden an deinen Mac und lade keine Software aus dubiosen Quellen.
+2
ND27.10.20 22:09
Danke
0
Weia
Weia29.10.20 03:34
MacTechNews
Ferner führt dies auch zu Abstürzen des Launch-Services-Daemons "LDS"
Das Ding heißt LSD, und nein, das ist kein Zufall.
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
0
Weia
Weia29.10.20 03:39
Mecki
Daher hoffe ich, das Apple in Zukunft zunehmend auch den Code ihrer Betriebssysteme auf Swift migrieren wird
Nicht Dein Ernst! Swift ist die schlimmste einzelne Fehlentwicklung von Apple in den 10er Jahren.
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
-1
Mecki
Mecki29.10.20 16:35
Weia
Nicht Dein Ernst! Swift ist die schlimmste einzelne Fehlentwicklung von Apple in den 10er Jahren.

Dir muss die Sprache nicht persönlich zu sagen, also deren Syntax, wobei was das angeht liegt Swift Welten vor C++, aber Swift ist um einiges schneller bei OO Code im Vergleich zu Obj-C (da passiert viel mehr statisch zur Compilezeit und viel weniger dynamisch zur Laufzeit), bei Low Level Operationen auch nur etwa 10% langsamer als reines C (und das größtenteils nur wegen Runtime Sicherheitschecks, die man auch abschalten kann, wenn Performance alles ist) und es ist typsicherer als alle anderen C Dialekte zusammen. Swift statt C Code zu verwenden macht also eine App kaum langsamer, es statt Obj-C Code zu verwenden sogar merklich schneller und so ziemlich jeder zweite schwerwiegende macOS Userspace Bug der letzten 10 Jahre wäre mit Swift gar nicht möglich gewesen, weil hier der Compiler hier schon mit einem Fehler abgebrochen hätte.
0
aMacUser
aMacUser29.10.20 18:16
Weia
Mecki
Daher hoffe ich, das Apple in Zukunft zunehmend auch den Code ihrer Betriebssysteme auf Swift migrieren wird
Nicht Dein Ernst! Swift ist die schlimmste einzelne Fehlentwicklung von Apple in den 10er Jahren.
Im Vergleich zu Objective-C ist Swift ein Segen. Schon rein von der Syntax her. Und was Apple im Anschluss mit SwiftUI geschaffen hat, ist einfach wunderbar. Aber ich muss @@Mecki recht geben, die Syntax ist nicht jedermanns Sache. Ich persönlich habe damit kein Problem. Allerdings entwickle ich auch relativ viel mit Go, was eine ähnliche Syntax hat. Aber für mich ist die Syntax mittlerweile sowieso nebensächlich (außer bei Obj-C, das ist einfach schrecklich mMn), da ich mit C#, Delphi, JS/TS, Go, Swift, ABAP, Java und PHP schon sehr viele Varianten von Syntax verwenden "durfte". Und Swift ist da definitiv eine der angenehmeren.
0
Weia
Weia30.10.20 00:15
Mecki
Dir muss die Sprache nicht persönlich zu sagen, also deren Syntax, wobei was das angeht liegt Swift Welten vor C++,
… aber Welten hinter Obj-C …
aber Swift ist um einiges schneller bei OO Code im Vergleich zu Obj-C
Schnelligkeit ist mir weitgehend egal (und wenn, kann ich in Obj-C dafür immer auf C zurückgreifen, schneller wird’s nicht ohne Assembler)
(da passiert viel mehr statisch zur Compilezeit und viel weniger dynamisch zur Laufzeit)
Und genau das ist mein Problem mit Swift: Es tauscht Flexibilität gegen Sicherheit ein, ein Trade-Off, den ich gar nicht mag. Ich mache oft Modellierungen von sozialen Interaktionen, dafür ist dynamisches Typing unverzichtbar.

Ich hätte nichts gegen Swift als zusätzliches, idiotensicheres Angebot für wenig kundige Gelegenheitsprogrammierer, die mal schnell eine iOS-App zusammenklöppeln sollen (allerdings bitte mit vernünftiger Syntax), aber als „Hauptsprache“? Nein danke (und es ist ja auch noch völlig unklar, ob es jemals dazu kommt). Das war eine der typischen Masse statt Klasse-Entscheidugnen der Cook-Ära, die sich wohl hauptsächlich der Tatsache verdanken, dass Cook für technische Klasse kein Gespür hat.
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
0
Weia
Weia30.10.20 00:23
aMacUser
Im Vergleich zu Objective-C ist Swift ein Segen. Schon rein von der Syntax her.
Die Syntax von Swift ist eine intellektuelle Bankrotterklärung und die von Objective-C die stringenteste OO-Syntax, die es gibt.

Aber den Streit hatten wir beide ja schon vor 3 Jahren …
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
-1
aMacUser
aMacUser30.10.20 02:03
Weia
Aber den Streit hatten wir beide ja schon vor 3 Jahren …
Hatten wir? Dafür ist mein Gedächtnis zu schlecht (und ich dabei bin erst 25).
Am Ende ist es wohl einfach eine Geschmacks- und vor allem Gewöhnungssache.
0
Weia
Weia30.10.20 02:11
aMacUser
Weia
Aber den Streit hatten wir beide ja schon vor 3 Jahren …
Hatten wir? Dafür ist mein Gedächtnis zu schlecht
Hatten wir, länglichst: , ab 3.9.2017, 22:16 Uhr
(und ich dabei bin erst 25)
Tja, wenn man erstmal jung wird, lässt das Gedächtnis nach …
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
+1
Joerg Sievers
Joerg Sievers31.10.20 12:55
Moin,
awk
Apple sind in letzter Zeit einige triviale Fehler unterlaufen. Einer Firma die sich Sicherheit auf die Fahnen schreibt dürfte derartiges nicht wiederholt unterlaufen.

wem ist da was unterlaufen? Das Konzept ist sehr, sehr alt. Kannst gerne mal auf meine NeXT-VM schauen....

Es ist nur so, dass Apple gerne an den Ausnahmebedingungen ihrer Altprogramme feilen kann, aber das ist ein Versäumnis aller Softwarehersteller. Alter Code == abgehangener Code == guter Code, jedoch ist letzteres durch != zu ersetzen.

Grüße
Jogi
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.