Kommentare zu folgendem Beitrag: Linux Kernel: Wollte Huawei absichtlich eine Hintertür einbauen?
Nachtrag vom 11.05.20 von grsecurity:
Wir wurden heute Morgen von Huawei PSIRT kontaktiert, der auf eine E-Mail des Patch-Autors an die KSPP-Liste verwies: https://www.openwall.com/lists/kernel-hardening/2020/05/10/3 und erklärte: „Das Patchset wird nicht von einem Huawei-Beamten, sondern von einer Einzelperson zur Verfügung gestellt. Und wird auch nicht in irgendwelchen Huawei-Geräten verwendet“. Sie fragten, ob wir die Beschreibung des Artikels aktualisieren würden, um diese Information zu korrigieren.
Auf der Grundlage öffentlich zugänglicher Informationen wissen wir, dass der Autor des Patches ein Mitarbeiter von Huawei ist, und trotz der Versuche, sich nach der Veröffentlichung dieses Posts nun vom Code zu distanzieren, behält er die Huawei-Benennung bei. Darüber hinaus ist der Mitarbeiter nach Informationen aus unseren Quellen ein Sicherheitspersonal der Stufe 20, dem höchsten technischen Niveau innerhalb von Huawei.
Dem in dem Artikel erwähnten Github-Repository wurde heute Morgen ein Commit hinzugefügt, der einen Hinweis am Anfang der README-Datei einfügte, der den Code von Huawei distanziert. Dieser Commit wurde (absichtlich oder unabsichtlich) auf Freitag zurückdatiert, als das Repository erstellt wurde, was den Eindruck erweckte, dass wir irgendwie absichtlich einschlägige Informationen, die leicht verfügbar waren, ignoriert haben. Das ist offensichtlich nicht wahr, und die Untersuchung des Inhalts von https://api.github.com/repos/cloudsec/hksp/events beweist, dass der Commit heute Morgen in das Repository verschoben wurde.
Wir haben auf die Mail von Huawei PSIRT geantwortet und erwähnt, dass es für uns in Ordnung wäre zu erwähnen, dass die Patches nicht auf irgendwelchen Huawei-Geräten ausgeliefert werden (ich hielt es angesichts der schlechten Code-Qualität bereits für unwahrscheinlich), aber bezüglich der anderen Behauptung (insbesondere wegen der heimlichen Bearbeitung des Repo von Github) müssten wir auch die zusätzlichen Informationen, die wir entdeckt haben, mit einbeziehen.
Huawei hat mit der Veröffentlichung von HKSP anscheinend einen Fuß in das Spiel des Kernel-Selbstschutzes gesetzt. Der Patch selbst ist von Fehlern und Schwächen durchsetzt und weist im Allgemeinen keinerlei Bedrohungsmodell auf (und ähnelt damit denjenigen in LKRG, wo das Wissen über die vorhandenen Abhilfemaßnahmen ausreicht, um sie zu umgehen). Es ist nicht klar, ob es sich bei dem geposteten Patchset um eine offizielle Huawei-Version handelt oder ob dieser Code bereits auf irgendwelchen Huawei-Geräten ausgeliefert wird, aber das Patchset verwendet Huawei in seinem Namen, und der Github-Account für das Patchset führt Huawei als die Organisation für den Account auf.
In diesem kurzen Blog-Beitrag konzentrieren wir uns heute darauf, wie das HKSP-Patchset eine trivial ausnutzbare Schwachstelle aufgrund eines völligen Fehlens einer defensiven Programmierung einführte.
Im Patch wird ein /proc/ksguard/state Eintrag erstellt. Jedes Mal, wenn dieser Eintrag geöffnet oder geschlossen wird, werden die folgenden Zeilen, die auf einen nicht existierenden Dateinamen verweisen, an dmesg ausgegeben, um einen Hinweis auf den Grad der Überprüfung des Codes zu geben…
Es gibt eine Reihe von Problemen mit dieser Funktion. Zunächst gibt es die Rückgabe -1, die ein ordentliches errno zurückgeben sollte (im Allgemeinen -EFAULT). Es gibt eine Variable n, die zugewiesen, aber für nichts verwendet wird. Es gibt überhaupt keine Überprüfung des Wertes von len. Das erste Problem, das dies verursacht, ist das Auftreten als begrenztes Orakel. Indem 0 Bytes in den Eintrag geschrieben werden, versucht das uninitialisierte tmp-Array, eine Zahl daraus zu parsen und dann darauf zu reagieren. Gleichermaßen führt das Schreiben von vollen 32 Bytes in den Eintrag und das Scheitern des NUL-Abschlusses der Zeichenfolge dazu, dass simple_strtoul außerhalb der Grenzen zugreift und möglicherweise als partielles Orakel für den angrenzenden Speicher fungiert. Am wichtigsten ist jedoch, dass aufgrund des Fehlens von Prüfungen auf len und angesichts der Tatsache, dass tmp ein einfaches 32-Byte-Stack-Array ist, ein trivial ausnutzbarer Kernel-Stack-Pufferüberlauf eingeführt wird, der von jedem unprivilegierten Benutzer durchgeführt werden kann.
Effektive Sicherheitsabwehr erfordert definierte, realistische Bedrohungsmodelle. Abwehrmaßnahmen im Kernel sollten defensiv und mit Blick auf die Verringerung des Wartungsaufwands programmiert werden. Der Kernel kann effektiv als das größte und anfälligste Setuid-Root-Binary auf dem System betrachtet werden. Neuer Code, der zu dieser am meisten privilegierten Komponente des Systems hinzugefügt wird, stellt eine potenzielle neue Angriffsfläche dar und muss genauestens untersucht werden, damit nicht noch schlimmere Probleme eingeführt werden, als ursprünglich versucht wurde, sie zu lösen.
1 „Gefällt mir“