Cross-posting von der Gluon Mailingliste. Original Text:
Hi everyone,
we have recently found a critial security vulnerability in Gluon, making a timely update of all nodes necessary.
The bugfix has not been pushed to the public Gluon repository yet to avoid disclosing information on this issue. A detailed advisory will be published at the same time as Gluon 2021.1.2, which will contain the fix.
The release is scheduled for the evening of Thursday, 2022-05-05. As all previous Gluon releases are affected, we will also provide bugfix backports for various older release branches that are still in use, regardless of end-of-life status.
ecdsa_verify_[prepare_]legacy() does not check whether the signature values r and s are non-zero. A signature consisting only of zeroes is always considered valid, making it trivial to forge signatures.
Requiring multiple signatures from different public keys does not mitigate the issue: ecdsa_verify_list_legacy() will accept an arbitrary number of such forged signatures.
Both the ecdsautil verify CLI command and the libecdsautil library are affected.
The exact same vulnerability was recently found in the Java Runtime Environment (CVE-2022-21449).
Patches
The issue has been fixed in ecdsautils 0.4.1.
All older versions of ecdsautils (including versions before the split into a library and a CLI utility) are vulnerable.
ecdsautils 0.4.1 is API- and ABI-compatible with version 0.4.0 (which is the same as version 0.3.2.20160630 found in the OpenWrt packages feed). The patch [add reference to fix commit here] should also apply to older versions of ecdsautuils with minor adjustments.
Die Release Notes, die oben verlinkt sind, geben dazu detaillierter Auskunft. Aber hier ganz kurz: Es geht um das Signieren von Firmware Updates. Aufgrund dieser Sicherheitslücke kann jedermann als gültig akzeptierte Firmware Manifeste erstellen. Damit kann man Gluon Knoten unter bestimmten Umständen ein beliebiges Firmware Update unterjubeln.
Der Angreifer muß dazu die Kontrolle über den hinterlegten Updateserver haben oder aber die Mittel, diesen im gegebenen Setup impersonieren zu können. Wobei letzteres sowohl auf L2- als auch L3-Ebene nicht trivial ist.
Kurzfassung: ja, ist Kacke, aber auch nicht direkte Götterdämmerung. Der Alarmismus ist aus Gluon-/Projektsicht verständlich – Level: major fuckup –, aus der Warte der Anwender oder Admins jedoch eher im Bereich »blaues Auge« einzuordnen.
Es ist ja so, dass sowieso nur communitys und branches betroffen sind bei denen man ein Firmware Update mit nur einer Signatur auslösen kann, da man nur eine durch Nullen ersetzen kann
Ja, das ist seltsam, in Kiel meine ich auch dass es zuerst geklappt hat beim Update von 2018.x auf 2020.2.x mit dreimal Nullen, aber in Freifunk Nord, wo wir zwei Signaturen brauchen, hat es dann nicht geklappt, erst als ich eine gültige Signatur hinzugefügt habe, und die zweite mit Nullen, ging das Update los. Ebenso bei @heini66 in Nordwest.
Vielleicht ist der Bug nicht in allen Firmware-Versionen gleich?
mit nordwest hab ich nix am hut. ich freifunke in der nordheide. ffnh. oder auch map.freifun-nordheide.de
aber: scarry ist das mit der manifestunterschrift. auf version n1 brauchten wir 1 gültige & 1 fake . auf version n2 klappten 2 fake unterschriften. n1 und n2 versionsinfo’s gibt esfür berknnte user per pm
Zumindest in einer 2021.1.1 hat die 0000er nur den Wert einer gültigen Signatur gehabt, wir brauchten dort noch weitere „echte“, nur halt eine weniger als sonst.