cm-7.2.0-jordan - Kritischer PIN Bug?

[Andromedario]

Hallo zusammen,

dachte ich starte hierfür mal ein neues Topic, da alle PIN Probleme von denen ich bisher gelesen habe, in eine etwas andere Richtung gingen (keine PIN Abfrage bei Rückkehr aus Flugzeugmodus / Reboot etc.)

Ich habe vor zwei Tagen von der CM 7.1.0-11 Stable problemlos auf die offizielle CM 7.2.0 Stable vom 16.06.2012 geflasht.

Wenn ich hiermit richtig liege, habe ich wohl einen Weg gefunden, eine aktive PIN-Abfrage zu umgehen. Bei nicht vorhandener (zusätzlicher) Tastensperre wäre das wohl im Falle eines Diebstahls der Worst Case.

Folgender Test:

(- PIN-Abfrage für SIM ("Lock SIM card") ist aktiviert)

- Defy runterfahren ("Power Off")
- Defy wieder einschalten
- Per Lautstärke - ins Bootmenü
- Im Bootmenü [Reboot] wählen

Ergebnis: Das Defy fährt hoch OHNE nach der PIN zu fragen!

Da ja auch bei einem "normalen Reboot" - anders als bei der CM 7.1-11 - keine PIN Abfrage mehr kommt, ist meine Vermutung, dass das Bootmenü einfach die gleiche Funktion aufruft wie ein Reboot bei laufendem Betrieb.

Kann das jemand nachstellen/bestätigen? Interessiert das evtl. auch den ein oder andern Dev?

Feedback wäre schön,
Gruß,
Andromedario

 

[diginix]

Kann ich bestätigen. Denke auch, dass es in dem Fall dass das Handy bereits komplett ausgeschaltet war auch bei Reboot aus dem Bootmenü trotzdem einmal eine SIM PIN erfragen muss.
Selbst mit einer fremden SIM nach Akkuentnahme ließe sich so booten und telefonieren.
Sprich es müsste sich bei shutdown irgendwo gemerkt werden, dass der anschließende manipulierte reboot trotzdem eine PIN erfordert.

 

[wieselmuff]

mal bei xda schreiben. maniac scheint z zt anderweitig beschäftigt zu sein.
gruß

 

[JanHimpIII]

Die zusätzliche Tastensperre/Sperrmuster des Telefons kommt bei mir in dem Fall übrigens auch nicht.

 

[JohnMcLane]

It's not a bug it's a feature...

Nein ich meine mich zumindest daran zu erinnern, dass maniac im nightly thread mal erwähnt hat dass das mit dem Pin wohl so gewollt ist, bzw. An einem bestimmten Modul liegt. Bei mir fragt er nach einem einfachen reboot oder flugmodus auch nicht nach dem Pin.
Die Abfrage kommt jedoch, wenn ich einmal ganz abgeschaltet habe oder im recovery war...

Gesendet von meinem MB525 mit Tapatalk 2

 

[diginix]

Die Abfrage kommt jedoch, wenn ich einmal ganz abgeschaltet habe oder im recovery war...

Aber nicht wenn du ganz abschaltest, dann ins Recovery/Bootmenü gehst und dann von dort ein Reboot auslöst. DAS ist der Bug.
Bei normalem Reboot aus dem laufendem System und nach Flugmodus ist es wie gehabt gewünscht und gut so.
Aber wenn das Handy mal aus war, Akku oder SIM raus war dann muss zwingend eine PIN abgefragt werden. Alles andere ist fahrlässig.
Ich kann aktuell von jedem Fremden die SIM sofort aktiv nutzen ohne je die PIN gekannt zu haben. wtf

 

[JanHimpIII]

Nach meiner Meinung sollte es folgendermassen sein, dann wär's OK:
Einschalten -> PIN-Abfrage
Reboot, egal woher -> PIN-Abfrage
Flugmodus aus -> keine PIN-Abfrage

(Ich meine, so wär's auch unter Froyo gewesen)

 

[Defier]

Ich kann aktuell von jedem Fremden die SIM sofort aktiv nutzen ohne je die PIN gekannt zu haben. wtf

Aha und wie soll das gehen? Das Defy wird ja höchstens deine eigene PIN irgendwo cachen und diese dann selbst eingeben wenn es merkt, dass du nur einen Reboot gemacht hast. Natürlich ist das hier ein Bug, aber ich kann mir nicht vorstellen, dass dadurch die Nutzung jeglicher SIMs ohne Eingabe der PIN möglich wird. Im Gegenteil - ich vermute, das Defy wird mehrfach die falsche PIN (nämlich die der vorherigen Karte) eingeben und die SIM dadurch sperren?

 

[diginix]

Ok, Denkfehler bzw. hatte meine 2. Test SIM die gleiche PIN. Dennoch bleibt eben der unschöne Effekt dass mit der eigenen SIM bei Verlust und ausgeschaltetem Tel. nach reboot gearbeitet werden kann. Solange eben die gecachte PIN zur SIM passt.

 

[maniac103]

Ich kann das Problem bestätigen. Ich vermute, dass es durch die Kineto-Unterstützung reingekommen ist. Ich habe in Zuge dessen 2 Libs (libmsl_interface.so und libmotdb.so), die mit der SIM zu tun haben, ausgetauscht. Wo die vorherigen Versionen herkamen weiß ich nicht (das weiß bestenfalls Quarx), die neuen kommen auf alle Fälle vom Stock-Froyo.

Hat das schon mal jemand im Stock-ROM mit installiertem Bootmenü getestet?

Bevor hier aber groß Panik geschoben wird (schon zu spät, ich weiß, wenn ich mir die Posts von Andromedario in diversen Foren anschaue ), bitte ich folgendes zu bedenken:

• Die SIM ist bei Diebstahl üblicherweise schon entsperrt
• Die SIM kann bei Diebstahl problemlos gesperrt werden
• In Anbetracht des vorherigen Punktes: Was ist euch bei Diebstahl wichtiger, die SIM oder die Daten auf dem Telefon (u.A. WLAN-Passwörter, vielleicht andere Passwörter und Zugangstoken, ...)
• Wenn es die Daten sind, warum stört euch nicht, dass das Bootmenü vollen Lese- und Schreibzugriff auf sämtliche Partitionen via USB erlaubt?
• Oder dass - bei aktiviertem Debugging - auch im laufenden Betrieb Root-Zugriff via USB möglich ist?

Ich bin im Moment dabei, die unteren Punkte zu fixen - mittels

• einer 'PIN' für Bootmenü-Direktzugriff (Tasten müssen in einer bestimmten konfigurierbaren Reihenfolge gedrückt werden), was auch gleich den erwähnten SIM-PIN-Bug erschlägt
• adb im laufenden System nicht mehr als root laufen lassen, was eine Voraussetzung ist für
• Backport der ICS-Root-Änderungen (Root-Zugriff im laufenden System abschaltbar machen)
• Reboot-Menü bei gesperrtem Bildschirm nicht mehr anzeigen (somit kein Bootmenü- oder Recovery-Zugriff von da aus mehr möglich)

Das sollte, zusammen mit einer konfigurierten Bildschirmsperre, den Angriffsvektor deutlich verkleinern. Mir fällt noch ein Weg ein, die Sperren dann zu umgehen, dieser ist allerdings nicht fixbar, weshalb ich ihn nicht verraten will

Ihr könnt ja mal versuchen, mit Ersetzen von /system/lib/libmsl_interface.so, /system/lib/libmotdb.so und /system/etc/motorola/comm_drv/mmins_telephony.cfg aus einem CM7.1- oder CM9-Build rumzuspielen. Immer eine Datei nach der anderen ersetzen und probieren, ob der Bug dann weg ist - wenn ja, Gegenprobe, d.h. Wiederherstellung der alten Dateien, nicht vergessen Ich hatte das schon mal probiert und uneinheitliche Ergebnisse bekommen (alle 3 ersetzt, Bug noch da - etwas mehr rumprobiert, Bug ist weg - so was in der Art), brauche allerdings im Moment mein Telefon einsatzbereit.

 

[diginix]

Bevor hier aber groß Panik geschoben wird (schon zu spät, ich weiß, wenn ich mir die Posts von Andromedario in diversen Foren anschaue ), bitte ich folgendes zu bedenken:

• Die SIM ist bei Diebstahl üblicherweise schon entsperrt
• Die SIM kann bei Diebstahl problemlos gesperrt werden
• In Anbetracht des vorherigen Punktes: Was ist euch bei Diebstahl wichtiger, die SIM oder die Daten auf dem Telefon (u.A. WLAN-Passwörter, vielleicht andere Passwörter und Zugangstoken, ...)
• Wenn es die Daten sind, warum stört euch nicht, dass das Bootmenü vollen Lese- und Schreibzugriff auf sämtliche Partitionen via USB erlaubt?
• Oder dass - bei aktiviertem Debugging - auch im laufenden Betrieb Root-Zugriff via USB möglich ist?

Na ganz toll, jetzt postest du einfach noch schlimmere Sicherheitslücken um die Gefährlichkeit einer anderen zu mindern.
Da die anderen bisher kaum einer kannte, hat sich wohl auch keiner dran gestört. Ich hatte mir bisher jedenfalls keine Szenarien überlegt mein Defy zu unterwandern. Mit dem jetzigen Wissen ist der SIM Bug ja noch trivialer als ich ihn ohnehin schon empfunden hatte.

Mein Notebook ist komplett getruecryptet mit Pre-Boot Authentication. Sowas gehört eigentlich auch auf ein Smartphone.
Mobile Geräte mit einer deartigen Mächtigkeit an persönlichen Daten sind bisher echt per default scheunentor offen. Leider ist mir für Android keine Verschlüsselung bekannt.
Ich nutze encfs auf der SD, aber das ROM+Data is unverschlüsselt.

 

[Defier]

@diginix: Also das was maniac103 da gepostet hat sind ja wohl keine neuen unenthüllten "Sicherheitslücken" sondern jedem doch schon längst bekannte Tatsachen.

Wenn du dein Smartphone verschlüsseln willst kannst du entweder auf ein Android 4 (CM9/CM10) umsteigen, oder wenn du bei 2.3.x bleiben willst beispielsweise den LUKS Manager oder nur das Backend davon vom Guardian Project nutzen:

https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager&hl=de

Damit wird auch dein Data verschlüsselt. Das ROM selbst mitzuverschlüsseln halte ich wegen dem größeren Angriffsvektor für Known-Plaintext-Angriffe für kontraproduktiv.

 

[Andromedario]

Schön, dass das Problem hier etwas Aufmerksamkeit erfährt und im Zuge dessen auch weitere sicherheitskritische Szenarien ans Tageslicht kommen (thx an dieser Stelle @maniac103 - feine Sache, dass Du an den von Dir zusammengetragenen Bugs dran bist )

Wäre mal interessant, ob's die (zukünftigen) Sicherheits-Optimierungen auch in die offiziellen CM Builds schaffen. (Sollte - zumindest was die CM7 angeht - die 7.2.0 nicht die letzte sein?)

Wie von maniac103 bereits erwähnt, war ich so frei und habe das Thema auch in anderen Foren zur Sprache gebracht. Die Resonanz ist bisher allerdings... naja... eher "verhalten".

Ich hoffe ich darf das hier verlinken - falls nicht, schon mal 'tschuldigung mit der Bitte um Edit:

XDA: http://forum.xda-developers.com/showthread.php?t=1764910
CM: Cm-7.2.0-Jordan - Cm 7.2.0 Stable - Possible Critical Pin Bug - Motorola Defy Stable Mod - CyanogenMod Forum

Zum Thema Encryption: Gibt's eigentlich schon ein Tool für Android 2.3.7, das nicht nur mit Containern, sondern auch mit ganzen Partitionen arbeiten kann? Also mit dem ich à la "True Crypt" eine Full-Volume-Encryption meiner SD-Karte vornehmen könnte? (inkl. Auto-Mount + Passwortabfrage bei Start + Auto-Dismount bei Shutdown?)

Beste Grüße,
Andromedario

 

[diginix]

wenn du bei 2.3.x bleiben willst beispielsweise den LUKS Manager oder nur das Backend davon vom Guardian Project nutzen:
https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager&hl=de
Damit wird auch dein Data verschlüsselt. Das ROM selbst mitzuverschlüsseln halte ich wegen dem größeren Angriffsvektor für Known-Plaintext-Angriffe für kontraproduktiv.

Also mit dem Luks Manager kann ich /data nicht auf einfache Weise verschlüsseln.
Ich müsste wohl ein Container erstellen dort alles aus /data reinlegen und den dann ggf. als /data mounten oder symlinken. Den bestehenden einfach verschlüsseln ging jedenfalls nicht. Ohne on-the-fly Verschlüsselung out of the box vom ROM, die sauber und robust implementiert ist, wird das wohl eher ein Krampf. Store-Apps bergen immer die Gefahr von Datenverlust oder man vergisst doch ein Ablageort wo App-Backups mit Zugangsdaten schlummern. Das ist mir dann doch grad noch zu sehr in den Kinderschuhen und die kritischsten Daten sind bei mir per encfs bereits geschützt.

 

[Defier]

Also mit dem Luks Manager kann ich /data nicht auf einfache Weise verschlüsseln.
Ich müsste wohl ein Container erstellen dort alles aus /data reinlegen und den dann ggf. als /data mounten oder symlinken. Den bestehenden einfach verschlüsseln ging jedenfalls nicht.

Da gebe ich dir recht, die GUI (Luks Manager) ist wohl noch nicht ganz so weit und reizt auch nicht die Möglichkeiten des zugrundeliegenden LUKS aus. Was mich an dem Ding zudem stört ist, dass es nicht Open Source ist.

Ich fände es ja auch gut, wenn jemand diesen Support für 2.3.x weiterentwickeln würde. (Eigentlich bräuchte man ja nur eine gescheite GUI.) Aber ich bezweifle ob sich hier wirklich etwas tun wird, wenn Android 4 das ab Werk schon kann. Ob die Android4-native Möglichkeit besser als LUKS ist bezweifle ich jedoch, sie scheint wohl standardmässig auch die SD-Card nicht mitzuverschlüsseln?