Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Mal wieder: Bestimmte Zeichenfolge lässt Apple-Geräte abstürzen

Bereits in der Vergangenheit tauchten immer wieder Bugs dieser Art auf: Erhielten iOS-Benutzer eine bestimmte Zeichenfolge per Nachrichten-App, so führte der Text zum Absturz des Geräts. Anwender konnten ihr iPhone nicht mehr bedienen und mussten sich verzwickter Workarounds bedienen, um wieder die Kontrolle über ihr Smartphone zu erlangen. Bisweilen waren auch Macs davon betroffen. Nun ist es wieder soweit - ein neuer Bug lässt Apple-Geräte einfrieren.

Sindhi-Zeichen bewirken Absturz
Bei dem Text kommen bestimmte Zeichen aus der Sindhi-Sprache vor. Ursprünglich galt auch das Zeichen für die italienische Fahne als unabdingbarer Bestandteil des Bugs, dem ist ist jedoch nicht so. Laut Reddit könnte diese spezielle Abfolge erstmals in einer Gruppe, die die App Telegram benutzte, aufgetaucht und später auf Twitter verbreitet worden sein. Erhalten Anwender eines iPhones, iPads, Macs oder einer Apple Watch diese Sindhi-Zeichen in einer bestimmten Konstellation, reagiert das Gerät nicht mehr auf Eingaben und stürzt eventuell ab. Lässt dich das Gerät nicht mehr bedienen, schafft lediglich ein Hard-Reset Abhilfe.

Apple ist Fehler bekannt
Apple weiß um diesen Bug und behebt ihn mit der zweiten Beta von iOS 13.4.5. Wann diese in ihrer finalen Version freigegeben wird, ist allerdings noch unklar. Denkbar ist ebenfalls, dass Apple zeitnah ein Software-Update wie iOS 13.4.2 veröffentlicht, um den Bug auszumerzen. Ungewiss ist auch, wann die anderen von diesem Fehler betroffenen Geräte mit einem Bugfix versorgt werden. Apple hat in der Vergangenheit auf Bugs dieser Art meist sehr rasch reagiert. Allerdings sind Abstürze aufgrund spezieller Zeichenfolgen nicht die einzigen Probleme, mit denen sich der Konzern gegenwärtig beschäftigen muss.

Auch Sicherheitslücke harrt einer Reparatur
Eine schwere Sicherheitslücke in der Mail-App von iOS-Geräten sorgt derzeit ebenfalls für Aufsehen. Einige Quellen berichten, dass Hacker so sensible Daten auslesen könnten - Apple allerdings widerspricht dieser Darstellung. Auch hier soll iOS 13.4.5 für Abhilfe sorgen - es gilt daher als überaus wahrscheinlich, dass möglichst bald Updates für Apple-Geräte bereitgestellt werden, um beide Fehler zu beheben.

"Der Hackintosh liegt auf dem Sterbebett" – das...

Recycling-Betrug: Doch Apple lässt Klage fallen...

"8 GByte sind genug" – Apple verteidigt RAM-Aus...

Kurz: Beliebige KI-Musik mit Udio komponieren (...

iOS 18: Bild soll neues Oberflächendesign zeige...

MacStammbaum 10.3 erschienen – "Suche" ganz neu...

Bericht zum neuen iPad Pro: Apple bestellt Mill...

AirPower lädt Apple Watch: Vorgang erstmals in ...

Kommentare

dtownsonic24.04.20 12:20

Hat jemand eine Erklärung wie es zu solchen "Fehlern" kommt? Also, dass eine bestimmte Zeichenabfolge das komplette Betriebssystem einfrieren lässt? Was läuft da in dem Moment genau ab?

Fenvarien24.04.20 12:22

Im letzten Absatz dieser Meldung hatte ich es mal erklärt:

Ey up me duck!

dtownsonic24.04.20 12:30

Danke für die Antwort aber der letzte Absatz hat mein Verständnis jetzt nicht wirklich verbessert.

"Wer sich fragt, wie so etwas immer wieder passieren kann: Das Thema Unicode ist eine komplexe und schwer zu überblickende Angelegenheit. Allerlei Optimierungen, Abkürzungen sowie undokumentierte Spezifikationen sorgen regelmäßig für Möglichkeiten, Exploits zu ersinnen. Daher ergibt sich ein stetes Katz-und-Maus-Spiel zwischen Herstellern wie Apple und Google sowie findigen Unicode-Exploitern."

Dass es ein komplexes Problem ist hab ich mir schon gedacht. Aber dennoch bleibt die Frage was da genau passiert, wenn eben die Zeichenabfolgen Verarbeitet werden.

sierkb24.04.20 12:50

dtownsonic

Dass es ein komplexes Problem ist hab ich mir schon gedacht. Aber dennoch bleibt die Frage was da genau passiert, wenn eben die Zeichenabfolgen Verarbeitet werden.

Die Validierung von Unicode-Zeichen ist alles andere als trivial und eine Herausforderung – erst recht, wenn's dann auch noch performant sein und die CPU möglichst nur minimal belasten soll. Siehe dazu u.a. auch z.B. die Ausführungen von:

Daniel Lemire Blog (19.10.2018): Validating UTF-8 bytes using only 0.45 cycles per byte (AVX edition)

Daniel Lemire Blog (09.05.2018): How quickly can you check that a string is valid unicode (UTF-8)?

Björn Höhrmann: Flexible and Economical UTF-8 Decoder

CAPEC/Mitre: CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic

sierkb24.04.20 13:05

sierkb

dtownsonic

Dass es ein komplexes Problem ist hab ich mir schon gedacht. Aber dennoch bleibt die Frage was da genau passiert, wenn eben die Zeichenabfolgen Verarbeitet werden.

Nachtrag (weil u.a. auch im Blog-Post von Lemire genannt):

Woboq – Olivier Goffart, Markus Goetz (26.07.2012): UTF-8 processing using SIMD (SSE4)

Kerberos24.04.20 17:23

@sirkb: Dennoch stellt sich die Frage, warum die Dekodierung einer Zeichenkette das ganze System abschmieren lässt und nicht etwa nur die jeweilige App (was auch schon schlimm genug wäre). Außerdem scheinen andere Hersteller damit kein Problem zu haben, oder gab es schon entsprechede Meldungen zu Windows, Linux, Android? Und offenbar hat Apple das Problem nach dem erstmaligen Auftreten auch nicht grundsätzlich behoben sondern hangelt sich von Fall zu Fall.

sierkb24.04.20 17:43

Kerberos:

Deine Fragen und Einwände sind berechtigt, und ich stimme Dir zu. Zumal es u.a. sowas wie Fuzzing , , Penetrationstests und andere automatisierte wie menschenbasierte Praktiken, Mechanismen und Abläufe (darunter u.a. auch Peer-to-Peer-Review bzw. Mehraugenprinzip) in der Softwareentwicklung gibt, um derlei Problemstellen und Fehler frühzeitig offenzulegen bzw. abzufangen, bevor man sie freigibt – man sollte meinen (und hoffen), Apples Software-Ingenieure nebst deren Qualitätssicherung (QA) haben von sowas schon mal gehört, und sie nutzen derlei auf einer selbstverständlichen Basis, und es gehört zu deren festen internen Abläufen/Prozedere.

-1

tocotronaut24.04.20 17:55

Alle möglihchen Zeichenketten werden permanent gescannt und auf verwertbare informationen abgeklopft.
- Wenn ein link erkannt wird macht das system diesen anklickbar.
- Wenn eine emailadresse erkannt wird kann man damit weiterarbeiten.
- Wenn ein Termin erkannt wird bietet das system an den in den kalender zu übertragen.
- Wenn ein Ort erkannt wird kann man die Navigation starten.
- Wenn ein rechtschreibfehler erkannt wird kann man den korrigieren.

Diese Datenerkennung wird (sinnigerweise) durch das Betriebssystem in einem eigenen (allerdings offensichtlich zu tief im system verwurzelten) Prozess bereitgestellt.
Deshalb bringen Probleme mit dieser Datenerkennung auch das komplette system zum Absturz.

malo24.04.20 21:18

tocotronaut

Danke, für die verständliche Erklärung!

ocrho25.04.20 10:34

Mir geht die Bereitschaft verloren nach über fünf Jahren mit diesen Unicode-Bugs in iMessage von einem Sicherheitsproblem zu sprechen auf das wir nur wieder auf den nächsten Hotfix warten müssen. Wir erwarten bei iOS und macOS zu Recht ein höheres Sicherheitsniveau als unter Windows. So ein systematisches Problem muss systematisch behoben werden. Im Extrem bedeutet es, dass man ggf. die Objektorientierte Programmierung oder API-Einbindung an kritischen Punkten etwas zurückbauen muss, wenn "geliehener Code" diese Sicherheitsprobleme nicht abfangen kann, da in deren ursprünglichen Kontext dieses Sicherheitsproblem nicht auftritt und der nachträglich Einbau die ursprüngliche Idee sprengt warum es dieses Objekt / API gibt. An den richtigen Stellen spezifisch programmierter Code "ohne geliehen Code" aus anderen Kontexte ist extrem performant und lässt sich auch leichter testen und anpassen, aber es bedeutet viel Arbeit und Knowhow erstmal spezifischen hochoptimierten Code als Algorithmus zu erstellen. Viele Programmierer können nicht mehr gute Algorithmen programmieren und binden dann immer nur "geliehen Code" ein.

-3

Wiesi25.04.20 12:24

Wie @sierkb in seinem ersten Post schon dargelegt hat, wird die Entschlüsselung der UTF-8 codierten Zeichen aus Gründen der Effizienz sehr maschinennah in C programmiert. Das Herausfiltern ungültiger Codes bleibt dabei schon mal auf der Strecke. Im Zuge der Weiterverarbeitung werden aus dem Code Pointer errechnet und ungültige Codes erzeugen ungültige Pointer. In C kann das tödlich sein.

Ein weiteres Problem ist die grafische Aufbereitung der Zeichen. Dabei sind auch Skalierungen nötig. Eine Division wird hier hin und wieder unvermeidlich sein. Auch hier wir aus den gleichen Gründen maschinennah programmiert.

Auf ungültige Adressen (Pointer) und Division durch Null reagiert die Hardware mit Panik. Und die schlägt bei maschinennaher Programmierung voll durch und bringt über sogn. "traps" das ganze System zum Absturz. Auf den höheren Ebenen der Software werden diese traps abgefangen und beenden nur den aktuellen Prozess, das System läuft weiter.

Da Apple eine eigenständige Aufbereitung der Zeichen hat, ist es nicht verwunderlich, wenn sich Apple-Systeme anders verhalten als Windows-Systeme. Zur Ehrenrettung von Apple muß gesagt werden, daß hier alle Facetten der Codierung sehr gut unterstützt werden. Apple hat sich die Sache dadurch nicht grade einfach gemacht.

Everything should be as simple as possible, but not simpler

Mal wieder: Bestimmte Zeichenfolge lässt Apple-Geräte abstürzen

Kommentare

Kommentieren

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