Today, we're publishing seven CVEs documenting several vulnerabilities in FatFs project, ranging from CVSS Medium to High (no Criticals, phew!). The affected ecosystem includes some major non-hobby platforms like Espressif ESP-IDF, STMicroelectronics STM32Cube middleware, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate, with downstream reach into consumer IoT, industrial controllers, drones, crypto wallets, and more.
Da wird eine Mücke zum Elefanten gemacht. Es kommt immer auf den Kontext an. Dass man solche Hobby-Bibliotheken nicht im Hoch-Sicherheits Umfeld nutzt, ist ja wohl klar.
Dass es trotzdem gemacht wird ist auch klar. Dafür kann der Autor dieser Bibliothek aber nichts. Der Absatz "XKCD "Dependency" strikes again" ist insofern zutreffend. Es ist halt eine Frage der Prioritäten.
1: schnell gemacht
2: billig gemacht
3: gut gemacht
Alles drei Zusammen ist unmöglich. Ich habe den Eindruck, dass die meisten Firmen schon zufrieden sind, wenn ihre Produkte funktionieren.
Immerhin können wir jetzt dank dieser Lücke theoretisch potentiell eventuell Teile der Firmware unserer Autoradios auslesen. Hoffentlich geht davon nicht die Welt unter.
Im übrigen kann man auch jeden PC zum Absturz bringen, wenn man Zugriff auf seine Speichermedien hat. Da gegen hilft nicht mal "Secure Boot". Überrascht das jemanden?
Immerhin können wir jetzt dank dieser Lücke theoretisch potentiell
eventuell Teile der Firmware unserer Autoradios auslesen. Hoffentlich
geht davon nicht die Welt unter.
Im übrigen kann man auch jeden PC zum Absturz bringen, wenn man Zugriff
auf seine Speichermedien hat. Da gegen hilft nicht mal "Secure Boot".
Überrascht das jemanden?
Nur könnte das (im Falle des Autoradios) simpel und einfach ein USB-Flash Stick mit Musik sein.
Schon vor drei bis vier Jahrzehnten wusste der gewiefte Amiga Programmierer, dass die Summe der /chunk/ Längen einer RIFF Datei nicht länger als die Gesamtlänge sein sollten.
Vielleicht kehren ja eines Tages solche zugegeben komplexen, gedanklichen Akrobatik-Meisterstücke wieder zurück.
Da wird eine Mücke zum Elefanten gemacht. Es kommt immer auf den
Kontext an.
Yep, da denke ich auch. Elms FS ist eine freundliche nette Geste fuer private Programmierer die hoffentlich auch freundlich aber weniger faehig oder faul sind. Wer sowas kommerziell einsetzt bekommt was er verdient. .-)
Ich meine waeren diese fremden Programmierer faehig und fleissig wuerden sie doch allermindestens mal den Source eines fremden gruendlich lesen und weil sie so faehig sind wuerden sie die Fehler sofort sehen und keine eigenen machen. Davon kann man gaaaaanz fest ausgehen. :-D
Und wer es echt soweit bringt ein System zu hacken indem er physischen Zugriff drauf hat, hey Bro du hast es verdient. Waer doch auch traurig wenn man es dann nicht schaffen wuerde.
Das letztemal als ich sowas als Profi gebraucht habe, da habe ich es mir selber geschrieben. Ist aber schon was her daher kenne ich den Markt nicht.
Noch ein Nachtrag: Ich wuerde denken wenn man heute ein System aufsetzt das nach aussen sichtbare Datentraeger wie SD oder USB verwendet, man doch sehr schnell auf dem Level ist wo man ein Linux implementieren wird. Oder irgendein anderes kommerzielles Betriebsystem.
Spezifisch das Zephyr und auch STM32Cube werden ziemlich offensiv für industrielle Nutzung beworben. Die Entwickler dieser Systeme haben FatFs aber anscheinend nie genauer angesehen oder Verbesserungen eingereicht...
Was passiert eigentlich wenn Microsoft auf die Idee kommt, konsequent Lizenzgebühren für die Nutzung von FAT einzusammeln?
Noch ein Nachtrag: Ich wuerde denken wenn man heute ein System aufsetzt
das nach aussen sichtbare Datentraeger wie SD oder USB verwendet, man
doch sehr schnell auf dem Level ist wo man ein Linux implementieren
wird. Oder irgendein anderes kommerzielles Betriebsystem.
Keineswegs. Der Vorteil von FAT ist ja gerade, dass es so einfach gestrickt ist, dass man es problemlos auch auf einer eher kleinen MCU benutzen kann, weil die Implementierung wenig RAM benötigt. Wenn man nur einen einfache Export von ein paar Logdaten oder das Einlesen von einem Firmwareupdate braucht, genügt so eine simple Implementierung vollauf.
Wenn man
nur einen einfache Export von ein paar Logdaten oder das Einlesen von
einem Firmwareupdate braucht, genügt so eine simple Implementierung
vollauf.
Da gebe ich dir natürlich vollkommen recht.
Trotzdem ist die Sicherheitsproblematik nicht zu unterschätzen. Auch und gerade in letztlich sicherheitskritischen Komponenten werden ja oft nur kleine MCUs verwendet, weil eben ihre Aufgabe eher eng umrissen ist. Ich meine damit z.B. solche Sachen wie die Endgeräte von Schließsystemen aller Art.
Wenn man nur einen einfache Export von ein paar Logdaten oder das
Einlesen von einem Firmwareupdate braucht, genügt so eine simple
Implementierung vollauf.
Wäre natürlich mies wenn das Einspielen von Sicherheits-Updates selbst anfällig gegen Angriffe ist...
Der Vorteil von FAT ist ja gerade, dass es so einfach gestrickt ist,
dass man es problemlos auch auf einer eher kleinen MCU benutzen kann,
weil die Implementierung wenig RAM benötigt.
Ich dachte es wäre längst LittleFS standard? Open Source, Wear Leveling, robust gegen Stromausfall und resourcenschonend.
Kann das ein Windows-PC lesen? Kann das ein Mac lesen?
Dateisysteme dienen in vielen Fällen dem Dateiaustausch, der durch wechselseitigen Anschluss eines Datenträgers an verschiedene Geräte erfolgt.
Wenn ein Dateisystem nur zur Bespaßung ein und desselben Geräts gedacht ist, dann kann man natürlich /irgendwas/ verwenden und muss sich um Kompatibilität keinerlei Gedanken machen.
Was passiert eigentlich wenn Microsoft auf die Idee kommt, konsequent
Lizenzgebühren für die Nutzung von FAT einzusammeln?
die FAT Patente sind seit langem abgelaufen. Am Schluss war nur noch das Long-File-Name Patent relevant. Das wurde 2007 vom Bundespatentgericht und 2013 vom Europäschen Patentamt für ungültig erklärt. Hauptsächlich weil die Idee schon veröffentlicht war, bevor das Patent angemeldet wurde.
Inzwischen sind die aber auch in den USA&Weltweit abgelaufen.
Hat schon einen Grund, warum exFat als neues Dateisystem hermusste.
Hat schon einen Grund, warum exFat als neues Dateisystem hermusste.
Es gibt aber auch reale technische Gründe - bei FAT32 ist die maximale Dateigröße auf 2^32 Byte (4 GByte) begrenzt, und man begegnet heutzutage doch immer häufiger Dateien, die größer sind.
Nur keine dafür, dass man Lizenzgebühren für etwas wie ein Dateisystem
verlangt.
Natürlich nicht. Aber früher wurde sogar der "Algorithmus" patentiert, mit dem PCs feststellten, ob die angeschlossenen Diskettenlaufwerke 40 oder 80 Spuren haben. Wo kämen wir denn da hin?
Ich vermeide es weitestgehend, mich mit dem ganzen Lizenz-, Patent- und sonstigem Gelddruckgehampel auseinanderzusetzen; es gibt da wohl eine Einrichtung namens "OIN", wer als Linux-Entwickler Mitglied davon ist, darf, so wie ich das der Wikipedia entnehme, exFAT verwenden.
Keine Lösung ist Microsofts Freigabe für andere Open-Source-
Betriebssysteme, etwa aus der BSD-Familie oder ReactOS. Der
Linux-Patentpool des Open Invention Networks ist nur dazu da,
Linux und seine Entwickler vor Klagen von Patentinhabern zu
schützen. Für andere Betriebssysteme gilt das nicht.
Zwar gibt es manche, die denken, neben Linux könne es gar keine anderen Betriebssysteme geben, aber ich weiß, woran Du eine ganze Zeit lang gearbeitet hast (oder es vielleicht sogar noch tust). Das fängt weder mit Lin an, noch hört es mit ux auf.
Andererseits ist das wohl nur 'ne Frage der Zeit; in den nächsten paar Jahren laufen diverse exFAT-Patente aus.
Ja, mach ich immer noch bissel was. exFAT läuft dort einfach als 3rd-party Software, als FuseFS, damit kann sich das jeder selbst installieren und man ist ob der fehlenden geschäftlichen Intention den Patent-Zirkus los.
