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

Schwere Sicherheitslücke mit iOS 7.0.6 geschlossen - OS X allerdings weiterhin betroffen (Aktualisierung)

Gestern veröffentlichte Apple ein Software-Update für iOS 6 und iOS 7, das laut Updatebeschreibung eine Sicherheitslücke schloss. Nähere Details nannte Apple nicht, Berichten zufolge handelte es sich aber um einen schwereren Fehler. Angreifern ist es durch Ausnutzen fehlerhafter Authentifizierung möglich, die Kommunikation zwischen zwei Stellen abzufangen, beispielsweise zwischen Browser und Server. Auf diese Weise können dann vertrauliche Informationen ausgespäht, modifiziert oder gar die Kontrolle über das System übernommen werden. Allerdings betrifft die Lücke nicht nur iOS, auch OS X ist betroffen. Die letzte Entwicklerversion von OS X 10.9.2 weist den Fehler ebenfalls auf. Es bleibt zu hoffen, dass Apple sehr schnell reagiert und auch ein Sicherheitsupdate für OS X veröffentlicht. Über diese Testseite kann man überprüfen, ob die Schwachstelle auf dem eigenen System ebenfalls vorhanden ist: . Firefox und Chrome verwenden ein anderes Verfahren (NSS für SSL anstatt SecureTransport), das von der Sicherheitslücke nicht betroffen ist. Allerdings ist der Firefox- und Chrome-Nutzer dennoch nicht vollständig sicher, da auch in anderen Bereichen des Systems oder in Programmen die SecureTransport-Schnittstelle eingesetzt werden kann.

Aktualisierung: Apple hat den Fehler offiziell bestätigt und ein rasch erscheinendes Update in Aussicht gestellt. Man kenne das Problem und habe bereits die Lösung gefunden - das Update erscheine "very soon".

Weiterführende Links:
Eskalationskurs: ARM kündigt Qualcomm die Design-Lizenz
Eskalationskurs: ARM kündigt Qualcomm die Desig...
Kopfhörer für Workout
Kopfhörer für Workout
Ransomware eingefangen? Die meisten bezahlen ihre Erpresser
Ransomware eingefangen? Die meisten bezahlen ih...
Mac mini mit M4
Mac mini mit M4
watchOS 11: Apple trennt sich von vier Zifferblättern
watchOS 11: Apple trennt sich von vier Zifferbl...
Das MacBook Pro M4
Das MacBook Pro M4
Kurz: Schon wieder neue AirPods-Firmware +++ Severance Staffel 2: Trailer erschienen
Kurz: Schon wieder neue AirPods-Firmware +++ Se...
Vor 15 Jahren: Als der iMac riesig wurde
Vor 15 Jahren: Als der iMac riesig wurde

Kommentare

BlueVaraMike
BlueVaraMike22.02.14 20:46
7.1 Beta 5, Lücke besteht!
😳
Do what you want, but harm no one!
0
strateg
strateg22.02.14 20:51
stimmt, das aktualisieren der 7.0.5 hatte wohl vorrang
cuntentientscha, attentivitad, curaschi —
0
someone22.02.14 23:01
Gruselig wie bei Apple codiert und getestet wird dass sowas nicht auffaellt:
0
MikeMuc22.02.14 23:04
Safari unter 10.6.8 nicht betroffen
0
sierkb22.02.14 23:38
MikeMuc:
user@/.
Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet. Just verified on my 10.6 box (to verify visit https://www.imperialviolet.org:1266/ )

On the other hand, iOS 6.1.5 is - and now I have a choice of using insecure iPhone or upgrading to 7.x. For now I've switched from Safari to a 3rd party browser that does not have this bug - but email is still vulnerable and so can be other components. That said, I have little trust in SSL even when it works as designed, so I won't lose much sleep over this.
Quelle: /.
0
Hannes Gnad
Hannes Gnad22.02.14 23:44
http://www.reuters.com/article/2014/02/22/apple-encryption-idUSL2N0LR0GW20140222
- Apple Inc said on Saturday it would issue a software update "very soon" to cut off the ability of spies and hackers to grab email, financial information and other sensitive data from Mac computers.

Confirming researchers' findings late Friday that a major security flaw in iPhones and iPads also appears in notebook and desktop machines running Mac OS X, Apple spokeswoman Trudy Muller told Reuters: "We are aware of this issue and already have a software fix that will be released very soon."
0
johnnyb23.02.14 00:32
Alles kein Problem...
0
user_tron23.02.14 00:41
Das sind bei Apple Features... also alles ok...
Ich erwarte von niemanden Zustimmung für meine persönlichen Ansichten ;-)
0
dan@mac
dan@mac23.02.14 01:51
someone
Gruselig wie bei Apple codiert und getestet wird dass sowas nicht auffaellt:
Wie geil
0
PaulMuadDib23.02.14 06:49
Wer von euch hat denn schon mal ein Programm geschrieben? Und wenn ja: noch nie ein ähnlicher Fehler passiert? Und warum so etwas bei Test nicht auffällt könnte es tausend Ursachen geben. Alles von Menschen gemacht. Und damit leider zwangsweise fehlerbehaftet.
0
o.wunder
o.wunder23.02.14 06:58
someone
Gruselig wie bei Apple codiert und getestet wird dass sowas nicht auffaellt:
Da wurde anscheinend nie ein Code Review durch eine weitere Person gemacht, alles Einzelkämpfer, denn sonst wäre das mit den doppelten Goto Fail sofort aufgefallen. Das führt dazu dass die Funktion SSLHashSHA1.final nie aufgerufen wird, aber die Funktion ohne Fehler verlassen wird - fatal.
0
orion23.02.14 07:02
PaulMuadDib
Wer von euch hat denn schon mal ein Programm geschrieben? ... Alles von Menschen gemacht. Und damit leider zwangsweise fehlerbehaftet.

Dafür gibt es ja die Qualitätskontrolle. Warum seit Jahrzehnten in der Softwarebranche im Hinblick auf Qualitätsmanagment andere Maßstäbe gelten als bei der Herstellung von "realen" Gütern ist mir ein Rätsel.
Man spricht ja nicht umsonst von Bananensoftware.

Das liegt wohl daran, daß es leider leichter ist einen Programmfehler zu patchen als z.B ein fehlerhaftes Uhrwerk zu flicken.
0
Dieter23.02.14 08:22
Für die iOS7 unwilligen gibt es keine Lösung.
0
Dieter23.02.14 08:26
Gerade getestet. Safari 6.1.1 unter 10.8.5.
Your browser aborted loading the test image upon seeing an invalid ServerKeyExchange message. This means your browser is not vulnerable to the bug, however if you're on an Apple device make sure you test Safari.
0
sonorman
sonorman23.02.14 09:44
orion
Dafür gibt es ja die Qualitätskontrolle. Warum seit Jahrzehnten in der Softwarebranche im Hinblick auf Qualitätsmanagment andere Maßstäbe gelten als bei der Herstellung von "realen" Gütern ist mir ein Rätsel.
Man spricht ja nicht umsonst von Bananensoftware.

Das liegt wohl daran, daß es leider leichter ist einen Programmfehler zu patchen als z.B ein fehlerhaftes Uhrwerk zu flicken.
Im Editorial der aktuellen Rewind schrieb ich gerade, dass es auch mir lieber wäre, wenn die Anbieter mehr Sorgfalt bei der Kontrolle walten lassen würden. Andererseits hat PaulMuadDib aber auch Recht: Es sind alles nur Menschen die dahinter stecken, wobei garantiert keiner von denen es darauf angelegt hat, dass seine Software als unsicher gilt. Eine wirklich fehlerfreie und unknackbare Software hat es noch nie gegeben – und wird es auch nie geben.

Vielleicht ist in letzter Zeit auch nur die Zahl der Hacker deutlich gestiegen und es kommt uns deshalb so vor, dass die Software immer unsicherer wird? Zu viele Leute mit zu viel Zeit und genügend krimineller Energie. Also ist das Ganze womöglich weniger ein softwaretechnisches als ein gesellschaftliches Problem.
0
Thomas Kaiser
Thomas Kaiser23.02.14 10:09
sonorman
Es sind alles nur Menschen die dahinter stecken, wobei garantiert keiner von denen es darauf angelegt hat, dass seine Software als unsicher gilt.

Das mag fürs "unsicher gelten" zutreffen, fürs "unsicher sein" evtl. auch nicht. Kann auch sein, dass wir hier den Versuch, eine Backdoor in iOS und OS X zu implementieren, gesehen haben, die erstmal nur nach "Fehler" aussehen soll (liest zwar eh keiner aber schönes Beispiel, wie das bei Linux versucht wurde, hier: )

Gab's in anderen OS ja auch alles schon, OpenBSD, Linux, etc. Bei den ganzen Closed Source OS darf man davon ausgehen, dass da genügend solche Kracher enthalten sind. Die bei der NSA beömmeln sich ja intern darüber, dass sie unter Windows noch nicht mal eine Backdoor brauchen, um den Rechner zu übernehmen.
sonorman
Eine wirklich fehlerfreie und unknackbare Software hat es noch nie gegeben – und wird es auch nie geben.

Ach so, so ist das also...
0
sonorman
sonorman23.02.14 10:24
Thomas Kaiser
sonorman
Eine wirklich fehlerfreie und unknackbare Software hat es noch nie gegeben – und wird es auch nie geben.

Ach so, so ist das also...
Ja genau. So ist das.

Ich will damit ja nicht sagen, die Entwickler sollen oder brauchen sich keine Mühe zu geben, ihre Software sicherer zu machen. Aber welchen Aufwand wärest DU bereit zu treiben, um Deine Software Fort-Knox-sicher zu machen? Und was wäre der Preis dafür? Und die Entwicklungszeit?

Ich glaube wirklich, dass die Software heute nicht luschiger geschrieben wird, als früher. Sie ist nur komplexer geworden und bietet damit auch mehr Angriffspunkte. Und wie gesagt, die Zahl der Kriminellen mit Programmierkenntnissen steigt auch.

Häuser sind übrigens auch nicht unsicherer geworden. Trotzdem steigt die Zahl der Einbruchdiebstähle immer weiter. – Ein gesellschaftliches Problem. Kein sicherheitstechnisches.
0
quiddemanie23.02.14 11:16
sonorman
Also ist das Ganze womöglich weniger ein softwaretechnisches als ein gesellschaftliches Problem.

nu nu...was hat das jetzt mit der news zu tun? dass schwere sicherheitslücken ein gesellschaftliches problem sind?
0
bmonno23.02.14 11:59
sierkb
MikeMuc:
user@/.
Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet. Just verified on my 10.6 box (to verify visit https://www.imperialviolet.org:1266/ )

On the other hand, iOS 6.1.5 is - and now I have a choice of using insecure iPhone or upgrading to 7.x. For now I've switched from Safari to a 3rd party browser that does not have this bug - but email is still vulnerable and so can be other components. That said, I have little trust in SSL even when it works as designed, so I won't lose much sleep over this.
Quelle: /.
Sieht für mich nach einem Erbe von Back to the Mac aus. Diesem Vorhaben haben wir ja schon einige Verschlimmbesserungen am Desktop zu verdanken.
Open Source scheint (eine größere Entwicklergmeinde vorausgesetzt) im Fehlerbeseitigen erfolgreicher zu sein. Viele Augen sehen halt mehr als wenige. Da WebKit ja fast nur noch von Apple eingesetzt wird, wird es auch da wohl spannend.
0
zod198823.02.14 12:08
bmonno
Da WebKit ja fast nur noch von Apple eingesetzt wird


Der war gut.
0
GHS
GHS23.02.14 12:09
Schaut mal über den Tellerrand. Hat MS jemals fehlerfreie und sichere SW geliefert? Geniesst den Sonntag
Seht die Welt aus anderen Augen.
0
Ties-Malte
Ties-Malte23.02.14 14:32
Thomas Kaiser
Kann auch sein, dass wir hier den Versuch, eine Backdoor in iOS und OS X zu implementieren, gesehen haben, die erstmal nur nach "Fehler" aussehen soll.

Ich vermute auch ganz, ganz stark, dass wir Zeuge der Machenschaften des von der NSA schon vor Jahren eingeschleusten Jakob Bond geworden sind. Leider wird er es wohl nie zugeben (Omerta: ihr wisst, das Schweigegelübte von Mafia und NSA. Ist ja quasi fast das Gleiche), nur wer das Offensichtliche nicht sehen will und so…

Herrlich. Sonntag gerettet.

P.S. Die Mutter von James (bürgerlich: Jakob) war ja Schweizerin. Wir sollten beim Thema Threema daher gaaanz vorsichtig sein. Man munkelt, auch dies sei ein Produkt der… (pssst…) ihr wisst schon.
The early bird catches the worm, but the second mouse gets the cheese.
0
dan@mac
dan@mac23.02.14 14:40
o.wunder
someone
Gruselig wie bei Apple codiert und getestet wird dass sowas nicht auffaellt:
Da wurde anscheinend nie ein Code Review durch eine weitere Person gemacht, alles Einzelkämpfer, denn sonst wäre das mit den doppelten Goto Fail sofort aufgefallen. Das führt dazu dass die Funktion SSLHashSHA1.final nie aufgerufen wird, aber die Funktion ohne Fehler verlassen wird - fatal.

Zudem ist der einzige Unterschied zur Vorversion das Fehlen der zweiten Goto Anweisung.

Das ist schon echt dämlich und hätte normalerweise mit den richtigen Werkzeugen eben nicht passieren dürfen. Das hat nichts mit "Menschlichkeit" zu tuen wie sich das hier manch einer schön redet.
0
sonorman
sonorman23.02.14 15:13
dan@mac
… Das hat nichts mit "Menschlichkeit" zu tuen wie sich das hier manch einer schön redet.
Ich versuche nur, die Sache aus mehr als nur einer Perspektive zu betrachten, wobei ich von "gesellschaftlich" sprach.

Fehler passieren aber nun mal. Die ganz dummen Fehler sind darunter besonders menschlich. Voreingenommen finde ich es hingegen, den Entwicklern quasi pauschal mangelnde Sorgfalt oder gar Absicht (NSA Backdoor) zu unterstellen.

Wo wir gerade bei mangelnder Sorgfalt sind: Es heißt "zu tun", nicht "zu tuen". Das ist zwar kein sicherheitsrelevanter Fehler für andere, aber so etwas kann die Integrität infrage stellen und dadurch das Argument angreifbar machen. So gesehen hast Du gerade eine Sicherheitslücke produziert. – Sehr schlampig! (Ist nicht persönlich gemeint, sondern rein argumentativ.)
0
chessboard
chessboard23.02.14 15:47
Warum ist dieser Quellcode eigentlich einsehbar? OpenSource? Und wenn OSS, warum hat das dann noch keiner früher entdeckt, wo doch bei OSS tausende ständig den Quellcode kontrollieren?
0
zod198823.02.14 16:12
Halt einfach bis dahin (oder besser grundsätzlich) kein Onlinebanking im Café treiben.
0
SpaceHotte23.02.14 16:21
sonorman
Ich versuche nur, die Sache aus mehr als nur einer Perspektive zu betrachten, wobei ich von "gesellschaftlich" sprach.

Fehler passieren aber nun mal. Die ganz dummen Fehler sind darunter besonders menschlich. Voreingenommen finde ich es hingegen, den Entwicklern quasi pauschal mangelnde Sorgfalt oder gar Absicht (NSA Backdoor) zu unterstellen.
So ein katastrophaler Bug ist aber nur bei Apple menschlich und nachvollziehbar. Käme so was bei Windows/Android vor hätte man sich brüllend drauf stürzen können.

Aber bei Apple nicht, lieber findet man noch 20 unrealistische Szenarien um sich das Fiasko schönzureden.
0
sonorman
sonorman23.02.14 16:47
SpaceHotte
So ein katastrophaler Bug ist aber nur bei Apple menschlich und nachvollziehbar. Käme so was bei Windows/Android vor hätte man sich brüllend drauf stürzen können.

Aber bei Apple nicht, lieber findet man noch 20 unrealistische Szenarien um sich das Fiasko schönzureden.
Ach, immer diese Vorurteile.
Wer redet denn hier was schön? ist es inzwischen unredlich geworden, sich die Situation mal aus einer anderen Perspektive anzusehen? Aber ich verstehe schon, dass es viel leichter ist, Schuldzuweisungen zu machen und Sündenböcke zu benennen.
0
SpaceHotte23.02.14 16:56
sonorman
SpaceHotte
So ein katastrophaler Bug ist aber nur bei Apple menschlich und nachvollziehbar. Käme so was bei Windows/Android vor hätte man sich brüllend drauf stürzen können.

Aber bei Apple nicht, lieber findet man noch 20 unrealistische Szenarien um sich das Fiasko schönzureden.
Ach, immer diese Vorurteile.
Wer redet denn hier was schön? ist es inzwischen unredlich geworden, sich die Situation mal aus einer anderen Perspektive anzusehen? Aber ich verstehe schon, dass es viel leichter ist, Schuldzuweisungen zu machen und Sündenböcke zu benennen.
Welcher Sündenbock? Wer zu blöd ist Klammern zu setzten und so direkt solche Fehler zu entdecken, oder zumindest einen Text von 1968 der nichtmal 1,5 Seiten lang ist zu lesen gehört öffentlich ausgepeitscht, nicht entschuldigt.

Nur um das noch mal klar zu stellen, hier gehts nicht darum, dass ein Quadrat blau statt grün gezeichnet wird, hier geht es um eine sicherheitskritische Bibliothek die das System benutzt. Es gibt genügend Techniken um solche Fehler heute zu verhindern, aber wahrscheinlich würde dann das günstigste iPhone einen 5-stelligen Betrag kosten.
0
Thomas Kaiser
Thomas Kaiser23.02.14 17:02
Ties-Malte
Thomas Kaiser
Kann auch sein, dass wir hier den Versuch, eine Backdoor in iOS und OS X zu implementieren, gesehen haben, die erstmal nur nach "Fehler" aussehen soll.

Ich vermute auch ganz, ganz stark, dass wir Zeuge der Machenschaften des von der NSA schon vor Jahren eingeschleusten Jakob Bond geworden sind. Leider wird er es wohl nie zugeben (Omerta: ihr wisst, das Schweigegelübte von Mafia und NSA. Ist ja quasi fast das Gleiche), nur wer das Offensichtliche nicht sehen will und so…

Hast Du wenigstens am Rande mitbekommen, worum es geht? Nicht, gell? Also: es geht um die SSLVerifySignedServerKeyExchange-Funktion, in der eine schwer erklärbare doppelte Zeile aufgetaucht ist, die die ganze Funktion nutzlos macht und damit Man-in-the-Middle-Attacken ermöglicht (bspw. falsche Software-Updates unterschieben, etc. pp.). Und es geht darum, wie es sein kann, dass dann auch noch interessante Compiler-Flags benutzt wurden, so dass der Code überhaupt kompilierbar war (moderne Compiler haben Schutzmechanismen gegen derlei "Fehler" eingebaut), es geht unter anderem darum, wie Code-Reviewing bei Apple intern funktioniert und wieso das alles nicht aufgefallen ist.

Das sind die vorherige Version des Source-Codes und die aktuelle: Version 55179.13 und Version 55471

Zwischen beiden hat sich an einigen Stellen was geändert: . Erzähl mir doch bitte mal, welche Form "menschlichen Versagens" die Zeile 631 darstellen soll. Hier die aktuelle Fassung von sslKeyExchange.c inkl. Zeilennummern: .

Wie soll das gehen, an der Stelle "aus Versehen" die Zeile zu duplizieren, wo ansonsten nirgends in der Funktion weitere Änderungen vorgenommen wurden. Welche Sorte "Fehler" soll das sein? Erzähl einfach mal...
0
Weitere News-Kommentare anzeigen

Kommentieren

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