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

20 Jahre alter Bug macht Kernel von iOS und macOS angreifbar

Betriebssystemhersteller machen es Hackern immer schwerer, Betriebssysteme und Geräte anzugreifen. Strategien wie beispielsweise Address Space Randomization, mit welcher wichtige Speicherblöcke an zufälligen und nicht vorhersehbaren Adressen abgelegt werden, erschweren Attacken deutlich. Doch manchmal gibt das System selbst preis, an welchen Orten im Speicher welche Informationen stehen.


Wie nun bekannt wurde lässt sich zumindest die Address Space Randomization auf iOS und macOS aushebeln. Wenn ein potenzieller Angreifer eine Adresse im Kernel kennt, kann er zwar noch nicht direkt darauf zugreifen – aber ein wichtiger Sicherheitsaspekt des Systems hat seinen Dienst versagt.

Seit 20 Jahren im Apple XNU-Kernel
Nun flog ein derartiger Fehler im XNU-Kernel auf, welchen Apple auf allen Betriebssystemplattformen einsetzt. Der Entdecker taufte den Fehler auf den Namen "cuck00". Das Framework IOKit nutzt zur Kommunikation mit dem Kernel Mach-Ports – und sendet bei jeder Anfrage auch einen Pointer auf den Mach-Port zurück. Bei diesem Mach-Port handelt es sich aber nicht um irgendeine Zahl, sondern um einen direkten Pointer in den Adressraum des Kernels – welcher eigentlich einem normalen Programm aufgrund der Address Space Randomization unbekannt sein sollte.

Aufgrund solcher Fehler, welche auch in anderen Betriebssystemen entdeckt und behoben wurden, ist es trotz Address Space Randomization möglich, kritische Speicherbereiche zu lesen oder gar zu überschreiben. Für sich alleine gesehen ist dieser Fehler erst einmal kein Sicherheitsrisiko, da andere Sicherheitsmechanismen das Lesen und Schreiben in den Speicherbereich des Kernels verhindern – doch in Kombination mit anderen Lücken ergeben sich hier vielfältige Angriffsszenarien, welche sonst von der Address Space Randomization verhindert würden.

Schaut man sich Apples Open-Source-Archiv an, findet man den Bug bereits in der allerersten Version des XNU-Kernels, welche im Jahr 2000 veröffentlicht wurde.

Apple behebt Fehler
Apple hat letzte Woche neue Vorabversionen von iOS und macOS herausgegeben – und den Fehler mit iOS 13.3.1 Beta 2 und macOS 10.15.3 Beta 2 behoben. Apple gibt nun nicht mehr die vollständige Speicheradresse des Mach-Ports an eine Applikation weiter, sondern verkürzt diese um 8 Bit – daher ist die vollständige Adresse nicht mehr bekannt.

Kommentare

rosss21.01.20 14:09
Hier wohl keine akute Gefahr; aber werden solche Bugs normalerweise nicht erst veröffentlicht, sobald Sicherheitsupdates bereitstehen?
0
Wiesi
Wiesi21.01.20 14:30
Es ist davon auszugehen, daß diese Lücke in einschlägigen Kreisen schon bekannt ist. Da macht es sich besser, wenn man deren Schließung frühst möglich bekannt gibt, damit diese Kreise sich rechtzeitig umstellen können.
Everything should be as simple as possible, but not simpler
0
mac_heibu21.01.20 15:49
Wiesis „Kreise“ …
+1
sffan21.01.20 16:11
Dann hoffen wir mal, daß macOS 10.14.6 bzw. iOS 12.4.4 auch mit einem Ficken versehen werden. Bei macOS dürfte das sicher sein, spannend wird es bei iOs..
+1
sierkb21.01.20 16:31
Es ist davon auszugehen, daß diese Lücke in einschlägigen Kreisen schon bekannt ist.

+1

"Hintertüren". Sogenannte. Gewusst, bekannt, z.T. absichtsvoll offen gelassen. Irgendwann dann halt gefixt und geschlossen, weil nicht mehr gebraucht und man auch anders rein kann. Der Rest ist reines PR- und Marketing-Theater.
mac_heibu
Wiesis „Kreise“ …

Nein, er hat recht. Es sind u.a. genau solche Bugs, dieser Art, in iOS und macOS, im XNU-Kernel, die in Kreisen wie FBI, Geheimdienste & Co. bzw. Cellebrite, Graykey (einer der Gründer ist ein ehemaliger Apple Security Engineer, der iOS und seine Schwachstellen und Angriffspunkte somit sehr gut kennt) & Co. bekannt sind und ihnen Zugang ermöglichen.
Und Apple weiß davon und lässt sie ihnen eine Zeit lang. Als sog. Türöffner bzw. Hintertür. Man verständigt sich ggf., spricht sich ab. Der Rest ist reines PR- und Marketing-Theater und "Good Guy, Bad Guy"-Spiel.
Matthew Green, 16.01.2020
It’s amazing to me that police are still able to unlock even recent-model iPhones. Either it’s really hard to secure a Secure Enclave Processor, or Apple prefers to leave these vulnerabilities in place because it takes the heat off.
Q: Matthew Green, Kryptograf und Sicherheitstechnologe

Privacy News Online (17.01.2020): FBI used Graykey to unlock an iPhone 11 Pro, which was previously thought to be the most secure iPhone
Privacy News Online, 17.01.2020
A recent article by Thomas Brewster at Forbes highlights the fact that the FBI is able to unlock iPhones using a product called Graykey. Specifically, a product called Graykey was used in a case against Baris Ali Koch to unlock Koch’s iPhone – an iPhone 11 Pro. Graykey works by bypassing the timeout functionality in iOS and allows for brute forcing of the passcode or password.

Graykey not only works on the newest iPhones, it also works on older versions – and is advertised as doing so. iOS 13 was supposed to defend against this type of brute force device, but it clearly does not. If the FBI already has this capability to unlock iPhones, why are they demanding Apple to unlock the iPhone 5 and 7 from the Pensacola case? The US government, and other governments around the world, have been making such a big deal of demanding backdoors be built into encryption for years now – likely to set some precedence to force companies to work with them.

[…]

Researcher Dr. Matthew Green of the Johns Hopkins University showed in 2018 that Graykey wouldn’t work as quickly on a longer numeric passcode – whether or not a longer alphanumeric password would be stronger depends on if you choose your passwords randomly, which is a rare occurrence. For more information about password and passcode entropy, refer to this two year old, but still extremely relevant Twitter thread .

iPhone privacy and security is not as promised

Following the recent news of the iPhone 11 Pro being vulnerable to Graykey, Dr. Green tweeted again:

https://twitter.com/matthew_d_green/status/12178484565822464 00

The real pertinent question that Apple users should be asking themselves is why a phone and operating system that was marketed as being so private continually is proven to be not so private. Apple has known about Graykey for years now, yet their Secure Enclave Processer is still not secure. Of course, the possibility of that being a result of human error is there, and Hanlon’s Razor tells us that we shouldn’t attribute to malice that which is equally explainable by stupidity. I believe we’re past the point of being able to blame stupidity, and it’s entirely necessary to consider that Apple leaves sidedoors for law enforcement to walk through while publicly benefiting from a standoff with the governments’ requests to make backdoors – all in the name of the same PR and marketing goal as when they tout the questionable security and privacy of their devices.

Forbes (15.01.2020): The FBI Got Data From A Locked iPhone 11 Pro Max—So Why Is It Demanding Apple Unlock Older Phones?
0
MetallSnake
MetallSnake21.01.20 17:55
Wiesi
Es ist davon auszugehen, daß diese Lücke in einschlägigen Kreisen schon bekannt ist.

Es steht im verlinkten Artikel dass der Bug schon mehreren Leuten aufgefallen ist. Jetzt hat Googles Project Zero den Bug auch gefunden, nun wird er gefixt.
Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.
0
sierkb21.01.20 18:27
Ebenso/außerdem:

heise (28.12.2019): 36C3: Zero-Click-Exploit in Apples iMessage
Ein Sicherheitsforscher von Googles Project Zero hat Einblicke in iPhone-Angriffe gegeben, über die sich ein Gerät ohne Nutzerinteraktion beherrschen lässt.

media.ccc.de (Chaos Computer Club e.V), Samuel Groß/Google Project Zero (27.12.2019): Messenger Hacking: Remotely Compromising an iPhone through iMessage (Präsentation 36th Chaos Communication Congress (36C3), Leipzig, 27.-30.12.2019, Audio, Video)

Google Project Zero, Samuel Groß (09.01.2019): Remote iPhone Exploitation Part 3: From Memory Corruption to JavaScript and Back -- Gaining Code Execution

Google Project Zero, Samuel Groß (09.01.2019): Remote iPhone Exploitation Part 2: Bringing Light into the Darkness -- a Remote ASLR Bypass

Google Project Zero, Samuel Groß (09.01.2019): Remote iPhone Exploitation Part 1: Poking Memory via iMessage and CVE-2019-8641
-2
Pixelmeister22.01.20 13:32
Ich sehe den Bug nicht als besonders gravierend an, da Address Space (Layout) Randomization (egal, auf welchem OS) ohnehin kein besonders starker Schutz ist. Es gibt auch ohne Bug verschiedene Möglichkeiten, ASLR auszuhebeln (es sei hier z.B. ROP oder Spraying genannt), von daher kommt es auf eine weitere Möglichkeit auch nicht mehr großartig an. ASLR ist nur eine kleine zusätzliche Hürde, die z.B. Microsoft und Apple seit ca. 2007 in ihre Systeme integriert haben. Man benötigt noch einige weitere ungefixte Bugs, bis man wirklich etwas böses tun kann. Und in der Realität passiert es ohnehin fast immer nur bei Windows, dass aus Lücken und Szenarien echte, teure Angriffe werden, die Daten oder Existenzen gefährden. Von daher bleibe ich ganz entspannt.

Die 5 gefährlichsten Schadsoftwares der Geschichte/Welt laufen/liefen alle ausschließlich unter Windows:

Und auch dieses Kunstprojekt mit einem Laptop, auf dem die gefährlichsten Schadprogramme aller Zeiten installiert sind (u.a. Wannacry), lässt sich nur mit Windows realisieren. (Schadenssumme übrigens rund 100 Mrd. Dollar)
+2
CKtwo22.01.20 18:08
„ Apple gibt nun nicht mehr die vollständige Speicheradresse des Mach-Ports an eine Applikation weiter, sondern verkürzt diese um 8 Bit – daher ist die vollständige Adresse nicht mehr bekannt“ — hmmm, aus einer Adresse werden dann 256 mögliche Adressen. Nicht besonders viele, die eigentlich gemeinte dürfte rasch rausgefunden sein. Ob das wirklich sicher ist? Besser bisher wird‘s wohl sein.
-1

Kommentieren

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