Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Donnerstag, 28 März 2019 | Blog: 2 | No: 42820
Es gibt einen aktuellen Report zu Huawei. Ab 3.11 wird es relevant. Ich fasse mal zusammen: Sie finden immer wieder Probleme, und das Volumen reißt nicht ab.
Ab 3.19 geht es dann darum, dass Huawei keine reproduzierbaren Builds hat. Das ist bedauerlich, aber leider Industriestandard. Das ändert sich gerade jetzt erst langsam ein bisschen zum besseren, getrieben vor allem (ironischerweise, finde ich) von so Web-Multimedia-Startup-Klitschen und so Agile-Hipstern mit CI-Pipeline und so, wo das dann zufällig an der Seite mit rausfällt.
Die nächsten Kritikpunkte sind Configuration Management und Third Party Libraries und ihre Versionen, was meiner Erfahrung nach auch alle anderen Playern in der Softwareindustrie große Schwierigkeiten macht.
Bei Punkt 3.31 geht es dann aber ums Eingemachte, und die Kritikpunkte klingen ziemlich deutlich nach "Legacy-Codebasis aus den 90ern, nie aufgeräumt". Was mich ein bisschen irritiert: Das ist kein Hexenwerk, da einmal gezielt drüber zu gehen. Als erstes macht man alle Längen, Indizes, Größen und Offsets size_t, dann schaltet man im Compiler die Signedness-Warnungen an und räumt die alle weg. Dabei werden diverse Stellen kaputtgehen. Wahrscheinlich liegen für die keine Unit Tests vor, die muss man dann halt an der Stelle neu schreiben — und zwar vorher, bevor man den Code ändert. Dann ändert man den Code und guckt, ob die Unit Tests noch bestanden werden. Und wenn man damit fertig ist, geht man alle *printf-Aufrufe durch und guckt nach sprintf mit %s und Format String Vulnerabilities, die so alter Code bestimmt auch einige haben wird.
Nichts davon ist schwarze Magie. Es ist bekannt, wo es hingehen muss, es ist bekannt, in welcher Reihenfolge man welche Schritte durchführen muss, und keiner der Schritte benötigt Kreativität. Das ist eine Menge Aufwand, klar, aber den muss man dann halt machen. Huawei hat ja schon einen Haufen Geld dafür reserviert.
Wenn ich Konkurrent von Huawei wäre, würde ich mir jetzt echt Sorgen machen, dass die einen "Bill Gates Memo"-Stunt pullen, alle Arbeit einstellen und nur Cleanup machen, und dann kann die Konkurrenz mal einpacken, so beschissen wie die Standards bei denen sind.
Was mich noch irritiert: Als Auditor freust du dich über so eine Codebasis! Da musst du nur mal kurz grep anwerfen und schon purzeln dir die Bugs entgegen! Lauter memcpy und sprintf im Code? Da hol ich doch den Schampus raus! In der Zeit, die für das Schreiben dieses Reports draufgegangen ist, hätten sie Dutzende bis Hunderte von Bugs finden müssen, einfach indem sie die einmal alle durchgehen. Dass das da nicht steht, lässt mich vermuten, dass dieser Report eher nicht von Security-Leuten geschrieben wurde, sondern von so Compliance-Halbleichen, die turnusmäßig Berichte über memcpy schreiben, damit niemand voreilig den Bestatter ruft. Sich in so einem Kontext (Pre-Auth Remote Stack Smash) über nicht-reproduzierbare Builds aufzuregen, das ist wie wenn der TÜV dir in den Bericht schreibt, dass dein Lack auf dem Dach etwas auszubleichen beginnt, während das Vorderrad sich gelöst hat und wegrollt. Mag sein, aber ist an der Stelle ganz sicher kein relevantes Problem.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Donnerstag, 28 März 2019 | Blog: 2 | No: 42820
Da musst du nur mal kurz grep anwerfen und schon purzeln dir die Bugs entgegen! Lauter memcpy und sprintf im Code?
Es gibt einen aktuellen Report zu Huawei
Some serious vulnerabilities reported in previous evaluations continue to persist in newer versions.DAS ist ein Riesenproblem. Nicht nur bei Huawei. Aber das ist eine Sache, die man wirklich kritisieren kann und sollte. Wie eine Firma auf Bugs reagiert, zeigt ihren Charakter viel deutlicher als ob Bugs gefunden werden.The character of vulnerabilities has not changed significantly between years, with many vulnerabilities being of high impact (equivalently, a high base CVSS score and a relevant operational context), including unprotected stack overflows in publicly accessible protocolsDas ist wirklich übel. Ich wünschte, es wäre nur bei Huawei so krass, ist es aber leider nicht. Das heißt, dass sie ihre Angriffsoberflächen nicht mit Priorität sauberauditiert und gefuzzt haben. Das ist eine Fehlerklasse, die heutzutage wirklich niemand mehr haben sollte. Dass die anderen Marktteilnehmer alle ähnlich grottig sind, ist an dieser Stelle keine Entschuldigung.Ab 3.19 geht es dann darum, dass Huawei keine reproduzierbaren Builds hat. Das ist bedauerlich, aber leider Industriestandard. Das ändert sich gerade jetzt erst langsam ein bisschen zum besseren, getrieben vor allem (ironischerweise, finde ich) von so Web-Multimedia-Startup-Klitschen und so Agile-Hipstern mit CI-Pipeline und so, wo das dann zufällig an der Seite mit rausfällt.
Die nächsten Kritikpunkte sind Configuration Management und Third Party Libraries und ihre Versionen, was meiner Erfahrung nach auch alle anderen Playern in der Softwareindustrie große Schwierigkeiten macht.
Bei Punkt 3.31 geht es dann aber ums Eingemachte, und die Kritikpunkte klingen ziemlich deutlich nach "Legacy-Codebasis aus den 90ern, nie aufgeräumt". Was mich ein bisschen irritiert: Das ist kein Hexenwerk, da einmal gezielt drüber zu gehen. Als erstes macht man alle Längen, Indizes, Größen und Offsets size_t, dann schaltet man im Compiler die Signedness-Warnungen an und räumt die alle weg. Dabei werden diverse Stellen kaputtgehen. Wahrscheinlich liegen für die keine Unit Tests vor, die muss man dann halt an der Stelle neu schreiben — und zwar vorher, bevor man den Code ändert. Dann ändert man den Code und guckt, ob die Unit Tests noch bestanden werden. Und wenn man damit fertig ist, geht man alle *printf-Aufrufe durch und guckt nach sprintf mit %s und Format String Vulnerabilities, die so alter Code bestimmt auch einige haben wird.
Nichts davon ist schwarze Magie. Es ist bekannt, wo es hingehen muss, es ist bekannt, in welcher Reihenfolge man welche Schritte durchführen muss, und keiner der Schritte benötigt Kreativität. Das ist eine Menge Aufwand, klar, aber den muss man dann halt machen. Huawei hat ja schon einen Haufen Geld dafür reserviert.
Wenn ich Konkurrent von Huawei wäre, würde ich mir jetzt echt Sorgen machen, dass die einen "Bill Gates Memo"-Stunt pullen, alle Arbeit einstellen und nur Cleanup machen, und dann kann die Konkurrenz mal einpacken, so beschissen wie die Standards bei denen sind.
Was mich noch irritiert: Als Auditor freust du dich über so eine Codebasis! Da musst du nur mal kurz grep anwerfen und schon purzeln dir die Bugs entgegen! Lauter memcpy und sprintf im Code? Da hol ich doch den Schampus raus! In der Zeit, die für das Schreiben dieses Reports draufgegangen ist, hätten sie Dutzende bis Hunderte von Bugs finden müssen, einfach indem sie die einmal alle durchgehen. Dass das da nicht steht, lässt mich vermuten, dass dieser Report eher nicht von Security-Leuten geschrieben wurde, sondern von so Compliance-Halbleichen, die turnusmäßig Berichte über memcpy schreiben, damit niemand voreilig den Bestatter ruft. Sich in so einem Kontext (Pre-Auth Remote Stack Smash) über nicht-reproduzierbare Builds aufzuregen, das ist wie wenn der TÜV dir in den Bericht schreibt, dass dein Lack auf dem Dach etwas auszubleichen beginnt, während das Vorderrad sich gelöst hat und wegrollt. Mag sein, aber ist an der Stelle ganz sicher kein relevantes Problem.
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
