Wenn Apple gut gearbeitet hat ist es völlig irrelevant, wenn nur der Quellcode veröffentlicht wurde.

Ein gutes Sicherheitskonzept basiert eben nicht auch Security by Obscurity.

Der Bootprozess basiert darauf, dass nur ein signiertes OS geladen wird. Gefährlich wird es erst, wenn der privat key mit dem das OS signiert wird ebenfalls öffentlich wird. Das scheint aber nicht der Fall zu sein.

Gruß Marc

Offene Quellen führen in der Regel zu einer höheren Sicherheit.
Wenn da keine technischen Schulden vorhanden sind oder fest hinterlegte schlüssel im Code stehen gibt es keine
Gefahr für Anwender.

Sollte Apple allerdings hart gepfuscht haben ist Polen offen.

Eben! Aber anscheinend schreiben gerade alle wieder voneinander ab. Heise meldete das ganze genauso unreflektiert wie 9toMac und MTN.

Mtn ist sozusagen die deutsche version von 9to5mac

Warum auch nicht.

Dirk!
Hu? Ob Quelloffenheit zu mehr Sicherheit führt oder nicht ist Teil von heißen Diskussionen - meine Ansicht ist, dass es dadurch einfacher wird, wenn der Code zur Verfügung steht. Außerdem ist kein etwas komplexerer Code perfekt und ohne Mangel - diese zu identifizieren wird durch dieses Leak deutlich einfacher.

+1

Das heißt also iOS wird durch diese Veröffentlichung noch sicherer weil Apple nachbessern muss falls dort was gefunden wird.

Inhaltlich stimme ich dir zu, aber diese Metapher finde ich respektlos. .

MetallSnake
Falls eine bisher unentdeckte Stelle im Code gefunden und veröffentlicht wird, wird es erstmal unsicherer. Wenn es eine Stelle ist, die schon im Hack-Gebrauch ist aber noch nicht öffentlich bekannt ist, Apple aber gemeldet wird, ist dies der Sicherheit zuträglich.

sierkb
Ein toller Spruch für eine Häkeldecke , hat nur leider mit der Praxis nichts zu tun. Jeder Code (Trivialcode ausgenommen) hat Fehler, Lücken und Unzulänglichkeiten - steht der Quellcode zur Verfügung, haben Angreifer eine weitere Recherchemöglichkeit.

Genau, erstmal aber danach wird es sicherer. Und ob diese Lücken die dabei gefunden werden nicht vielleicht schon von den ganz bösen Jungs (also z. B. die NSA ) genutzt wird kann auch niemand wissen. Also ist die Veröffentlichung der Sicherheit im Endeffekt nur zuträglich.

Ich weiß nur nicht wie hoch die Motivation von white hat Hackern ist sich 3 Jahre alten Quellcode anzugucken um Lücken im aktuellen System zu finden. Eine mögliche Reaktion von Apple wäre die mit iOS 12 weiteren Quellcode Open Source zu machen, so wie sie in der letzten Zeit damit schon angefangen haben.

Der, der den Spruch da gebracht hat (Jörg Schilling aka Schily – besser bekannt von OpenSolaris bzw. Schillix bzw. Illumos oder auch als technischer Beisitzer im POSIX-Rat bzw. der OpenGroup, die die UNIX-Zertifizierung vornimmt), weiß, wovon er redet und warum er den Spruch gebracht hat. Und er hat Recht mit dieser Aussage (wie meine Vorreder obig ebenso). Eben weil dieser Spruch nicht von irgendwem Dahergelaufenen gekommen ist, habe ich ihn hier verlinkt. Und er hat ja Recht mit seiner Aussage. Wenn der Code sauber geschrieben ist, ist nichts zu befürchten, und dann hält er jeglicher öffentlicher Begutachtung stand.

Das gefällt mir sehr gut, da ich weder Zeit noch Lust für Heise, 9to5Mac und diverse andere Quellen habe.

subjore:

,

Nein, ist es nicht.

In der Fachwelt ist das längst „gesetzte“ Wahrheit, und die Praxis zeigt auch genau das. Als Entwickler sehe ich auch genau das.

Diskussionen gibt es eigentlich nur, wenn Lieschen Müller das nicht gerafft hat und immer argumentiert, es könne je jeder ihr Fahrrad klauen, wenn die Kombination des Schlosses offen läge. Aber so funktioniert Security eben nicht.

Firmen wie Cellebrite und XRY dürften sich freuen und somit die Agencies.

Geh' mal davon aus, dass die das alles schon längst haben und nicht erst seit jetzt:

Ich bin da ander Meinung, auch als Entwickler. *
Quelloffenheit ≠ Sicherheit.
Die Fachwelt kann kaum besweisen, ob ein SourceCode wasserdicht ist, abgesehen davon, dass er auf jeder Prozessorarchitektur/Compiler/Optimierung anders übersetzt. Und Hardware gibt es ja auch unten drunter (siehe Intel) .

Mit hinreichend Geld/Resourcen/Zeit kann man aber das Gegenteil/Unsicherheit beweisen!
Und das wird um so schwieriger/teurer/zeitintensiver wenn der nicht öffentlich ist.

Übrigens kann man in vermeintlich sicheren öffentlichen Code auch Schwachstellen einschleusen (OpenSSL), die erst viel später strotz der (wenigen?) "Spezialisten" gefunden werden. Das muss nicht mal böse Absicht sein.
Das man Code untersuchen kann heißt noch lange nicht dass es auch gemacht wird (schiere Menge)

*Reverse-Engeneering und Optimierung eines komplexen Multikanal-FT-Protokols als Virgin (also ohne SourceCode) auf der Leitung.

Genau das sagt ja auch keiner, dass OpenSource allein deswegen sicherer wäre. OS ist deswegen sicherER, weil sich viele dreckige Hacks verbieten, die sichtbar würden. Weil man Code-Analysetools über den Source laufen lassen kann. Weil man, auch ohne in den Code zu gucken, z.B. wenigstens Compilerwarnungen sieht. Weil sich bei OS so'n Quatsch verbietet wie „if passwort='abcxyz' dann root“.

Jedes Tool, das man auf Closed Source anwenden kann, sei es Fuzzing, Reverse Engeneering Assemblercode angucken, kann man auch auf OS anwenden — aber für OS sind die Tools deutlich mehr und mächtiger (Allein mal versuchen, ein minified JavaScript mit einem offenen Source zu vergleichen — das ist nicht mal übersetzt und trotzdem unleserlich).

Natürlich kann man auch in OS Programmierfehler machen. Oder andere Fehler. Natürlich kann ein Firma für ihre CS-Software ein Auditing bezahlen, während in quelloffene OpenSSL keine freiwillig reinschaut.

Aber das ist so ein bisschen, als würde man sagen, Nitroglyzerin ist genau so gefährlich wie Mehl, denn beides könnte ja explodieren. Ja — kann es. In der Praxis kostet explodierendes Mehl aber weniger Todesopfer als Nitroglyzerin.

Ein zweites Thema, das sich da auftut, ist dann auch die Reaktion. Ein Incident in OpenSource-Software kann sofort gefixt werden. Bei ClosedSource muss ich warten, ob und wann was kommt.

Das heisst auch nicht, dass ich das immer alles selber machen muss und könnte. Aber bei OS kann ich jemanden bezahlen, der das für mich macht. Bei CS sind mir die Hände gebunden.

Wenn man sich bewusst macht, was bei Apple in letzter Zeit so alles passiert ist (Stichwort in Mac OS als root anmelden ohne Passwort) bin ich mir nicht mehr so sicher, dass hier alles wasserdicht programmier wurde.

Sieht nicht gut aus. Habe mal reingesehen und es handelt sich nicht nur um ziemlich gut kommentierten Sourcecode, sondern jede Menge Dokumente in Pages, Excel, html als Beschreibungen und Referenzmaterial mit allerlei solchem "Zeug" (Zertifikate?):

Nicht nur das, das ein oder andere Gerät dürfte auch noch mit iOS 9 unterwegs sein, weil mehr gar nicht geht.

Der nächste Leak kursiert grad', diesmal iPhone Baseband…:

iPhone baseband source code leaked ,

Frage aus Interesse, weil ich mit Android unterwegs bin und das bei iOS nicht genau kenne:

Viele Androiden kommen ja von Haus aus mit einem überschreibbaren Bootloader — also kein „Jailbreak“, sondern offizielle „rootbarkeit“ des Gerätes. Menüpunkt auswählen —> Bootloader unlocked.

Trotzdem wäre mir nicht bekannt, dass das ein Problem wäre. Das System mountet die entsprechende Partition „read only“, liefert von Haus aus kein su/sudo-Binary mit, und der Kernel ist gehärtet und verweigert selbst einem wie-auch-immer-erlangten root-User trotzdem Schreibzugriffe (Ähnlich den aktuellen MacOSsen). Die einzige Möglichkeit, das System zu beschreiben, besteht darin, das Gerät sozusagen in einen „Ich-bin-eine-dumme-Festplatte“-Modus zu booten und mit Tools die Firmware zu schreiben.

Dabei gibt es zwei Modi:
- Üblicherweise wird die Signatur der Firmware überprüft. Das ist der Normalzustand. -
„gerootet“ heisst erstmal eigentlich nur: Signaturprüfung abschalten — dann kann man halt alternative Pakete einspielen, z.B. root-Tools.

So, jetzt die Brücke rüber zu iOS:

Wenn Apple jetzt seine Schlüssel gepublished hat, dann sind die Geräte im Prinzip im Status eines Androiden mit „unlocked Bootloaders“. Nicht weniger, aber auch nicht mehr. Also im Prinzip das, womit ich mit meinen Androiden seit Jahren rumlaufe — bzw. eigentlich sogar weniger, weil ich ja nicht nur unlocked, sondern auch rooted bin.

Ein konkreter Bedrohungsfall wäre dann also, wenn es einer App gelänge, ein gefaktes „Update“ gültig zu signieren, das dann eingespielt werden kann/muss. Aber ich vermute mal, dass das auch bei iOS kein Drive-by-Download ist, sondern erst mal erfordert, dass die signierte Datei von root an eine geschützte Stelle hinterlegt wird, oder?

Kurz gesagt:
Die iOS Lücke ist ziemlich genau das Feature, warum ich mich für Android entschieden habe: Weil ich den Bootlader überschreiben KANN, was aber nicht trivial möglich ist?

Bug oder Feature?

Das ist so eigentlich nicht so ganz richtig. Auch vor Veröffentlichung des Codes konnte man den object code analysieren und dekompilieren. Gerade für jene Spezialisten die sich mit der Suche nach Lücken hervortun ist das Tagesgeschäft. Mit dem Quellcode ist der Code natürlich leichter analysierbar - aber das ermöglicht eigentlich vor allem eher Laien einen leichteren Zugang. Oder Kurz gesagt: Für Profis in dem Metier ist die Veröffentlichung interessant aber keine Revolution. Insgesamt haben jetzt eben mehr Leute einen Zugang zur Funktionsweise dieses Codes - nicht jeder davon hat böses vor und schon alleine die Publicity etwas zu entdecken und zu veröffentlichen ist es für viele wohl wert. Gefundene Lücken sind dann auch weniger Wert weil sie ja leichter und demnach auch schlicht "öfter" gefunden werden. Sobald eine Lücke bekannt wird ist sie sowieso wertlos für Handel. Falls gefundene Lücken tatsächlich noch nicht gefixt sind können die in aktuellen Versionen behoben werden. Insgesamt erhöht sich damit auf lange Sicht die Sicherheit.