Hallo zusammen, an dieser Stelle eine Vorabinfo, da einige von uns betroffen sein könnten: Es existiert eine Schwachstelle im Firmwareschutz der STM32F1 Serie. Details werden am 15.03.2020 im Rahmen eines Coordinated Disclosure Prozesses veröffentlicht. Die Schwachstelle ist unter CVE-2020-8004 erfasst. Quelle + weitere Details: https://blog.zapb.de/stm32f1-announcement/ Viele Grüße Johannes
Gast
#6128368
Ist es moralisch ok die Details solcher Schwachstellen zu veröffentlichen? Software kann man updaten, aber bei µCs die schon hergestellt sind ist nichts zu machen.
Gast
#6128374
Die Info ist für die "Entwicklung" Chinesischer Produkte gedacht.
Also schonwieder! Beim F0 hats ja auch schonmal geklappt mit 3 Möglichkeiten: https://www.aisec.fraunhofer.de/en/FirmwareProtection.html Per SWD gings da auch schon, also mal gucken obs beim F1 ähnlich ist.
Mw E. schrieb: > Beim F0 hats ja auch schonmal geklappt mit 3 Möglichkeiten: > https://www.aisec.fraunhofer.de/en/FirmwareProtection.html Auch da war ein gewisser Johannes Obermaier unter den Autoren. Ich vermute mal stark, dass das der TO ist ;)
Wenn das O für diesen Nachnamen steht, dann ja. Da bin ich mal gespannt.
Mw E. schrieb: > Wenn das O für diesen Nachnamen steht, dann ja. Wie es der Zufall will, steht er im selbst verlinkten Artikel, also > https://blog.zapb.de/stm32f1-announcement/ ebenfalls unter den Ansprechpartnern ;)
Moralapostel schrieb: > Ist es moralisch ok die Details solcher Schwachstellen zu > veröffentlichen? Eine Problem verschwindet nicht dadurch daß man aufhört darüber zu sprechen. Genauso wenig wie Du unsichtbar wirst wenn Du Dir die Augen zuhältst.
Neuigkeiten?
Gast
#6182859
Jetzt sind Details abrufbar
Und zwar hier: https://blog.zapb.de/stm32f1-exceptional-failure/
Wie sehen denn die knapp 90% ausgelesener Speicher aus? So wie ich das sehe, hat man immer wieder ein paar Befehle echt, dann wieder nichts, dann wieder echt/nix/echt/nix usw. usf. Die letzten fehlenden Bytes muss man dann probieren? ;)
Also wenn da der Vektorfetch genutzt wird um Flashinhalt in den PC zu laden, weil der M3 das über den I-Bus macht. Ja dann wären STM32F2 aber auch betroffen? Die haben auch einen M3 Kern.
Gast
#6184356
> Wie sehen denn die knapp 90% ausgelesener Speicher aus?
Siehst du doch in dem Video. Einzele Wörter können nicht extrahiert
werden. Im Video sind diese durch "aaaaaaaa" kenntlich gemacht.
9uf1
Gast
#6185315
Kann man mit der gewonnenen Information nicht "einfach" sequentiell alle Flash-Adressen in das entsprechende Register des entsprechenden Befehls laden, und den Flash-Inhalt anschließend aus dem entsprechenden Ziel-Register lesen?
Gast
#6187734
Im Artikel steht "We discuss a novelly discovered vulnerability whose exploitation would be the first non-invasive way to circumvent the feature." Würde man Fault-Injection über die Betriebsspannung auch als invasiv betrachten? Dafür braucht man das Gehäuse des uC ja auch nicht öffnen, nur die Spannungsversorgung modifizieren. Im Paper "Shaping the Glitch: Optimizing Voltage Fault Injection Attacks" wird nämlich eine solche Attacke beschrieben, die ich gerade kürzlich erfolgreich (und vereinfacht: Nur FET statt Signalgeneator) an einem STM32F103ZE nachstellen konnte. Ich konnte damit den gesamten Flash auslesen und die Firmware auf einen neuen Chip flashen, um damit das Gerät (zumindest größtenteils) zu reparieren... Stefan
Gast
#6241784
Info schrieb: > Kann man mit der gewonnenen Information nicht "einfach" sequentiell alle > Flash-Adressen in das entsprechende Register des entsprechenden Befehls > laden, und den Flash-Inhalt anschließend aus dem entsprechenden > Ziel-Register lesen? Scheint zu klappen: https://www.optiv.com/blog/automated-unlocking-nrf51-series-socs-nrfsec
Gast
#6249701
Nein, dieser Anriff geht auf dem STM32F1 nicht.