libvncserver Sicherheitslücke erreicht 9.8/10 und wurde lange nicht gefixt

„WOW“ entfleuchte es mir vorhin kurz, deswegen kommt Ihr jetzt in den Genuß einer drei Jahre alten Sicherheitslücke kommt.

libvncserver Sicherheitslücke erreicht 9.8/10 und wurde lange nicht gefixt

Beim Durchsehen von Securityadvisories bei Red Hat Enterprise Linux stolperte ich über eine CVE Nummer aus 2017:

* libvncserver: websocket decoding buffer overflow (CVE-2017-18922)

For more details about the security issue(s), including the impact, a CVSS
score, acknowledgments, and other related information, refer to the CVE
page(s) listed in the References section.

Da nicht dabei stand, was da los war und wieso das erst jetzt gefixt wurde bei Red Hat, habe ich kurz recherchiert. Was dabei raus kam war diese Meldung von Red Hat:

Date: Tue, 30 Jun 2020 10:50:09 +0200
From: Stefan Cornelius <scorneli@...hat.com>
To: <eine Distri übergreifende ML>
Subject: libvncserver: old websocket decoding patch

Hi,

Upstream libvncserver fixed a websocket decoding issue >3years ago in
https://github.com/LibVNC/libvncserver/commit/aac95a9dcf4bbba87b76c72706c3221a842ca433

AFAICT, this never got a CVE and wasn't backported by some
distributions.

Thanks and kind regards,

[I sent a heads-up about this to distros last Friday, 'embargo' ran out
on Monday 20:00 UTC]
-- 
Stefan Cornelius / Red Hat Product Security

Da fixt also jemand eine drei Jahre alte Sicherheitslücke, weil die damals wohl keine CVE Nummer bekommen hatte, oder jemand diesen Umstand übersehen hat. (Könnte ja auch den besten mal passieren). Wäre das jetzt irgendeine schwer auszunutzende Lücke gewesen, hätte ich das achselzuckend abgehakt, aber das war es nicht.

In der NIST Datenbank findet sich nämlich das hier dazu:

It was discovered that websockets.c in LibVNCServer prior to 0.9.12 did not properly decode certain WebSocket frames. A malicious attacker could exploit this by sending specially crafted WebSocket frames to a server, causing a heap-based buffer overflow.

Severity

Base Score: 9.8 CRITICAL
Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.8 von 10.0 möglichen Punkten auf der Destruktionsskala, also eine leicht auszunutzende Lücke, die ohne Autorisierung am System funktioniert und eine Übernahme des Servers ermöglicht. Und DAS haben die übersehen… => WOW!
Als wenn das nicht schon genug wäre, kommt bei der Durchsicht der Updatemeldungen bei Fedora raus, das da gleich noch 3 andere jahrealte mit CVE Nummern versehen Sicherheitslücken gestopft wurden:
[ 1 ] Bug #1849877 – CVE-2019-20839 (Score 7.5) libvncserver: „ConnectClientToUnixSock()“ buffer overflow https://bugzilla.redhat.com/show_bug.cgi?id=1849877
[ 2 ] Bug #1849881 – CVE-2019-20840 (Score 7.5) libvncserver: unaligned accesses in hybiReadAndDecode can lead to a crash https://bugzilla.redhat.com/show_bug.cgi?id=1849881
[ 3 ] Bug #1849886 – CVE-2018-21247 (Score 7.5)  libvncserver: uninitialized memory contents are vulnerable to Information Leak https://bugzilla.redhat.com/show_bug.cgi?id=1849886
[ 4 ] Bug #1852356 – CVE-2017-18922 (Score 9.8) libvncserver: websocket decoding buffer overflow https://bugzilla.redhat.com/show_bug.cgi?id=1852356
Also das ist sicherheitstechnisch mal gründlich in die Hose gegangen. Jetzt denkt Ihr, betrifft mich nicht, ist ja Fedora und Red Hat.. leider Pech gehabt! betroffen sind auch:  OpenSUSE & Ubuntu. Man darf annehmen, daß Arch & Debian auch mit von der Partie sind. (kann ja mal kurz wer verifizieren, der die jeweiligen Updatesysteme kennt)

Quelle: https://nvd.nist.gov/vuln/detail/CVE-2017-18922
Quelle: https://www.openwall.com/lists/oss-security/2020/06/30/2

Boothole – Ja, und?

Ähm.. ich fühle mich geradezu .. ähm.. genötigt.. auch was zum Grubproblem zu schreiben:

Ja, und?

Als ich bei Heise das erstmal davon gelesen hatte, ging mir nur das Satzfragment „ja,und?“ durch den Kopf? Was bitte ist an einer Lücke mit der einen PC „übernehmen“ kann, für die man aber schon Root sein muß, besonders? Naja, nichts. Wenn ich schon durch einen Hack Root wurde, dann brauche ich diese Lücke nicht mehr, weil ich schon drin bin. Wenn man diese Lücke von außen per physischem Zugriff ausnutzen kann, dann brauche ich das auch nicht mehr, denn dann hatte ich schon den Zugriff auf den PC mit allem was drauf ist, denn die meisten haben keine Festplattenvollverschlüsselung. Ich kann als Angreifer also nicht nur den Bootbereich, sondern alles ändern, wenn ich das wollte.

Es bleibt also nur die eine Kombination übrig, für die das ein Problem ist: Systeme mit Verschlüsselung + physikalischem Zugriff  und hier auch nur die, wo /Boot unverschlüsselt ist.

Jetzt ist das mit dem physischem Zugriff so eine Sache, denn was bitte hindert mich daran, einen Bootloader auf die Platte zu bannen und dem Bios des Pcs zusagen, es soll Legacy booten, ergo der Secureboot ist nicht mehr im Spiel? Ein BIOS-Passwort vielleicht? Nicht wirklich, weil physischer Zugriff meint halt auf alles, ich könnte als Angreifer also auch mit genug Zeit, das Mainboard austauschen und so das Biospasswort umgehen, oder ich resette das einfach.

Antwort von Euch: „Dann schließ das Gehäuse halt ab.“ .. ja, das ist so.. ich war mal bei den deutschen Meisterschaften im Schlösserknacken dabei ( Zuseher ) und naja, so sicher wie man glaubt,  sind Schlösser gar nicht. Türschlösser z.b. sind in unter 3 Sekunden geöffnet. Es gibt sogar einen Sportverein der sich ganz der Schlossknackkunst verschrieben hat. Wenn uns das eins lehrt: Schlösser sind kein Hindernis für Profis und die (baulich)einfachen Schlösser von PC Gehäusen oder ausm Baumark schon gar nicht.

Merke.. wer physischen Zugriff auf Euren PC hatte, stellt IMMER ein unkalkulierbares Risiko da. Daher kann einen diese Lücke nicht wirklich schrecken. Spannender wird die Frage, wie M$ das nötige Secure-Bootupdate für die Sperre alter Grub Shims verteilen möchte, weil ohne das, ist der Fix oder nicht Fix komplett unwichtig 😀

Spammer und Scammer drehen immer mehr ab

Heute morgen hatte ich eine merkwürdige Email im Kasten. Gut, das kommt öfters vor, manche davon haben sogar einen legitimen Inhalt, aber diese hier ist derzeit Platz #2 der Hitliste. Platz #1 ist übrigens die leere Spammail, die an tausend Empfänger ging 🙂

Spammer und Scammer drehen immer mehr ab

Schauen wir uns erstmal die Header an:

From: Orabelle Cadwell <orabellekbdcad@hotmail.com>
Date: Mon, 6 Jul 2020 12:03:20 +0000
Subject:  2017-05-27 00:27:08  csq2qvXHzJr

Keine Ahnung ob da jemand einen Kontakt von vor 3 Jahren wiederbeleben wollte, oder ob er sich dachte, daß Zufallsdaten immer ein Datum sein müssen , aber völlig unsinnig wird erst der Inhalt:

https://fksC6I jO1.arpa ,) $>< https://1fCIjOs6k .arpa ,) $>< https://fk1Osj 6CI.arpa ,) $>< https://1Ojs6fkC I.arpa = 09 ,) $>< https://kIs1O6Cj f.arpa ,) $>< https://OIskC 16jf. arpa ,) $>< https://1OjCI ksf6.arpa ,) $>< https://kIC6f js 1O.arpa ,) $>< https://jIks fC16O.arpa ,) $>< https:/ /s 6OfIj1kC.arpa ,) $>< https://1 O6sjfkIC.arpa ,) $>< h ttps://k1sIOjC f6.arpa ,) $>< https://kO1jfI sC6.arpa ,) $>< https://kjIs1Of 6C.arpa ,) $>< https://sf1kCIj 6O.arpa , ) $>< https://OC sk1I6fj.arpa ,) $>< https://6I jO1sfCk.arpa ,) $>< https://s jIk1C6fO.arpa ,) $>< https://6fksIOj1 C .arpa ,) $>< https://1CkI6O jfs.arpa ,) $>< https://Okjf I1 6sC.arpa ,) $>< https://jfI 1sCk6O.arpa ,) $>< https: //6IjOCf s1k.arpa ,) $>< https://jskIOfC16 .arpa ,) $>< https://skjfO1IC6 .arpa ,) $>< https://ksCI61j fO.arpa ,) $>< https://Cs6Ifk j1O.arpa ,) $>< https://6fO IjCk1s.arpa ,) $>< https://jfC16IO ks.arpa ,) $>< https://CsO 1Ifj6k.arpa ,) $>< https://fCsj1I6O k.arpa ,) $>< https://C6O1sf jk I.arpa ,) $>< https://16C OIkfjs.arpa ,) $>< https://Ijf 6sOk1C .arpa ,) $>< https://s6OCf1jk I.arpa ,) $>< https ://Isjk1O6f C.arpa ,) $>< https://Ij 16COfks.arpa ,) $>< https://1 jsCfIkO6.arpa ,) $>< https://6j O1CIfks.arpa ,) $> < https://6CIkfs j1O.arpa ,) $>

Wenn man mal davon absieht, daß es die .arpa Domain zwar gibt, diese aber ausschließlich für PTR Records, also IP zu Domainnamen Umwandlung, benutzt wird und es somit keine wie auch immer generierten Domain im klassischen Sinne gibt, mußte man den Inhalt erst doppelt von „quoted-printable“ zu „lesbar“  umwandeln, was kein Mailprogramm der Welt macht. Schlußfolgerung: Der Block, der übrigens mehrere KB lang ist, dient nur der Verwirrung der Antispamprogramme.

Jetzt wirds richtig wirr, weil den Block oben gab  es als ASCII-Block, als HTML-Block und als .. tada.. PDF-Block 😀 Da wollte jemand auf Nummer sicher gehen 😉

Ok, ich denke, die Mission isterfüllt: Alle sind verwirrt – Der Verfasser, das Antispamprogramm und die 2.500 Empfänger 😀