heise (25.02.2014): OS X Mavericks: Weiter warten auf den SSL-Fix
Auch am Montag wurde die schwerwiegende Verschlüsselungslücke in Apples jüngstem Mac-Betriebssystem nicht behoben. Dies könnte im Rahmen von OS X 10.9.2 erfolgen. Doch wann erscheint es? Sicherheitsexperten üben harsche Kritik.

Forbes (24.02.2014): Former Apple Security Engineer To Apple: 'Fix Your Sh-t'

Kristin Paget's Blog (23.02.2014): Dear Apple, FIX YOUR SHIT. Much love, Me <3

Golem (25.02.2014): iOS und OS X: BSI warnt vor Apples SSL-Lücke
Über seinen Bürgerservice informiert das Bundesamt für Sicherheit in der Informationstechnik über die gravierenden Lücken in Apples Betriebssystemen. Patches für iOS 6 und 7 und das Apple TV gibt es, ein Update für OS X steht aber immer noch aus.

BSI Bürger CERT (24.02.2014): Technische Warnung TW-T14/0018: Sicherheitslücke in Apple iOS und Apple Mac OS X

Da geht's ja drunter und drüber zu...

Tja, AVM wird von der Presse gelobt, dass sie in drei Tagen (eigentlich war der Fehler schon länger bekannt) einen schwerwiegenden Fehler behoben haben, der in mehreren Fällen zu erheblichem finanziellen Schaden geführt hat.
Apple behebt einen ebenfalls schwerwiegenden Fehler in vier Tagen und erntet Prügel von allen Seiten. So unterschiedlich kann die Wahrnehmung sein. Wahrscheinlich würden sie besser da stehen, hätten sie das iOS-Update ein paar Tage hinausgezögert …

Die Kritik ist wirklich absolut berechtigt, denn ein reiner SSL-Patch wäre in nullkommanichts erstellt gewesen und hätte die Sache geregelt. Mit 10.9.2 hätten sie sich dann Ziet lassen können.
Apples Vorgehen in diesem Fall ist vollständig gaga und inakzeptabel.

Security Spread (26.02.2014): About Apple security

+1

ZDNet.com: Apple's goto fail needs a massive culture change to fix
Summary: Apple may be shiny on the surface, but the recently revealed SSL security flaw means that something's rotten inside — or perhaps even poisoned.

+1

Sierkb

+1

Es ist leider keine ganz neue Erkenntnis, daß Apple bei der Software QS wie der Sicherheit noch...Raum für Verbesserungen hat.

LOL

der Hannes ...

Vor persönlichen Anmerkungen und Gelächter erst mal in den Spiegel schauen. Siehe gerade Dein Posting zu Adobe CC, investiere Deine Energie lieber in "lesen & lernen".

Was mich nach wie vor wundert: Warum dauerte es so lange, bis diese schwere Sicherheitslücke entdeckt wurde?

Leuten, die sich beruflich und somit professionell mit dem Thema "IT Sicherheit" beschäftigen, hätte dies doch schon nach wenigen Tagen in iOS und auch Mavericks auffallen müssen?

Spätestens die Jungs von Palo Alto Networks (und alle, die Zugriff auf solche Firewalls haben, und dazu zählen jede Menge größere Unternehmen) hätten sehr leicht zeigen können, wie ein "man in the middle" Szenario diese SSL-Lücke ausnutzen kann!

Marcel_75@work:

Frag' Apple.
Wie ich zuvor schon einmal schrieb: dieser Fall macht deutlich, dass, obwohl Apple den Sourcecode offengelegt hat, sich diesen außer Apple anscheinend niemand außer Apple anschaut, sich niemand außer Apple dafür interessiert. Weil Apples Opensource-Lizenz und Code unattraktiv für andere Entwickler ist.

Fehlersuche, Tests und Fehlerbeseitigung lagen/liegen somit allein an Apple. Und diesbzgl. wirft das alles nun ein Schlaglicht darauf, wie sauber und gründlich Apple intern arbeitet und testet -- da gibt es offenbar enorm Verbesserungsbedarf in puncto QA bzw. QA testing besonders im Hinblick auf Security. Erst recht, wenn man bedenkt, dass dieser so triviale Fehler offenbar schon seit Einführung von iOS6 (released im September 2012) bestand und (von Apple, von anderen, die davon profitieren konnten, womöglich nicht, nur haben die zum eigenen Vorteil geschwiegen) so lange unentdeckt blieb. Was der NSA (und bestimmt nicht nur der NSA) perfekt in die Hände spielte, um über eine lange Zeit hinweg Man-in-the-Middle-Abgriffe an iOS-Geräten machen zu können.

Im Grunde ein ziemlich großes Image-Desaster, ein Super-GAU und oberpeinlich das Ganze. Von wegen "iOS ist sicher" -- das Gegenteil ist da der Fall gewesen. Und die Frage steht im Raum: was kommt da evtl. noch hoch, was ist da evtl. noch unentdeckt geblieben? Ein Anlass für Außenstehende, sich Apples veröffentlichten Code ab nun mal regelmäßiger genauer anzuschauen und Apple bei dem nicht veröffernlichten auf andere Weise auf die Finger zu schauen bzw. darauf zu drängen, dass Apple sauberere und gründlichere Arbeit abliefert.

Auch Aktionäre sollten da diesbzgl. mal mehr Druck machen, sich diesem Thema stärker widmen und Apple in dieser Hinsicht antreiben. Alles eine Sache der Prioritätensetzung.

sierkb

+1

In vielen Unternehmen sind Code Reviews (iiiihhh.... da muss man ja Quellcode lesen!) unter der Würde der Security Experts. Die veranstalten lieber Workshops, QA Sessions und halten Vorträge in denen sie erzählen was für ein toller Hecht sie sind und welche tollen Sicherheitslücken sie im Alltag schon entdeckt haben.

Träum weiter!

Wirst du das tun?

+1

Mir fehlt dazu leider die Expertise und das Know-How, und da verweise ich mal bescheiden auf geeignetere Kandidaten. Es gibt aber andere, die meinen, diese Expertise, dieses Know-How zu haben bzw. lassen sich gerne als einen solchen Experten bezeichnen und zu solchen Themen interviewen oder schreiben Essays darüber (hauptsächlich, um OSX und iOS ob ihrer Großartigkeit zu feiern und gleichzeitig über Konkurrenten herzuziehen), ich nenne hier mal keine Namen, für die wäre das doch mal ein tolles Profilierungsfeld zu zeigen, was in ihnen steckt -- der Ruhm wäre ihnen gewiss.

Ich hätte den zwinkernden Smiley setzen sollen, dann wär's klar, dass das wohl nur ein Traum bleiben wird und der Gedanke fern der Realität.

Es ist tatsächlich eine spannende Frage, warum das so lange unentdeckt geblieben ist. Denn insbesondere iOS zählt wegen seiner Verbreitung (Plattform zehn mal größer als OS X), wegen seines Einsatzes in staatlichen Einrichtungen, in großen Konzernen, demnächst im Auto usw. zu einem der Angriffsziele und Forschungsfelder für Sicherheitsexperten, Zero-Day-Exploit-Verkäufer, Hacker, Jailbreaker und Co. Keine Black Hat-Konferenz, keine NSA-Nachricht und kein Sicherheitsgutachten ohne iOS - und niemand hat das gefunden, zumindest für eine ganz geraume Zeit? Obwohl der Source Code offen lag?!

Hannes Gnad:

Wer verirrt sich denn mal nach https://www.opensource.apple.com/ und setzt sich wirklich mit dem offengelegten Sourcecode von Apple auseinander? Offenbar nur sehr wenige bis keiner. Zumal Apple den ja immer erst auch veröffentlicht NACH einem erfolgten Release statt vorher (um evtl. Fehler auch von anderen rechtzeitig VOR einem Release-Termin rechtzeitiger finden zu können)? Und warum ist das so? Und warum ist das bei anderen Open-Source-Projekten (zumal dieser Größe) anders und gibt es dort eine Community, eine viel größere Community? Hat Apple eine Open-Source-Community? Oder hat Apple im Grunde nur sich selbst -- trotz offengelegtem Sourcecode? Stellt sich hier evtl. mal die Sinnfrage, ob es an Apples Stelle so sinnvoll ist, Open-Source auf diese verschlossene Weise zu betreiben anstatt transparenter und offener und mehr auf ein Miteinander setzend und in beiden Richtungen wirkend wie das in anderen Open-Source-Projekten ähnlicher Größe Gang und Gäbe ist?

Welcher Entwickler und Sicherheits-Experte da draußen hat denn Lust, die ganze Arbeit zu machen, und Apple legt ihm da noch Steine in den Weg, vergällt es ihm, verbietet ihm qua Lizenz, sich mit anderen Gleichgesinnten drüber auszutauschen? Ist das wirklich der Gedanke von Open-Source, den Apple da mit seinem Code lebt? Oder ist das eher ein "Friss oder stirb"-Gedanke, der auf andere eher abschreckend denn einladend wirkt? Fremdentwickler aus dem Open-Source-Lager sagen sich mehrheitlich offenbar jedenfalls "Dann behalte doch Deinen Code und pflege ihn selber, ich arbeite lieber an Code mit, wo es ein wechselseitiges Geben und Nehmen ist und wo meine Arbeit besser und vor allem fairer gewürdigt wird." Apples APSL , , ist für viele Open-Source-Entwickler trotz Nachbesserungen halt nach wie vor unattraktiv mitzumachen und sich an der Entwicklung zu beteiligen, andere Lizenzen, andere OSS-Projekte, die unter anderen Lizenzen als der APSL stehen, offenbar attraktiver.

Der Witz ist doch, dass diese unglaubliche SSL-Lücke ja auch ohne "Open Source" hätte auffallen müssen!

Korrigiert mich, wenn ich es missverstanden habe, aber man konnte bis vor kurzem SSL-Verbindungen mit "man in the middle"-Angriffen belauschen, die den Diffie-Hellman-Schlüsselaustausch verwenden (Verbindungen, die auf TLS v1.2 beruhen, waren nicht betroffen, aber das sind ja nach wie vor die wenigsten).

Und solche Szenarios lassen sich z.B. mit oben erwähnter Palo Alto Firewall sehr einfach nachstellen (und abseits dieser im Enterprise-Markt bekannten Lösung gibt es sicher noch jede Menge andere Tools, mit denen das sofort hätte auffallen müssen).

Haben denn etwa weltweit alle blind darauf vertraut, dass das (so ein essentieller Bestandteil eines Sicherheitssystems für Netzwerkverbindungen) schon funktionieren wird?

Wer hatte diesen schlimmsten aller anzunehmenden bugs denn letztlich entdeckt? Apple selbst? Weiß es gerade nicht ...

PS: Auch das von mir eingesetzte Banking-Programm "MoneyMoney" nutzt z.B. die SSL-Implementation von Apple und war somit von dem Problem betroffen.

Marcel_75@work:

Spätestens jetzt weiß Apple, wie zentral wichtig ein funktionierendes SSL ist und dass sie sich da in Zukunft besser und an erster Stelle drum kümmern müssen -- wenn's löchrig ist und sie sich zu allem Überfluss dann auch noch dilletantisch verhalten beim beim Patch-Management und dadurch 4 Tage lang ihre Plattform für vogelfrei erklären und zum Abschuss freigeben, nützen alle guten Vorsätze nix, die man an anderer Stelle vielleicht mal gehabt hat.

Lernen durch Schmerzen.

Offenbar. Apple glaubt man ja so Einiges.

+1
Zusatzfrage: wann? Wann genau? Dann, als es ruchbar geworden ist, oder schon vorher?
Schön, dass Apple stets so offen und transparent alles kommuniziert und dokumentiert...

Nun, den Argumentationen einiger (Foren) User folgend ist Open Source *per se* ja sicherer und somit zwingend besser. Das auch offener Code erstmal von jemanden gesichtet werden muß spielt da keine Rolle. Jede kleine Klitsche wird wegen OpenSpource hochgejubelt und deren Produkte mit +10 Vorabpunkten ins Rennen geschickt. Für den "Normalen User" ist damit aber nichts besser und schon gar nicht zwangsläufig sicherer. Normaler User versteht nämlich auch noch so offenen Quellcode nicht, kann somit nicht beurteilen was da geschrieben steht und muß sich wiederum auf Aussagen Dritter verlassen, die entweder einen Fehler gar nicht suchen oder ihn bisweilen ebenso übersehen können.

warum trotz Open Source Fehler nicht automatisch "besser" erkannt und gefunden werden, lässt Stefan Esser (@i0n1c) in einem Nebensatz im heise Interview durchblicken =>

Zitat:
Im Grunde ist es also schön wenn es OpenSource Software gibt, aber in der Praxis setzt sich mit dem Code kaum jemand auseinander. Wenn dann eher verstärkt bei Projekten die für das finden von Fehlern im Quellcode eine Prämie bereitstellen. - Wieviel von den ach so tollen hunderttausenden Open Source Projekten werden das wohl sein?

Um nicht mßverstanden zu werden: Ich finde OpenSource grundsätzlich einen guten Ansatz. Vor allem im Zusammenhang mit einem entsprechenden Lizenzierungsmodell, welches die Verwendung von SourceCode in eigenen Projekten gestattet. OpenSource und offene Lizenzpolitik sind aber zum einen nicht zwangsläufig das gleiche und ersteres *garantiert* im Grunde per se erstmal *nichts*. Weder Qualität, noch Sicherheit, auch wenn es die Möglichkeiten dazu bietet. In der Theorie.

Vielleicht musste Apple ja erst genügend Serverkapazitäten organisieren. Wenn man bedenkt wie die bei neuen OS X Versionen in die Knie gehen und das Geschrei los geht, möchte ich mir nicht vorstellen was los wäre wenn gleiches bei dem Update passiert wäre. Ich glaube dann wäre der Aufschrei deutlich größer weil sich dann auch die Aufregen die nicht jedes kleine Informatiönchen von oder über Apple wie ein Schwamm aufsaugen.

Nichts desto trotz hätten sie sicher schneller reagieren können und müssen. Naja aus so etwas wird man halt schlauer. Hoffentlich gilt das auch für Apple.

Im Normalfall wird zwischen beiden Parteien ausgehandelt, was verwendet werden soll. D.h. wenn der anfragende Client mehrere Methoden kennt und die Gegenstelle (also der MITM-Proxy oder -Server) behauptet, sie könne halt leider nunmal nur die verwundbare Variante... dann hat sie gewonnen. Nur wenn die Client-Implementierung ausschließlich TLSv1.2 sprechen will, war man sicher. War das bei Apple der Fall?

Sagen sie nicht -- keine Credits: http://support.apple.com/kb/HT6150. Diese nicht existente "Fehlerbehandlungskultur" dort vaporisiert förmlich alle anderen und in manchen Bereichen durchaus löblichen Ansätze bzgl. IT-Security in Apple-Implementierungen komplett. Leider.

Bitte was? So einen Unfug glaubst Du doch hoffentlich selbst nicht?

Würde ich es glauben hätte ich nicht vielleicht sondern ich denke oder ich glaube geschrieben.

Aber vorstellen kann ich es mir schon, wenn auch nicht das sie dafür eine Woche brauchen.
Ich konnte es jedenfalls flott runterladen, da hatte ich schon schlechtere Verbindungen zu den Servern zum Runterladen bei Aktualisierungen.

Die einen können sich vorstellen das es extra für NSA und Co eingebaut worden andere können sich halt vorstellen das Apple Kapazitäten schaffen musste das es reibungslos runterladbar ist. Möglicherweise ist das eine oder das andere Unfug, ich kann mir aber auch vorstellen das beides Unfug ist.

An alle, die ein wenig in das Thema eingetaucht sind: Ich erinnere mich auf irgend einer amerikanischen Seite gelesen zu haben, dass dieser Bereich des Codes (also der mit dem schwerwiegenden bug) zusätzlich mit speziellen Compiler-flags versehen war, damit es nicht auffällt beim compilieren ...

Leider habe ich den Link nicht mehr parat.

Was ist da dran?

kawi:

Du lässt in Deiner Betrachtung geflissentlich unter den Tisch fallen, dass Apple es Nicht-Apple-Entwicklern unnötig erschwert, da reinzuschauen, Code anzuschauen, anzufassen, Bugs zu melden und zu fixen. Du kannst nicht Kritik an Open-Source an sich üben, wenn diese Voraussetzungen bei Apple bislang völlig hinderlich und abschreckend gegeben sind, sodass das Pflänzchen am Erblühen gehindert wird. Denn im Nehmen von Open-Source aus anderen Quellen (deren Open-Source-Community und Code-Review im Gegensatz zu Apples Ansatz transparenter und deutlich lebhafter ist), ist Apple groß und geübt, sonst gäbe es keinen Unix-Unterbau von OSX und iOS, also kein Darwin. Nur im Zurückgeben Unterordnen unter allgemeine Open-Source-Gepflogenheiten ist Apple eher sehr zurückhaltend.
Zumal die hier gefundene fehlerhafte SSL-Implementierung Apples eine von der allgemein genutzten und auch von Apple bislang fehlerfrei genutzten OpenSSL-Implementierung allein auf Apples Mist gewachsen ist, die überall sonst und auch von Apple bis dahin genutzte OpenSSL-Implementierung hat den Fehler ja nicht.

Oracle hat auf dieselbe Weise es auch geschafft, Solaris bzw. OpenSolaris zu killen bzw. die Community da herum zum Erliegen zu bringen und diese genötigt auf Solaris-Forks auszuweichen. Indem sie die OpenSolaris-Quellen geschlossen haben und den Sourcecode erst NACH Erscheinen eines jeweiligen Releases veröffentlichen. Total unattraktiv für Entwickler. Und sicherheitstechnisch gesehen im Grunde für die Katz, weil zu spät.

Schaue Dir doch mal die Projekte in Apples eigener Open-Source-Bucht Mac OS forge (gehostet bei Apple) an: wer ist deren Betreiber, wer sind deren Entwickler, manches Projekt, das dort annonciert ist, wird offen kaum gepflegt, sondern eher im Verborgenen? Die Entwickler sind hauptsächlich Apple-Leute, sie pflegen ihre eigenen Produkte (XQuartz vor allem vom Apple-Mitarbeiter Jeremy Huddleston, CUPS vor allem von CUPS-Initiator und Ex-Easy Software-Gründr Michael Sweet, launchd wird unter Ausschluss der Öffentlichkeit entwickelt, obwohl ursprüngl. offengelegt, MacPorts wird ebenfalls hauptsächlich von Apple-Leuten geführt und entwickelt, etc. pp.).
Wo ist da die große, diversifizierte Nicht-Apple-Community, aus der sich Leute rekrutieren lassen, die da mal mit geschultem Auge ein Code-Review machen, Tests machen, vor allem: Tests schreiben (ExMacRabbitPro sagte es ja bereits, das ist lästige Arbeit), ja überhaupt die Lust dazu haben? Ich kenne selbiges leidiges Thema aus der Arbeit im und rund ums W3C und beim Vorankommen der Spezifikationen. Deren Zeitplan und Vorankommen ganz wesentlich an Reviews und Tests hängt und niemand, auch die großen Browser-Hersteller nicht, so wirklich Lust dazu hat, diese undankbare Kärrner-Arbeit zu machen. Und deswegen hängt so manche Spezifikation (auch HTML5) manchmal so lange in der Warteschleife und kommt auf der Leiter zwischendurch mal nicht voran, wartet auf "Grünes Licht".

Warum veranstaltet Apple nicht z.B. wie Google sowas wie einen alljährlichen "Google Summer of Code" , , auch MacPorts z.B. ist da wieder ein Projekt, das da mitmacht und in diesem Rahmen verbessert wird. Und Google hat sich zudem noch vorgenommen, alle möglichen zentralen Open-Source-Projekte, die sie selber verwenden und die ihren Einsatz in Android haben, nach und nach ganz gezielt einem sicherheitstechnischen Code-Review zu unterziehen, wovon diese Projekte und alle diejenigen, die sie einsetzen (also auch Apple), natürlich profitieren.

Warum kriegt Google sowas auf die Beine und Apple nicht? Apple müsste sogar noch mehr Eigeninteresse für sowas haben und könnte davon sehr profitieren, ein Äquivalent zu sowas wie einem GSoC zu veranstalten, bei dem Open-Source-Stack, der bei ihnen in Darwin (Grundlage für OSX und iOS) zum Einsatz kommt. Wieso schwimmt Apple bei sowas nicht vorne mit dabei?

eiq:... und drei Tage waren nur der optimale Fall. Die 3270er Fritzbox (immerhin nur knapp ein Jahr alt) hat deutlich länger auf den Fix warten müssen (bis zum 10.2., wenn ich mich recht erinnere), und wie sich zwischenzeitlich ja herausgestellt hat, war das von AVM propagierte Abschalten des Remotezugangs nicht ausreichend, um die Lücke zu stopfen.

Man darf sich aber nun nicht zurücklehnen und sagen 'die anderen können es ja auch nicht besser'. AVM und Apple haben beide Mist gebaut, und zwar gründlich. Bei Apple wird es nur mit mehr Genuß breitgetreten, AVM-Hater sind eher selten ...

Sicherheitsupdates bringen gar nichts. Zumindest so lange, wie sie nicht installiert werden. Wenn man sieht, wie viele noch nicht iOS 6.1.6 oder 7.0.6 installiert haben, da wird einem schwindelig. Noch besser sind die Idioten, die lieber bei einer alten iOS 6-Version bleiben anstatt 7.0.6 zu installieren.
Bei Mac OS ist es ähnlich - besonders die "Snow Leopard ist das über-Mac OS"-Fraktion darf sich hier angesprochen fühlen.

Wie gesagt, Sicherheitsupdates sind schön und gut - wenn sie vom Nutzer installiert werden.

PS: Natürlich ist daran auch Apple schuld, weil sie iOS 6.1.6 nicht für das iPhone 4-5 rausbringen und sich weigern, das viertletzte Mac OS mit Updates zu versorgen.

Peter Eckel:

Wie lange war die Lücke bei den AVM-Routern existent?
Wie lange war die Lücke in iOS existent? Seit September 2012.

Hat AVM alle seine Router, die diese Lücke aufgewiesen, gleichzeitig gepatcht? Ja.
Hat Apple alle seine Produkte, die diese so zentral wirkende SSL-Lücke aufgewiesen haben, gleichzeitig gepatcht? Nein. Und vor allem DAS wird ihnen sehr angekreidet. Denn der Mac stand genau diese 4 Tage, in denen die Lücke einem großen Publikum bekannt war spätestens mit dem Patch von iOS, komplett schutzlos und nackt da und zum Entern bereit.
Das hat AVM nicht geschafft bzw. hat dem durch die Gleichzeitigkeit ihres Ausrollens des Firmware-Updates vorgebeugt.

Ich sehe da schon deutliche Unterschiede in der Gefährlichkeit und und der Art des Umgangs mit dieser Gefährlichkeit. Zumal es weltweit ganz sicher mehr iOS-Geräte und Macs gibt als AVM-Geräte, der Kreis der Betroffenen und des potentiellen Schadens bzw. der Kreis der dem Risiko Ausgesetzen bei Apple ein viel größerer ist als der bei AVM. Und eine heftigere Schelte in Richtung Apple somit nur natürlich und unausweichlich.

Ich glaub, Du erinnerst falsch. Die ersten Analysen nach der Veröffentlichung des Fix für iOS wiesen alle darauf hin, dass so ein Code-Malheur eigentlich sogar mit normalen Compiler-Settings auffallen müsste und unkten daher, dass bei Apple auch noch an den Compiler-Switches gedreht wurde, damit sich sowas überhaupt kompilieren läßt. Leider falsch geraten: Bei dem von Apple verwendeten Compiler ist der Schalter, um sowas zu finden, kein default und beim "Standard" gibt es den Schalter aber der hat seit Jahren keine Funktion mehr: http://blog.fefe.de/?ts=adf5a1ff

Aber das ist beides keine Entschuldigung genauso wenig wie das immer wieder vernehmbare "Ja mei, Fehler können mal passieren. Ist doch alles nur menschlich", das viele so bräsig vortragen. Natürlich können Fehler passieren und sie passieren auch. Andauernd. Und genau dafür gibt es Strukturen (personeller und technischer Art), die das Auffinden von Fehlern bzw. das Eindämmen/Eliminieren ihrer Konsequenzen ermöglichen.

An einen Statiker stellt man beim Bau eines Hochhauses auch bisserl andere Anforderungen und prüft dessen Arbeitsergebnisse lieber noch mehrfach. Weil die Konsequenzens eines Fehlers an der Stelle halt nunmal fataler sind als wenn bspw. beim Fundamentgießen ein Hilfsarbeiter, der sich schon 'nen Kasten Bier reingestellt hat, einen Kronkorken einbetoniert.

Jetzt überleg doch mal: Mavericks, Mountain Lion und Lion rumpeln jeweils mit paar GByte daher. Das 10.9.2-Update war irgendwas zwischen 700 und 900 MByte schwer (je nachdem, welche Version man sich eingefangen hatte). Ein Patch, der nur diese Lücke geschlossen hätte, wäre nur ein paar MByte groß gewesen (bzw. ist nur so groß gewesen: siehe iOS- und AppleTV-Update und die inoffiziellen Patches).

Die Applesche Installer- und Software-Update-Infrastruktur (die teilweise auf internationalen CDN-Providern aufsetzt) stemmt sowas problemlos, die Verbreitung von iOS (für das der kleine Patch ja 4 Tage früher bereitgestellt wurde) ist mindestens zehnmal so groß wie die von 10.9... die Idee, dass sowas ausgerechnet an fehlenden Serverkapazitäten gelegen haben könnte, ist völlig haltlos im "großen Kontext", was über diese Serverinfrastruktur alles noch so läuft. Das war ein Management-Fallrückzieher ins eigene Tor... der hoffentlich Konsequenzen hatte.

Bitte was? Äh, nein, haben sie nicht. Und sie haben den eigentlichen Angriffsvektor meines Wissens auch nie richtig benannt sondern das hat dann erst wieder Heise Security aufgedeckt, dass die Lücke die meisten Modelle betrifft. Aber es ist völlig egal, was AVM macht, wenn es um Fehler von Apple geht. Ein Fehlverhalten hier wiegt doch keines dort auf?

Thomas Kaiser:Leider nicht, Apple ist da, was die Präferenzen der Algorithmen angeht, eher performance- als sicherheitsorientiert, was allerdings auch zur Folge hat, daß die EDH-Algorithmen in der Präferenzliste der Clients ganz weit hinten stehen, die Verwundbarkeit also wahrscheinlich eher selten zum Tragen kam.

Umgekehrt kann man mit ein wenig Aufwand auf dem Server TLS1.2 und EDH erzwingen. Auch dann ist man auf der sicheren Seite. Das ist natürlich nur dann anwendbar, wenn man seine Mail- und Webserver selbst verwaltet (oder einen sicherheitsorientierten Provider hat), und wenn man auch auf der Clientseite einigermaßen die Kontrolle hat, was zum Einsatz kommt.

Für Webserver läßt sich die Präferenz sehr schön mit Hilfe des Online-Tools von SSLlabs austesten. Wenn man ein wenig tiefer in die Sache einsteigen und z.B. Mail- und andere SSL/TLS-Server untersuchen will, gibt es z.B. sslscan oder - deutlich ausführlicher - sslyze. Gerade wenn man einen gesicherten Server aufsetzen will ist das ziemlich hilfreich.
Ganz falsch ist das nicht. Serverkapazitäten sind eher nicht der Knackpunkt, aber bekanntermaßen nutzt Apple Akamai als CDN. Bei einem größeren Update von Mac OS X wird Apple dort die erforderlichen Bandbreiten vorab reservieren müssen. Was auch einen Teil der Erklärung des zeitlichen Abstandes zwischen IOS-Fix (der recht klein war) und Mac OS X-Fix (komplettes Minor Update) liefert.

Man darf sich allerdings immer noch die Frage stellen, warum der SSL-Bug nicht vorab per Einzelupdate herausgebracht wurde. Bei IOS ging es ja auch, und bis zum IOS-Update war der Bug nicht weithin bekannt. So, wie sie es jetzt 'gelöst' haben, haben sie sehr sauber eine Zero-Day-Lücke für Mac OS X bekanntgemacht, und das war schon selten dämlich.

Nein, da vergingen vom aktuellen Top-Modell bis zum ältesten betroffenen Modell auch einige Tage. Und auch nur unter Druck von heise, was eigentlich genau das Problem ist, und welche Modelle es betrifft etc. Aber hier off topic.

OK. Dann habe ich das wohl falsch wahrgenommen. Ich dachte, sie hätten ihren Routern der betroffenen Modell-Palette das Firmware-Update gleichzeitig verpasst. Irrtum meinerseits, mea culpa.

Und sie haben den eigentlichen Angriffsvektor meines Wissens auch nie richtig benannt sondern das hat dann erst wieder Heise Security aufgedeckt, dass die Lücke die meisten Modelle betrifft.[/quote]

+1

Das sehe ich ganz genauso. Es darf als reines Ablenkungsmanöver gewertet werden, hier mit dem Finger auf andere zu zeigen, die es genauso schlecht oder noch schlechter gemacht haben. Nach oben orientieren, an den und dem Besseren orientieren und nicht nach unten hin.

Siehe gerade Gesagtes. AVM ist nicht Apple, und Apple ist nicht AVM.
Zudem: ich dachte, Apple spielt in einer eigenen Liga und gehört zu den Besten bzw. ist der Beste und gibt den Ton an? Warum bei Fehlern dann zur Seite oder gar nach unten blicken statt an sich herunter und zum Besseren (in puncto Patch-Management und Schnelligkeit in der Reaktion wäre z.B. Mozilla jemand, von dem man diesbzgl. lernen könnte oder auch Google) hinauf? Nicht ausgerechnet bei Fehlern gleichzeitig mit dem Finger auf andere verweisen und sagen "Die aber auch". Diese hier gemachten Fehler (es war ja eine ganze Kette von Fehlern) hier ist zudem 100% hausgemacht und made by Apple. Niemand sonst ist dafür verantwortlich. Und es ist überhaupt nicht zielführend und nützlich, hier mit dem Finger auf andere zu verweisen, das kann nur als Ablenkungsmanöver verstanden werden und deutet auf wenig Übung und Souveränität mit sowas hin sondern eher auf "kalt erwischt" und Dünnhäutigkeit in der Reaktion.

Und viel wichtiger: AVM hat den Usern Quatsch erzählt: "Schaltet Fernwartung aus und alles ist pipifein". Derweil betraf die Lücke auch generell Erreichbarkeit der Box per HTTP, d.h. von innen. Heise Security hat ja dann gleich einen Skript-basierten Exploit rausgebracht, der über eine manipulierte Webseite Daten von dem Gerät mit dem Namen "fritz.box" gelutscht hat. Und nochmal: Wenn Apple Scheize baut, dann baut Apple Scheize, völlig egal, wieviel Scheize andere rundherum bauen mögen oder nicht. Was sollen diese Vergleiche überhaupt? Wieso soll man Probleme mit Verweis auf sonstwohin runterspielen?

Verständnisfrage: Wenn ich einen mitmproxy nutze und den zwischen Client und Server stelle, dann ist es nach meinem Verständnis doch völlig egal, was der Server will, wenn zwischen Client und Proxy was ganz anderes ausgehandelt wird. Abhilfe brächte doch da eigentlich nur, auf Client-Zertifikate zu setzen, was a) nicht geschieht und b) auch schon wieder negativ aufgefallen ist:

Eben. Das ist doch der Punkt. Wenn ich weiß, dass ich ein großes Update nur mit Vorlauf rausbringen kann, dann muß ich halt einen kleinen Fix vorab rauswerfen oder den für iOS/AppleTV noch verzögern. Beinah am Schlimmsten in dem Kontext finde ich, dass Apple bzgl. des Grunds für die Entscheidung, die Lücke in iOS sofort zu fixen und bei OS X nicht... einfach die Fresse hält. Das Gschmäckle läßt sauer aufstoßen. Selbst wenn man im Hinterkopf hat, dass sich die Kollegen von der NSA beömmeln darüber, dass man auch ohne Apples Beistand im konkreten Einzelfall immer und jederzeit in iOS-Devices eindringen kann...

Der AVM-Apple-Vergleich wurde weiter oben in diesem Diskussionsfaden angerissen und auch schnell wieder als unpassend wie off-topic verworfen, es geht hier daher nicht um Fingerzeigen.

Es herrscht eigentlich weitgehend Einigkeit darüber, daß Apple hier in allen Bereichen (von der Entwicklung über die QA bis zur Doku und dem Patch-Management) nicht ordentlich gearbeitet hat, und daß nun endlich eine massive Kursänderung angezeigt wäre, ein echter Kulturwandel im Umgang mit dem Thema "Sicherheit".

+1

Eigentlich ist das spätestens seit Flashback und Apples Umgang damit (Apple kämpft an der Front heute immer noch, kauft deshalb heute, im Jahr 2014 und Dezember 2013, immer noch Domains auf, um die betreffenden dahinterstehenden C&C-Server trockenzulegen, da da draußen immer noch gekaperte Zombie-Macs herumlaufen, die eine Gefahr für alle sind) offensichtlich, dass Apple da dringend eine Kursänderung einschlagen muss.
Wieviele Einschläge braucht's noch und welcher Güte, bis sich bei Apple endlich grundsätzlich und spürbar was ändert? Wie schlimm muss es denn noch kommen, bis sich der Tanker bewegt?

Thomas Kaiser:Das ist natürlich korrekt. Sofern der mitmproxy ein Zertifikat hat, dem der Client vertraut (und das sind ja nun bekanntermaßen ein paar zuviele), hilft ein festgenagelter Server auch nicht mehr. Leider sind mir derzeit auch keine Clients bekannt, bei denen man ein Serverzertifikat als allein gültiges festlegen könnte.

Das ist leider einer der Punkte, an denen man sehr schön sehen kann, daß die PKI-Infrastruktur schon prinzipiell kaputt ist.
Nicht uninteressant, danke für den Link. Es steht zu hoffen, daß die Exploits länger auf sich warten lassen als die Updates (wobei man sich wohl nicht der Illusion hingeben darf, daß die dann auch überall eingespielt werden ...).

Andererseits ist der Angriff schon rein prinzipiell in der breiten Masse weniger interessant, weil, wie Du ja bemerkst, Client-Zertifikate eher exotisch sind (auch weil viele Clients das einfach nicht können).

Ah ok, dann hatte ich das beim überfliegen des Textes falsch verstanden. Fefe hat es ja gut erklärt.

Und hier gleich die perfekte Ergänzung zum Thema: http://heise.de/-2132674

Man sollte sich langsam mit der Erkenntnis abfinden, dass diese kleinen Router-Kasterl einfach nix taugen. Was man aber an Erkenntnissen aus obiger Heise-Meldung ziehen kann, ist ganz simpel:

• Apple: So einfach kann das SSL-Debakel ausgenutzt werden: Angreifer übernimmt den Router, manipuliert DNS und schon ist praktisch alles, was auf SSL aufsetzt, im Arsch. Punkt.
• AVM: Siehe die TP-Link-Variante. Man schickt dem Opfer eine manipulierte Mail, das Opfer klickt drauf und peng ist der Router übernommen bzw. im Fall der Fritzboxen mindestens auslesbar. Obwohl der Angriff soz. "von innen" kam

Und was lernen wir bzw. der Security-Laie daraus: Es ist halt alles viel komplexer als man sich als Laie vorstellen mag. Im Falle der Appleschen SSL-Verschisselung reicht es eben nicht, Vertrauliches nur innerhalb der eigenen 4 Wände zu erledigen, im Falle AVM darf man dem Hersteller nicht trauen, der erzählt das Probleme wäre durch deaktivierten Fernwartungszugang zu lösen.

Das ist ja das fiese psychologische Problem, diese vermeintliche Abschottung vor äußeren Gefahren. Das funktioniert nicht nur gesellschaftspolitisch so famos (die Ausländer sind an allem schuld) sondern eben auch in punkto Sicherheit: Alles Böse von kommt von außen... Weit gefehlt.

Ich bin kenne die Anwendungsentwicklung von typischen Client-/Server-Systemen in Großunternehmen ganz gut.

Und jedes Mal, wenn ich, wie bei diesen Bug-Debakeln, meinen Blick auf das Feld der Systemprogrammierung richten muss, bin ich erschüttert, dass man hier ganz offensichtlich methodisch noch nicht im 21. Jahrhundert angekommen ist. Meines Erachtens sind das alles Fehler, die sich bereits mit einfachen Unit-Tests hätten vermeiden lassen. Aber solche existieren offensichtlich nicht. Und das bei Software-Produkten, die über mehrere Jahre weiterentwickelt und verändert werden. Das alles beunruhigt mich eigentlich am meisten.