Bitcoin Core maskiert Zeilenumbrüche gegen gefälschte Logzeilen per RPC
Victoria Shinder1 Min. LesezeitBitcoin Core hat am 30. September den Pull Request #35833 übernommen und damit eine Möglichkeit geschlossen, Einträge im Log des Knotens zu fälschen. Die Änderung des Mitwirkenden l0rinc betrifft vier Dateien: den Logging-Code, einen Unit-Test und zwei Funktionstests.
Das Problem laut Pull Request: Eingeschränkte RPC-Nutzer sowie Aufrufer von createwallet oder restorewallet konnten über den Namen einer abgelehnten RPC-Methode oder einen Wallet-Namen einen Zeilenumbruch ins Log bringen. Die allgemeine Log-Maskierung von Core ließ Zeilenumbrüche stehen, sodass alles nach dem Umbruch als eigener Eintrag mit eigenem Zeitstempel erschien – wie eine Meldung des Knotens selbst.
Der Pull Request enthält eine Nachstellung. Ein Knoten wird mit einer RPC-Whitelist gestartet, die nur getblock und stop erlaubt. Dann wird eine Methode aufgerufen, deren Name aus getblock, einem Zeilenumbruch und einer erfundenen Zeile besteht, die wie ein Fehler bei der Blockprüfung aussieht: ERROR: ConnectTip: ConnectBlock … failed, bad-txns-inputs-missingorspent. Vor dem Fix zeigte debug.log die erwartete Warnung, dass der Nutzer die Methode nicht aufrufen darf, und danach den gefälschten Fehler, als sei er wirklich passiert. Nach dem Fix bleibt dieselbe Eingabe in einer Zeile, der Zeilenumbruch erscheint als \x0a.
Der Fix ist eng gefasst: In Logmeldungen eingebettete Zeilenumbrüche werden maskiert. Die Funktionstests für die RPC-Whitelist und den Wallet-Start prüfen jetzt beide Eingabewege.
Warum das wichtig ist
Betreiber und Überwachungswerkzeuge lesen debug.log, um zu entscheiden, ob ein Knoten gesund ist. Ein gefälschter Konsensfehler kann jemanden einem Problem nachjagen lassen, das es nicht gibt, oder ein echtes verdecken. Der Angreifer brauchte zwar einen gewissen RPC-Zugang – aber eingeschränkte RPC-Nutzer sind genau die Konten, die Betreiber an weniger vertrauenswürdige Dienste vergeben.