Ansicht umschalten
Avatar von Alberto123
  • Alberto123

27 Beiträge seit 16.03.2005

Was für ein dünnes Papierchen

Mal ehrlich, das soll High-Level-Wissenschaft à la Fraunhofer sein? Mann-o-mann, ich glaube, es gibt einen Grund, warum die das Ding "Report" und nicht "Studie" nennen.

Kein Review erkennbar
Null. Nichts. Peer-Review? Fehlanzeige. Dann muss der Review wohl im heise-Forum erfolgen... ;)

Keine Methodenkritik erkennbar
Ist blankes CVEs zählen aussagekräftig für eine SIcherheitsbewertung? Vielleicht ja, vielleicht nein, sollte wohl in dem "Report" diskutiert werden, wenn man zentrale Aussagen darauf aufbaut. Verweise auf Literatur oder Forschungsergebnisse anderer, oder halt eigene Überlegungen. Fehlanzeige. Nichts dazu enthalten. Überhaupt keine Verweise zu anderen Forschungsergebnissen enthalten.

Ist bloßes vermuten Wissenschaft?
Sie schreiben, dass Hersteller sich vermutlich nicht die Mühe machen, Backports von Security Fixes für ihre Kernelstände zu erstellen. Und deswegen alle CVEs, die seit der in der Firmware verwendeten Kernelversion anfielen, ja enthalten sein müssten. Aha. Ich würde ja fast sagen: Die Forscher haben sich nicht die Mühe gemacht, nicht mal stichprobenhaft, diese Vermutung zu überprüfen. Z.B. in den GPL-Quellen der Hersteller mal nachgeschaut, wie es mit einzelnen für Router wichtigen Kernelpatches so aussieht. SACK-Panic z.B. (CVE-2019-11477, CVE-2019-11478, CVE-2019-11479).
Kernelconfig scheint auch nicht beachtet zu werden - oft sind CVEs ja in Treibern o.ä., sind die denn überhaupt in den jeweiligen Kerneln der Firmwares einkompiliert?

Keine Transparenz: das FACT-Tool wird wohl als Auftragsarbeit für irgendeinen Kunden entwickelt, legen jedenfalls github-Kommentare nahe. Wäre es nicht gute wissenschaftliche Sitte aufzuzeigen, ob Papiere und Tools mit Dritmitteln finanziert wurden und sollten die Geldgeber nicht auch genannt werden? Dann könnte man sich selbst ein Bild machen, wer so etwas vielleicht in Auftrag gibt.
Man findet unter https://github.com/fkie-cad/FACT_core/issues/165 jedenfalls sowas:

"Unfortunately, documentation is not a high priority for the guys, who pay for the development, at the moment."

Keine Rohdaten verfügbar, keine Nachvollziehbarkeit der Ergebnisse: zu den Boxplots mit den vielen CVEs, welche die zentrale Aussage "kein Router ohne kritische Lücken" belegen soll, finde ich keine Rohdaten. Ich kann also nicht nachschauen, welche CVEs sie überhaupt meinen und zählen. Sind das jetzt eher 50 Syzcaller-Funde im USB-Subsystem, von denen 49 bei den meisten Routern nicht in der Kernelconfig enthalten sind (DVB-C-USB-Treiber, USB-Soundkarten etc.), oder sind das 50 kritische Punkte im Linux-Netzwerkstack? Das würde ich gerne selbst mal sehen.

Neu ist da eigentlich auch nichts.

- Stumpf CVEs zählen und daraus einen SIcherheitsstatus ableiten? Die Idee hatten andere schon, hier aber mit Diskussion, welche Aussagekraft das haben könnte. Wow. Mehr Methodenkritik in c't-Artikeln als in Fraunhofer-FKIE-Arbeiten: https://www.heise.de/select/ct/2020/3/1580498856872446

- Hardening-Maßnahmen in Routern betrachten und bewerten? Gibt es ausführlicher hier: https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf
Sogar fast die gleichen Hersteller untersucht wie bei CITL.

- Nach private Keys in Firmware-Images scannen? Ihr ahnt es schon, die Idee gabs schonmal, z.B. hier: https://sec-consult.com/en/blog/2015/11/house-of-keys-industry-wide-https/

Wäre es nicht schön, ein paar Verweise auf diese Arbeiten einzubauen in seine wissenschaftliche Arbeit, vielleicht sogar zu erzählen, was in der eigenen Untersuchung jetzt anders oder neu ist? Da steht leider nichts im "Report".

Was noch? Peinliche Aussage zu Prozessorarchitekturen: "The CPU architecture has nothing to do with security. Nevertheless, we got the data for free and it might help some people who do not know which assembler language to learn."
Irgendwie finde ich die Seitenbemerkung im zweiten Satz unpassend in einer seriösen wissenschaftlichen Arbeit, das ist doch keine Bergündung, warum man den Leser jetzt damit langweilt. Aber es geht mir vor allem um den ersten Satz. Man scannt also nach MIPS und ARM und unterscheidet sogar zwischen Little Endian und Big Endian. Sicherlich aufregend für jemanden, der nicht so viel Erfahrung mit Embedded Systems hat. Endianess. Wow. Krass. Aber jetzt erzähl ich mal was noch krasseres: es gibt sogar ganz viele MIPS-Architekturen. Und ganz viele ARM-Kerne. Manche unterstützen das NX-Bit. Manche nicht. Ich hab mal gelesen, das NX-Bit habe was mit Security zu tun, wo war das noch gleich... achja, drei Abschnitte später im selben "Report" stehts ja. Wäre es nicht vielleicht auch mal interessant zu sehen, ob die Firmwares, die das NX-Bit unterstützen, möglicherweise genau die sind, die für Prozessorarchitekturen generiert wurden, die das ebenso unterstützen? Das wäre doch ne krasse Korrelation, die wissenschaftlich untersucht werden könnte. Wird aber nicht. Stattdessen begründet man die Untersuchung der CPU-Archichtektur damit, dass sie halt einfach erhebbar ist und schöne Kuchendiagramme gibt... wieder ne Seite vollgekriegt.

Irgendwie alles nicht das Niveau, das ich von einer echten wissenschaftlichen Arbeit, zumal von einem Fraunhofer-Institut, erwarten würde. Was war denn da los?

Bewerten
- +
Ansicht umschalten