Ungewohnt viele Sicherheitslücken
iOS 17.0.3 stopft erneut „Zero Day“-Schwachstelle
Mit dem gestern veröffentlichten Update auf iOS 17.0.3 möchte Apple nicht nur die Problematik mit der teils außergewöhnlichen Hitzeentwicklung bei den neuen iPhone-Modellen in den Griff bekommen, das Update behebt einmal mehr auch eine sogenannten „Zero-Day“-Schwachstelle. Wie Apple in den im Nachgang veröffentlichten Informationen zum Sicherheitsinhalt von iOS 17.0.3 und iPadOS 17.0.3 mitteilt, wurde die nun behobene Sicherheitslücke Berichten zufolge zumindest in Versionen bis zu iOS 16.6 aktiv ausgenutzt.
„Wohl aktiv ausgenutzt“
Die betreffende Schwachstelle ist unter der Kennung CVE-2023-42824 registriert. Hierbei handelt es sich nach Angaben von Apples um eine Sicherheitslücke im Systemkern, die es einem lokalen Bedrohungsakteur ermöglichen könnte, mit erweiterten Rechten zu agieren.
Darüber hinaus wurde mit dem gestrigen Update auch eine weitere Sicherheitslücke mit der Kennung CVE-2023-5217 im Zusammenhang mit dem Kommunikationsstandard WebRTC geschlossen, auf deren Basis ein Angreifer zumindest theoretisch die Möglichkeit hätte, schädlichen Programmcode auszuführen.
Ungewöhnlich viele „Zero Day“-Schwachstellen bei Apple
In den vergangenen Wochen musste Apple ungewöhnlich häufig mit Sicherheitsupdates reagieren, um Schwachstellen in den hauseigenen Betriebssystemen zu beheben, von denen mehrere wohl auch schon aktiv ausgenutzt wurden.
Die Hintertüren wurden unter anderem von der israelischen Spionage-Software „Pegasus“, die von dem zweifelhaften Anbieter NSO Group vertrieben wird, sowie von der Überwachungssoftware „Predator“, die wahrscheinlich aus Ägypten stammt, verwendet. Beide Anwendungen werden vor allem gegen politische Gegner eingesetzt, finden aber auch im Bereich der Wirtschaftsspionage Verwendung. Zumindest im Fall von „Pegasus“ sollte es nicht überraschen, wenn die Software auch von deutschen Behörden eingesetzt wurde. Das Bundeskriminalamt hat in der Vergangenheit zumindest Verhandlungen mit dem Anbieter des Spionagewerkzeugs geführt.
Warum wird nur im Nachhinein etwas verbessert? Warum nicht proaktiv? Ich bin kein Programmierer, aber vielleicht mal die Codes regelmäßig verändern und nicht über Jahrzehnte durchziehen. Dafür weniger Emojis.
Das du kein Programmierer bist brauchst du uns nicht zu sagen. Das liest man schon heraus.
+1
+1
+1
+1
+1
mit dem weniger Emojis und bessere Konzentration auf Sicherheit muss man ihm aber recht geben. Gibt anscheinend genügend die das drauf haben Sicherheitslücken zu finden
Du kannst doch nicht bei Programmierern hinterfragen, was „richtig und falsch“ ist. Und bloß nicht differenziert nachfragen, damit disqualifizierst Du Dich selbst.
Du musst ganz genau vorgeben was Du willst, denn proaktiv mitdenken geht da gar nicht! ;)
+1
+1
Ist wie ein Meteoriteneinschlag proaktiv verhindern. Kann man auch machen ;-)
Jo, deshalb war gerade eine Sonde unterwegs und hat Material zur Erde zurückgebracht.
Nein. DART war nicht Osiris-Rex!
Man verändert nichts am Code nach Lust und Laune ohne dass Änderungsbedarf besteht.
Das sind Millionen Zeilen.
Und bei jeder Änderung können sich neue Fehler einschleichen.
Als Programmierer kann ich sagen: das ist unmachbar. Sobald der Code auch nur eine gewisse Komplexität hat, ist es schwer jegliche erdenkliche Kombination zu testen. Klar man kann das Risiko mit bestimmten Mechanismen und Methoden verringern, aber kein Code der Welt ist 100% fehlerfrei. Selbst wenn ein Feature ursprünglich mal ging, kann eine Anpassung in einem anderen Feature es wieder unbrauchbar machen. Oder nachträgliche Anpassungen schaffen plötzlich neue Voraussetzungen. Und wenn dann noch mehrere Personen (zum teil grosse Teams) daran arbeiten, wird es noch schwieriger die Übersicht zu behalten.
++
Als Programmierer kann ich dir sagen da lässt sich ne Menge machen.
Grundlagen sieht Xcode ja sogar vor: UI Test & Co.
Mann sollte nur nicht versuchen es hinterher einzubauen, sondern man muss den Code gleich auch auf Sicherheit auslegen und nicht nur auf Funktion.
Und zu dem Thema man kann nicht alles Testen, klar kann man das. Kostet halt Geld.. und denkst du das sich solche „Häcker“ nur die Israelis und Ägypter leisten können wenn sie wollen.
Es ist halt eine andere Denke als bei einem Programmier.. die Abteilung die Apple scheinbar hat, scheint aber einfach Scheiße zu sein.
(evt. mal externe Firma nehmen)
Andererseits bekommt Apple nicht mal mit, das ihre iPhone 15 zu heiß werden. Schiebt den Quatsch auch noch externen Firmen zu, wo das ganz eindeutig ne iOS angelegt ist.
Zumal zumindest 2 der 3 genannten Apps gängige Apps sind.. die Apple vielleicht in irgendeiner Review selbst testen könnte.
Programmierer ist nicht immer gleich Programmierer, also es gibt gute und schlechte. Zudem sagt das Wort Programmierer überhaupt nichts aus, welchen Bildungsstand man hat. Somit sagt dies nicht aus, ob man qualifiziert ist für Aussagen. Engagierte Programmierer beschäftigen sich auch mit theoretischeR Informatik, die meisten Programmierer aber nich. Sie urteilen oft nur aus ihrem Erfahrungswissen heraus. Ist man ein studierter Informatiker, hatte man als Vorlesung zumindest theoretische Informatik. Von daher kann ich mit Bastimmheit sagen, dass @“Revbem“ Recht hat. Aber @“conectas“ hat auch nicht ganz Unrecht.
Also etwas differenzierter ausgesagt zum Thema Fehlerfreiheit im Code: @“conectas“ hat durchaus Recht, es ist möglich Code formal zu überprüfen, ob es absolut fehlerfrei ist.
ABER: Schon in TheoInf lernt man, dass man z.B. bei Windows theoretisch die absolute Fehlerfreiheit beweisen kann, wobei macOS ungefähr genauso komplex ist (evtl. etwas weniger, oder doch mehr … das ist Apples Betriebsgeheimnis … Beweise sind ab einer gewissen Komplexität des zu Beweisenden sehr schwierig, weshalb bei vielen Dingen, wenn möglich, man lieber einen Widerspruchsbeweis durchführt, wenn möglich … aber ab einer gewissen Komplexität ist dies praktisch nicht immer möglich, da die Quantität zu enorm sein kann und evtl. nicht alle nötigen Widerspruchsbeweise auffindbar sind wie beim komplexen Betriebssystem macOS, worauf auch iOS/iPadOS basiert). Formale Beweise auf fehlerfreie Programmierung bei komplexen Systemen kosten praktisch Dekaden. Und so lange wollen Anwender natürlich nicht warten. Also wenden sie einen Kompromiss an und überprüfen den Code nur bis zu einem gewissen Grad. Diesen bestimmt die QS (= Qualitätssicherung). Diese hat das Problem den Code in einem möglichst brauchbaren und der Sicherheit genügenden Zustand des Codes zu finden und dies dabei möglichst schnell zu realisieren.
@“clnnectas“ zeigt, dass er/sie entweder ein(e) schlechte(r) Programmierer(in) ost. Denn es gibt tatsächlich so etwas wie Unit Tests (nicht „UI Tests“!). Und bei den Programmierern gibt es oft große Differenzen beim Coding bzgl. Sicherheit. Sichere Programmierung kann man grundlegend durchführen (was aber nicht absolute Fehlerfreiheit garantiert! Wie sagt man? Errare humanum est!), was ich auch bevorzuge, auch wenn man dafür mehr Zeit aufwenden muss zum Programmieren. Aber manchmal muss man eine Daedline einhalten, was über Leben oder Tod beruflich entscheidet. Dann ist es natürlich, dass man versucht das Einfachere zu implementieren. (Nebenbei: Viele Programmierer sind faul und tun das nötigste, was sie aber durchaus später bei nötigen Weiterentwicklungen in Bredouillen bringt.). Also gute Entwicklungsumgebungen versuchen natürlich dem Programmierer etwas das Leben zu erleichtern, indem z.B. Unit Tests einfacher sind. Aber sie sind nicht der heilige Gral und können nicht alles überprüfen (oft muss man selbst eigene Überprüfungen einbauen … blöd, wenn die Überprüfung selbst fehlerhaft ist, aber das lässt sich leider nicht vermeiden, da niemand perfekt ist und sein kann).
Praktisch hat @“Revbem“ daher mehr Recht als @“conectas“.
Leute wie @“Saubär“ sind „lustig“. Er sagt selbst, dass er nichts über Programmierung weiß, aber will gleich danach darüber qualifiziert genug urteilen können. Sei Usteil zeigt zudem, wie unwissend er ist. Es gibt unterschiedliche Unicode-Standards, die sich ständig weiterentwickeln (oft mehr Emojis). Apple versucht den aktuellsten Unicode-Standard zu unterstützen und muss sie natürlich oft erweitern mit fast jedem Update. Damit kann man gut werben, auch wenn das einer der leichtesten Übungen ist. Zu behaupten, die ständig neuen Emojis kosten sehr viel Zeit, zeugt von Unwissenheit. Der Vorteil an neuen Emojis ist, am System muss man dann nichts grundlegend ändern, weshalb man dort auch kaum Qualitätssicherung braucht. Dass Emojis in iMessage mitunter ein Grund waren für eine schwere Sicherheitslücke, ist nur rein zufällig. So etwas gab es auch bzgl. PDF in allgemein (nicht nur iMessage), bei Sonderzeichen in iMessage und anderem. Es lag an der Verarbeitung des externen Inputs, was dies Probleme ermöglichte. In diesem Bereich sollte man evtl. die Qualitätssicherung erhöhen, wenn praktisch möglich.
Übrigens: Wenn den Lockdown-Mode nutzte, war von keinem dieser kritischen Lücken affektiert. Deshalb wurde dieser Modus schließlich eingeführt. Problematisch ist, dass nicht jeder erkennt, ob er/sie ein Target von Regierungen ist wie einfacje Mitarbeiter bei Hilfsorganisationen.
Zur Aussage „Kostet halt Geld.“ und „[…] klar kann man das“:
Nebenbei, man schreibt Hacker, auch wenn es phonetisch im Deutschen wie „Häcker“ ausgesprochen wird.
Theoretisch kann man beweisen, dass eine Implementierung absolut fehlerfrei ist. Das ist korrekt. Die formale Beweisführung würde aber ungefähr Dekaden kosten. Nehmen wir an, bei iOS 1 (damals iPhone OS (1)) dauert die Überprüfung nur eine Dekade. Für iOS 2 bräuchte man eine weitere Dekade. Dann wären wir heutzutage noch immer bei iOS 1. Wäre das toll, wenn man absolute Fehlerfreiheit hat? In iOS 1 gab es nich nicht einmal ein AppStore! Wenn du in der Steinzeit verharren willst, dann kaufe noch nicht einmal Handies!
So dermaßen kostenaufwändig ist eine generelle formale Beweisführung nicht. Aber sie kostet viel Zeit und gerade im Hinblick auf die Dauer und der schnellen Entwicklung der Geräte ist Zeit dort sehr kostbar. Daher ist es praktisch rückschrittlich darauf zu setzen, dass Code absolut fehlerfrei ist. Es ist für viele wie mich auch wünschenswert, wenn dies so wäre. Aber das ist Idealismus und kann mit Realität nicht immer vereint werden.
Da Computer damals viel langsamer waren, hätte die Überprüfung des Codes für den Flug zum Mond evtl. 3 Dekaden gedauert. Also vor zwei Dekaden wären wir zum ersten Mal auf dem Mond gewesen (und die Russen hätten noch viele sinnlos piepsenden Sputniks hoch geschickt ;) – mehr als Piepsen machte Sputnik nicht …).
Also ohne notwendiges Risiko wären wir noch in der Steinzeit. Dass alle Risiken mind. einen Kollateralschaden haben, ist leider unvermeidbar. Man versucht sie zu minimieren, so dass dies noch einigermaßen erträglich ist.
Das alles setzte voraus, dass Hardware perfekt ist. Aber genau dies ist es oft nicht, bei komplexen Systemen. Z.B. bei einem Modell der Intel CPU war auch ein berühmter FDIV-Bug. Das hieß, das System stürzte ab, wenn man bei einer Rechenoperation durch 0 teilte. Das ist bei Hardware besonders schlimm, weil sie besonders früher nicht mehr nachträglich geändert werden konnte. Also selbst absolut fehlerfreie Software funktionierte auf diesem Computer nicht. Man hat dann als Workaround in Software ein Umweg gefunden, wodurch der Nutzer durch 0 zu teilen befehlen konnte, aber dieser Befehl nicht an die CPU weiter gereicht wurde.
Also man müsste zuvor auch die Hardware auf absolute Fehlerfreiheit formal beweisen. Das könnte auch erst einmal viele Jahre dauern (ja, ich bin kein professioneller Hardwareentwickler, aber kann etwas darüber reden, weil ich im Studium produktionsreif schon eine 16 Bit CPU entwickelt habe, was in der Eliteuni jeder Student in Informatik erlernt, der unter anderem sich etwas in technischer Informatik einlernt).
Also es ist quasi ein Vabanque-Spiel. Es geht darum möglichst schnell neue Funktionen, Erweiterungen, Features oder einfach Weiterentwicklungen zu veröffentlichen, die möglichst gut benutzbar sind und sicher genug sind, aner die Zeit ist ein erbitterter Gegner, der auch rachsüchtig sein kann, wenn man versucht zu viel zeit einzusparen, weshalb man wegen der viel zu kurzen Zeitspanne man leider praktisch nicht das Implementierte formal beweisen kann.
Übrigens: Dass iPhones zu heiß werden, hat nichts mit Programmierung zu tun. Das ist die Qualitätssicherung, die dafür verantwortlich ist. Allerdings ist es dort analog zur Programmierung, dass man bei komplexen Systemen um Deadlines einzuhalten nicht alles überprüfen kann. Die Programmierung, die diesen fehlerhaften Zustand behebt, ist natürlich nur ein Workaround. Aber der Fehler in der Hardware bleibt. Dank den Programmierern muss Apple die ganzen iPhones nicht zurück rufen, sondern kann durch dieses Workaround/Update den teuren Rückruf vermeiden.
Wenn einer unserer Entwickler Code „einfach so“ ohne konkrete fachliche Anforderung oder einen Bug verändern würde, würde ich als erstes seinen gesundheitlichen Zustand prüfen und bei positivem Ergebnis ihn entlassen.
Immer dieses dümmliche Argument der Emojis. Die Emojis werden von Apple übernommen, nicht kreiert. Denkst du da sitzen 100 Programmierer und überlegen sich bei Apple den ganzen Tag was die für neue Emojis einführen und der Rest bleibt liegen?
Gute Idee, sich erst selber ein paar Schwachstellen ausdenken und sie dann noch vor Veröffentlichung der Software wieder schließen. So macht man seine Software super sicher. ;-)
Na das ist doch mal ein Vorschlag: Schwachstellen/Bugs/Fehler beheben BEVOR sie auffallen oder von jemandem bemerkt werden.
Ist so ähnlich, wie erst denken, dann reden … alles unrealistisches Wunschdenken … hat bei deinem Post auch nicht geklappt! ;)
Tja andere finden die Bugs ja. Frage der Motivation und Investition.
Ja, du „Schlau“Bär, weil deren gesamter Tag nur daraus besteht, Geld mit Schwachstellen zu machen. Keine, absolut keine, Software ist fehlerfrei. Außer natürlich, die, die du Fuchs schreiben würdest.
@“_Knight_“: Ich glaube nicht, dass @“Saubär“ Ironie versteht. :-)
Man stelle sich vor, bei Microsoft Windows hätte man diese Taktik implementiert, und einfach alle Schwachstellen schon vor dem Entstehen behoben, es hätte zwischen Windows 95 und 11 wahrscheinlich insgesamt nur 12 Updates gegeben.
Die Arbeit bei den Emojis wird zu 90 % bei einem Grafiker liegen. Und der sollte dann lieber nicht versuchen zu programmieren.
Bin kein Virologe, aber „die Codes regelmäßig verändern“ klingt nach komplettem Unsinn.
PS: Kein Virologe, aber zumindest Software-Entwickler.
Wenn man code verändert ist die Gefahr grösser neue Lücken einzubauen…
Autsch
Wie sieht es denn mit dem Problem des deaktivierten NFC bei BMWs aus? Ist das auch gefixt?
Hat BMW denn ein Update gebracht?
Was nützt das? Mein BMW versucht schon das ganze Jahr lang (aktuell ist es glaube ich der 3. Versuch) ein Update OTA einzuspielen :-))
Wenn das schon nicht (mehr) geht, nüzten auch bereitgestellte Update nichts.
Liegt fast immer an der Batterie. Die Werkstatt kann das Update auch so einspielen.
Deswegen habe ich das Online Gedöns nicht mehr verlängert. Idee ist gut aber die Umsetzung grausam. Support: „Oh ihr Fahrzeug ist gar nicht mehr bei uns im System“. Das Fahrzeug war nicht mal ein Monat alt. Und das passierte immer wieder.
Warum sollten Sie ? Wenn dein Apple mal wieder Müll gebaut hat.
Versucht ? Was ist die Fehlermeldung fürn Abbruch ? Schlappe Batterie
Ist die Spannung zu gering wird automatisch abgebrochen!!!
Die Batterie muss > 80% liegen ( Kapazität)
VW bekommt Autosoftware auch nicht hin.
Müssen Israelis und Ägypter gut sein !!! Evtl mal diese abwerben ???
Besser zu sein als die Software Gurkentruppe von VW ist auch kein Kunststück.
Woher kommt diese Erkenntnis, dass sie eine Gurkentruppe sind? Oder ist das nur unmarkiertes Stammtischgerede?
Die sollten das Akku Problem nicht vergessen. Der Akku hält noch nicht mal einen Tag
Scheint kein generelles Problem zu sein. Die meisten Ergebnisse sind positiv im Vergleich zum 14ner
Bei mir gibts auch kein Akku Problem. Steht sogar auf 80% Limit. Nutze es wirklich viel, YouTube, TikTok usw.
Bei mir ist seit iOS 10 der Akku auch sehr schnell leer. Das gleiche gilt für die AW4.
Vielleicht solltest du dann mal auf iOS 17 wechseln!
Also wenn du ein Gerät mit iOS10 nutzt, liegt es vlt am Alter des Akkus. Nicht an der Software.
Oder meinst du etwa WatchOS10?
Mein iPhone 15 hat am Ende des Tages noch über 20%, trotz reger Nutzung über den Tag und 30-60 Minuten Call of Duty: Mobile bei voller Helligkeit mit angeschlossenem USB-C-Controller am Abend. Setzt eure Geräte einfach mal frisch auf, wenn ihr Probleme habt. Ohne Backup Restore. Das wirkt Wunder.
These:
Die ersten Lücken in der Entwicklung tun sich auf. Apples Back-to-Office Politik lässt grüßen…
Bleib dran, du bist da was ganz Großem auf der Spur …
@“_Knight_“: Bitte Ironiezeichen nicht vergessen. Wenn man nur diesen Post liest, ist es theoretisch möglich, dass du dies tatsächlich ernst meinst. Und manche erkennen Ironie selbst auf Präsentiertellern nicht unbedingt.
Nachdem die Lücken ja schon lange existieren ist es wohl eher ungewöhnlich, dass Apple jetzt so viele davon stopft.
Der Unterschied zwischen „Existenz“ und „Bekanntheit“ sagt dir was?
Klar.
Es ist jedoch nicht verwunderlich, dass es viele Lücken gibt, sondern dass Apple sie jetzt erfährt und stoppt.
Aus Korrelation folgt oft nicht Kausalität.
Autsch
Leider hat Apple den Lautstärkeregler-Bug auf dem iPad immer noch nicht gefixt. :(
Gibt es auch auf dem iPhone in Kombi mit AirPods
Welcher Lautstärkebug? @“Jack Peachseed“ hat auf dem iPad evtl. den Stummschalter aktiviert? Und @“TRG“ hat für Signale und Töne unterschiedliche Einstellungen? Ersteres kann man die Stummschaltung im Control Center wieder deaktivieren. Bei Zweiteres muss min in die App Settings und unter Sounds ist ein Schalter, wo man Lautstärken für die zwei unterschiedlichen Systeme einstellen kann (also man kann einstellen, dass z.B. Videos nur sehr leise sind um andere nicht zu nerven, aber dass es bei Anrufen dennoch kaut genug klingelt).
Gilt die Schwachstelle auch für ios 16 ?
Also für iOS 16 gibt es kein Update. Vermutlich hätte Apple dies auch dort ausgebessert, wenn es auch diesen Fehler hätte. Aber da ohne Details und ich kein NSO-Mitarbeiter – oder evtl. reicht auch ein professioneller Pentester – bin und Apple noch keine Details bekannt gibt, kann ich dies nicht mit 100¿iger Sicherheit sagen.
Also für iOS 16 gibt es kein Update. Vermutlich hätte Apple dies auch dort ausgebessert, wenn es auch diesen Fehler hätte. Aber da ohne Details und ich kein NSO-Mitarbeiter – oder evtl. reicht auch ein professioneller Pentester – bin und Apple noch keine Details bekannt gibt, kann ich dies nicht mit 100%iger Sicherheit sagen.
Nicht dein Ernst?
Meinst du @“Saubär“? Wenn ja, dann kann ich sagen, dass es erfahrungsgemäß erstaunlich viele Leute gibt, die so oder so ähnlich denken.
Wer etwas Einblick haben möchte in Softwareentwicklung und warum leider immer wieder schwere Sicherheitslücken vorkommen und ob es gerechtfertigt ist, deswegen Apple oder andere Unternehmen in der Softwareentwocklung zu schelten, der sollte meine langen Kommentare als Antworten auf andere OPs/Hauptkommentare oder Unterkommentare lesen.