macOS 10.13 - APFS Passwörter werden unverschlüsselt abgelegt

[Jan Gruber]

macOS 10.13 - APFS Passwörter werden unverschlüsselt abgelegt

Anscheinend dauern die Wochen in Cupertino deutlich länger als die normaler Kalender. Die "schlechte Woche" bei Apple geht weiter. Nach dem Fehler mit Siri gibt es jetzt auch einen Fehler bei macOS 10.13. Das System legt die Passwörter von verschlüsselten APFS Partitionen unverschlüsselt in einer Log-Datei ab.

Die Forensikerin Sarah Edwards bemerkte den Fehler und wies entsprechend auf ihn hin. Der Fehler tritt aktuell bei macOS 10.13 und 10.13.1 auf, im aktuellen Release und der aktuellen Beta scheint er behoben zu sein. Apple führte den Fehler allerdings nicht offiziell als gelöst an. Das könnte zwei Gründe haben. Einerseits, dass gezielt auf eine Kommunikation verzichtet wurde, andererseits, dass der Fehler eigentlich gar nicht offiziell angegangen wurde. Insofern bleibt abzuwarten, ob der Bug vielleicht nicht doch wieder auftritt.
Festplattendienstprogramm - unverschlüsselt und Standardpasswörter


Es ist nicht der erste Fehler im Zusammenhang mit dem Festplattendienstprogramm. Bereits letztes Jahr wurde ein Fehler im Umgang mit Passwörtern bekannt.

 

[meru]

Das ist doch ein Scherz?
So oft kann unmöglich bei einer Firma wie Apple bei der Sicherheit gepasst werden, das muss doch Sabotage sein.

mfg Meru

 

[MichaNbg]

Ja. Unfassbar hohe Softwarequalität und total sicher. Da schreibt man Datenschutz und Datensicherheit noch riiichtig groß.

 

[Jan Gruber]

Das ist doch ein Scherz?
So oft kann unmöglich bei einer Firma wie Apple bei der Sicherheit gepasst werden, das muss doch Sabotage sein.

mfg Meru

Ich konnt mirs ja im Artikel schon nicht verkneifen - schlechte Woche - seeeeeehr schlechte, seeeeehr lange Woche =)

 

[ottomane]

Wieder ein Fehler, der deutliche Zweifel an der Professionalität der Entwicklungsprozesse aufwirft.

Mir reicht das allmählich. Aber wo will man schon hin bei diesen Alternativen?

 

[echo.park]

Was erlauben Apple!?

 

[fnL]

Aber wo will man schon hin bei diesen Alternativen?

Sehe das absolut genauso. Es gibt mMn schlicht keine vernünftige Alternative.
Auf der Arbeit benutze ich ein Lenovo ThinkPad und hatte auch schon das Dell XPS vom Arbeitskollegen in den Fingern. Ist zwar für ein Windows Notebook echt gut, und ich hatte da schon einige von in den Händen, aber trotzdem bin ich immer wieder froh mit meinem rMBP Late '13 zu arbeiten. :rolleyes:

 

[MacMark]

Der Fehler tritt nur bei externen Volumes auf. Auch nicht toll, aber lange nicht so dramatisch.

 

[MichaNbg]

Der Fehler tritt nur bei externen Volumes auf. Auch nicht toll, aber lange nicht so dramatisch.

Das kann man so oder so sehen. Einen externen Datenträger trägt man einfacher mal weg, als einen ganzen iMac.

 

[MacMark]

Das kann man so oder so sehen. Einen externen Datenträger trägt man einfacher mal weg, als einen ganzen iMac.

Das Paßwort taucht im neuen "unified" Logging-System von macOS auf. Die Logs liegen mit ziemlicher Sicherheit auf der Systemplatte und nicht auf einem externen Volume.

Update: Die Unified Logs liegen in

• /var/db/diagnostics/
• /var/db/uuidtext/

https://www.mac4n6.com/blog/2016/11...orensic-artifacts-introducing-unified-logging
(Dieselbe Website hat auch den Bug veröffentlicht)

Und wenn die interne Platte mit FileVault verschlüsselt ist, dann sind darauf dummerweise gelandete Paßworte für externe Volumes nicht mehr ganz so bedrohlich. Nicht cool, aber nicht das Problem, als das es dargestellt wird.

 

[echo.park]

Aber wo will man schon hin bei diesen Alternativen?

Die Sachen, die Microsoft zuletzt so veröffentlich hat, die Surface-Geräte, sind gar nicht mal schlecht. Wirklich gut sogar.

Aber dann stolpere ich wieder über sowas hier und alles ist passé:
https://www.heise.de/newsticker/mel...tragung-in-Windows-10-abschalten-4003291.html

 

[MichaNbg]

Das Paßwort taucht im neuen "unified" Logging-System von macOS auf. Die Logs liegen mit ziemlicher Sicherheit auf der Systemplatte und nicht auf einem externen Volume.

Update: Die Unified Logs liegen in

• /var/db/diagnostics/
• /var/db/uuidtext/

https://www.mac4n6.com/blog/2016/11...orensic-artifacts-introducing-unified-logging
(Dieselbe Website hat auch den Bug veröffentlicht)

Und wenn die interne Platte mit FileVault verschlüsselt ist, dann sind darauf dummerweise gelandete Paßworte für externe Volumes nicht mehr ganz so bedrohlich. Nicht cool, aber nicht das Problem, als das es dargestellt wird.

Es ist noch weniger cool immer jeden Fehler zu relativieren. Wie kommt man eigentlich auf die Idee, Passwörter in Logs zu schreiben? Und dann auch noch unverschlüsselt?!

 

[MacMark]

Es ist noch weniger cool immer jeden Fehler zu relativieren. Wie kommt man eigentlich auf die Idee, Passwörter in Logs zu schreiben? Und dann auch noch unverschlüsselt?!

Die Wahrheit ist nie relativ. Es gibt nur wahr oder falsch. In der Regel lassen sich Falschmeldungen jedoch besser verkaufen in News.

Wenn man eine neue Software entwickelt, hier ein neues Logging System, schreibt man erstmal alles in Logs. um das Verhalten zu prüfen und Fehler zu finden. Am Schluß nimmt man sensible Daten wieder raus. Daß keine Paßworte und dergleichen in Logs auftauchen sollen, steht in Apples eigenen Entwickler-Richtilinien:

Important: Don’t log confidential data, such as passwords, which could then be read later by a malicious user.
Audit Logs​

Aber Fehler passieren.

 

[Fresh_Prince]

Auch wenn Fehler passieren, sollten solche Fehler in einem solchen Bezug nicht passieren. Aber irgendwie kommt mir das bekannt vor. Kann das vielleicht einen Zusammenhang damit hier haben?
Ich wusste das mir diese Meldung bekannt vorkam, auch wenn sie etwas „Anderes“ beschreibt.

Von Anfang Oktober und ein Sicherheitsupdate gab es dann ja auch. Bei der neuen Meldung war es mit 10.13.2 ja nun auch nicht mehr reproduzierbar. Mhm

https://www.apfeltalk.de/community/...uesseltem-volume-im-klartext-sichtbar.520604/

 

[MichaNbg]

Selbstverständlich passieren Fehler. Für die Fallhöhe sorgen aber Apple und die Fanbase selbst. Die einen spielen sich immer perfekt auf und die anderen überschütten die Konkurrenz mit Häme.

Kannst dir die Kommentare ja vorstellen, wenn das unter Windows passiert wären


Davon abgesehen. Dass es so etwas die QS schafft... puh.

 

[MacMark]

… Kann das vielleicht einen Zusammenhang damit hier haben?…
https://www.apfeltalk.de/community/...uesseltem-volume-im-klartext-sichtbar.520604/

Das aktuelle ist ein Fehler im Unified Logging, das andere war ein Fehler im Disk Utility.

 

[Fresh_Prince]

Ok. Mir kam es nur bekannt vor wegen den Versionen. Der Fehler im Disk Utility bestand ja auch mit 10.13.0 und 10.13.1. ich hoffe wirklich das Apple es mit der kommenden Version von macOS und iOS hinbekommt wie sie es sich vorstellen. So wie sie es sich eigentlich schon auf der WWDC im Sommer 2017 vorgestellt haben und es auch so kommunizierten.

 

[doc_holleday]

Es ist noch weniger cool immer jeden Fehler zu relativieren.

(Wertfreier!) Kommentar:
Einen Fehler herunterzuspielen ist eine Sache, einen Sachverhalt richtig/klar zu stellen, eine andere.

Unabhängig davon: das ist mal wieder eine richtig peinliche Nummer. V.a. für eine macOS-Reihe, die nur Fehlerbehebungen und Leistungsverbesserungen bekommen sollte.

 

[Wuchtbrumme]

Das aktuelle ist ein Fehler im Unified Logging, das andere war ein Fehler im Disk Utility.

das streite ich ab. Ein Logging-Subsystem darf niemals schon auch nur die Credentials in Cleartext erhalten. Meiner Ansicht nach liegt der Fehler eindeutig am FPDP.

 

[MacMark]

Da ist was dran. Das Logging-System kann ja nicht wissen, was von dem Text ein Paßwort ist. Beim FPDP liegt der Fehler jedoch auch nicht, denn das muß das Verschlüsselungs-Paßwort zwangsläufig an den -S Parameter von /sbin/newfs_apfs übergeben, damit die Platte von newfs_apfs verschlüsselt werden kann. Die Logausgabe kommt ebenfalls vom /sbin/newfs_apfs Utitlity.