Linux: Runes of Magic zurück

Ich sage ja immer mal wieder, daß man nie genau hinsehen sollte, weil man sonst noch was findet, so auch heute. Allerdings gibt es da einen feinen Unterschied, denn das jetzt gefundene ist positiv 🙂

Linux: Runes of Magic zurück

Ja, liebe Leser, Runes of Magic, das letztes Jahr kläglich die Linux-Gamer durch ein Update (ungewollt vermutlich) ausgesperrt hat, ist zurück auf Linux. Quasi beim Aufräumen bin ich über das Runes of Magic Icon gestolpert, das im Angesicht von mehreren Wine Update immer noch auf meinem Desktop der erneuten Verwendung harrte, also habe ich dann mal drauf gedrückt 😉

Der Client startete zwar, aber es war immer noch der alte. Allerdings fehlte das sonst übliche Errorwindow (Runes of Magic – Der schwarze Fix ) und das gab mir einen Grund, mal den GameForge-Clienten zu starten. Der wollte dann im zweiten Anlauf ein Update einspielen. Ewig und drei Tage später war das dann auch endlich durch und ein Klick auf „Spielen“ startete tatsächlich das Spiel und … es lief:

Runes of Mgaic mit 3 Clienten auf zwei Monitoren.Na dann, auf zum Gipfel! (Das merkt Ihr dann schon, wenn Ihr einloggt.)

Blog Statistiken

Heute morgen habe ich mal etwas meine WordPress App auf dem Handy geärgert und das ist dabei herausgekommen: Eine Animation der Zugriffszahlen des Blogs, gezählt durch WordPress.

Blog Statistiken

WordPress zählt das alles etwas anders als die Traffic Stats auf der Seite selbst, daher ist hier ein quantitativer Vergleich nicht möglich. Was man aber schön sehen kann, daß früher mehr Abfragen aus den USA kamen, heute dagegen mehr aus Portugal und wie sich die Zahlen im Laufe der Jahre ändern.

Eine Animation der Jahre 2013-2020Da sieht man mal das „gesteigerte“ Interesse der Leute an Linux 😉

Die Zahlen von 2020 sind natürlich kleiner als die von 2019, weil 2020 noch nicht rum ist 😉

Aber natürlich will ich wissen, was für ein Docx da auf mich wartet!

Aber natürlich will ich wissen, was für ein Docx da auf mich wartet!

Klaro, und ich bin natürlich blöd genug auf den Link zu klicken, damit der Verbrecher weiß, daß die Adresse gelesen wird 🙂

Wem sowas hier ins Haus flattert …

 Microsoft Docx Portal Notifier for info@{eineunsererdomains.de} Mail. 
 
   
RECEIVED: 3/3 pages scanned file awaits your review on info@{eineunsererdomains.de} Microsoft Docx

<a href=“http://uxxxxxxxxx.ct.sendgrid.net/ls/click?upn=MÜLLENTFERNT!“> REVIEW NOW: </a>

by {eineunsererdomains.de} Microsoft Document Portal

direkt in die digitale Mülltonne damit! Wer nur den Absender sieht, so sieht sowas aus.
From: "{eineunsererdomains.de} Microsoft Docu Portal" <ainal@satextilesourcing.com>
To: info@{eineunsererdomains.de}
Subject: 3/3 Pages New Document.

Leicht zu erkennen, daß das nicht von M$ ist und da „wir“ gar nicht mit Windows arbeiten, werden „wir“ natürlich auch nicht das „Online“ Docu Portal von M$ benutzen, oder Ihr etwa??? 😉

Windows Netzwerke topologisieren – Linuxstyle

Wenn wir in einem Firmennetz den PCs per DHCP IPs zuweisen, dann kennt nur der DHCP Server die aktuelle Zuordnung aller von Ihm verwalteten Addresseranges und die kann sich dynamisch ändern. Also brauchen wir eine Methode wie wir eine aktuelle Übersicht bekommen.

Windows Netzwerke topologisieren – Linuxstyle

Oh ja.. endlich mal was ohne Corona schreiben, wie ich das vermisst habe 😀

Wir brauchen:

Einen Linux PC
NMAP Scanner
GREP, SED, AWK
nmblookup

nmblookup bekommt man für Fedora im Paket „samba-client“ und nmap natürlich im Paket „nmap„, wer hätte es gedacht 😉

Wir nehmen jetzt mal an, daß wir nur ein Netz haben: 192.168.1.0/24 und, daß Windows RDP offen hat, damit man da auch Remote drauf kann. RDP hat den Port 3389. Das hat den Vorteil, daß wir nur die PCs mit Port 3389 finden müssen:

nmap -n -sS -p 3389 192.168.1.0/24

das sieht dann so aus:

Nmap scan report for 192.168.1.24
Host is up (0.00040s latency).
PORT STATE SERVICE
3389/tcp open ms-wbt-server
MAC Address: A2:54:20:26:3D:7F (Unkown)

Aus der Ausgabe brauchen wir nur die mit offenen RDP Ports, also filtern wir nach „open“, es sei denn, Ihr habt eine Installation bei der das eingedeutscht wurde. Da müßt Ihr selbst ran 😉

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open

Jetzt habe ich dem ersten grep nach „open“ gesagt, es soll auch die 3 Zeilen vor dem Treffer ausgeben. Dies ist wichtig, weil da die IP drin steht. Als nächstes  filter wir auf die IP Zeile:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“

und werfen alles außer der IP weg:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“ | sed -e „s/^.*for //g“

Diese Ausgabe müssen wir um den eigentlichen Befehl so erweitern, daß wir die Informationen vom PC bekommen und das geht mit „nmblookup -A <ip>“:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“ | sed -e „s/^.*for //g“ | awk ‚{print „nmblookup -A „$1;}’|bash

..Das Ergebnis der Mühe wert..

Das Ergebnis sieht dann so aus:

Looking up status of 192.168.1.2
W10-HEIST <00> – B <ACTIVE>
MOVIE <00> – <GROUP> B <ACTIVE>
W10-HEIST <20> – B <ACTIVE>

MAC Address = 52-54-00-48-D1-17

Looking up status of 192.168.1.87
No reply from 192.168.1.9

Looking up status of 192.168.1.188
AUTOCAD02 <00> – B <ACTIVE>
AUTOCAD02 <20> – B <ACTIVE>
INGENIEURE <00> – <GROUP> B <ACTIVE>

MAC Address = 90-1B-0E-53-5E-07

Jetzt habe ich die IP, den Namen, die Arbeitsgruppe und die Macaddresse von jedem Windows PC mit RDP. Jederzeit aktualisierbar. Live 🙂

Das war Teil 1 der Aufgabe, denn für den Fall, für den ich das so gemacht habe, war das das gewünschte Ergebnis. Wir können aber noch mehr machen. Wir haben die IP und die MAC eines PCs.

Was wäre, wenn man damit die Topologie ermitteln könnte?

Vorweg: Es gibt andere Methoden, z.b. snmp Abfragen am Switch und Router, die sind etabliert und funktionieren. Allerdings ist son snmpwalk abhängig davon was die einzelnen Geräte anbieten, da muß man einiges an Zeit reinstecken, wenn man das selbst bauen will.

Zeit ist aber das richtige Stichwort 🙂 Pakete laufen im Netz abhängig von der Strecke zwischen den PCs unterschiedlich lange. Wie bekomme ich das raus? Richtig mit Ping:

# ping -c 20 192.168.1.25
PING 192.168.1.25 (192.168.1.25) 56(84) bytes of data.
64 bytes from 192.168.1.25: icmp_seq=1 ttl=64 time=0.215 ms
64 bytes from 192.168.1.25: icmp_seq=2 ttl=64 time=0.195 ms
64 bytes from 192.168.1.25: icmp_seq=3 ttl=64 time=0.209 ms
64 bytes from 192.168.1.25: icmp_seq=4 ttl=64 time=0.204 ms
64 bytes from 192.168.1.25: icmp_seq=5 ttl=64 time=0.166 ms
64 bytes from 192.168.1.25: icmp_seq=6 ttl=64 time=0.204 ms
64 bytes from 192.168.1.25: icmp_seq=7 ttl=64 time=0.253 ms
64 bytes from 192.168.1.25: icmp_seq=8 ttl=64 time=0.158 ms
64 bytes from 192.168.1.25: icmp_seq=9 ttl=64 time=0.200 ms
64 bytes from 192.168.1.25: icmp_seq=10 ttl=64 time=0.184 ms
64 bytes from 192.168.1.25: icmp_seq=11 ttl=64 time=0.199 ms
64 bytes from 192.168.1.25: icmp_seq=12 ttl=64 time=0.249 ms
64 bytes from 192.168.1.25: icmp_seq=13 ttl=64 time=0.264 ms
64 bytes from 192.168.1.25: icmp_seq=14 ttl=64 time=0.225 ms
64 bytes from 192.168.1.25: icmp_seq=15 ttl=64 time=0.297 ms
64 bytes from 192.168.1.25: icmp_seq=16 ttl=64 time=0.255 ms
64 bytes from 192.168.1.25: icmp_seq=17 ttl=64 time=0.290 ms
64 bytes from 192.168.1.25: icmp_seq=18 ttl=64 time=0.328 ms
64 bytes from 192.168.1.25: icmp_seq=19 ttl=64 time=0.212 ms
64 bytes from 192.168.1.25: icmp_seq=20 ttl=64 time=0.229 ms

— 192.168.1.25 ping statistics —
20 packets transmitted, 20 received, 0% packet loss, time 19360ms
rtt min/avg/max/mdev = 0.158/0.226/0.328/0.047 ms

Wenn wir also statt nmblookup ping einbauen, können wir jeden dieser Pcs messen:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“ | sed -e „s/^.*for //g“ | awk ‚{print „ping -c 20 „$1;}’|bash | grep -E „(statistics|rtt)“ | sed -e „s/— //g“ -e „s/ ping.*$//g“ -e „s/rtt //“ -e „s/\/max\/mdev = /:/g“ -e „s/\//:/g“ | awk -F „:“ ‚{print $1″=“$3″ „$2″=“$4;}‘ | sed -e „s/= =//“

da kommt sowas bei raus:

192.168.1.21
min=0.624 avg=0.851

Wert ermittelt, jetzt muß er bewertet werden..

Jetzt kann man sich überlegen, inwieweit Ihr dem MIN Wert traut, denn der ist stark vom Netzwerkverkehr abhängig, wo hingegen avg so etwas bedingt ausbügelt. Man sollte die Messung zu verschiedenen Zeiten wiederholen und dann die Ergebnisse zusammenrechnen. Für diese Prinzipdarstellung reichts auch erstmal so 😉

Wir können aus den MIN-Daten folgendes ermitteln: Alle PCs mit der gleichen Antwortzeit sind gleich weit weg, oder der antwortende PC ist ne alte Krücke 😉 Gleich weit weg bedeutet in Wirklichkeit: diese PCs könnten in einem Zimmer stehen, aber die könnten auch in verschiedenen Zimmern stehen, die über gleich lange Kabel angeschlossen sind. Das ist der Knackpunkt.

Üblich ist, daß im Serverraum ein Patchfeld ist, von dem die Kabel in die einzelnen Regionen des Gebäudes abzweigen. Der Vorteil dabei ist der Datendurchsatz und das man PortSense benutzen kann, der Nachteil, daß viel mehr Kabel gezogen werden, als nötig wären.

Datenaustausch in einem Netzwerk

Jetzt überlegen wir mal, welchen Test wir noch machen können… hmm.. IP.. Name… MACAdressse… MACAdresse… hey, wir haben eine MACAdresse vom PC direkt.. vergleichen wir die doch mal mit dem was im Arptable steht 😀

Erstmal erklären: Der Datenaustausch findet in einem Netz nicht zwischen IPs statt, sondern zwischen MAC Adressen. Das sind die Adressen der Netzwerkkarten die da zum Einsatz kommen. Haben wir eine direkte Verbindung zu dem Austauschpartner, hat die IP im Arpcache die gleiche Macadresse wie die per nmblookup mitgeteilt wurde. Im ARP Cache, erreichbar über den Befehl apr, bekommen wir die für die Kommunikation zur IP genutzte Mac auf dieser Seite der Verbindung:

Looking up status of 192.168.1.51

MAC Address = B1-6E-FF-D3-42-B4

# arp |grep 1.51
192.168.1.51 ether b1:6e:ff:d3:42:b4 C eth0

Ist da aber ein anderes Gerät dazwischen ( z.B. Router ), dann hat das Arpcache bei uns eine andere MAC als das Gerät uns per nmblookup mitgeteilt hat. Hinweis: Switche geben Ihre eigenen MAcs nicht preis, die sind transparent was das betrifft. Ein Router könnte jetzt also ein Netzumsetzer, eine Bridge, Tunnel oder ähnliches sein:

Looking up status of 192.168.1.51

MAC Address = B1-6E-FF-D3-42-B4

# arp |grep 1.51
192.168.1.51 ether  A0:43:3d:3A:13:45 C eth0

Wenn man jetzt also mehrere IPs mit der gleichen MAC hat, weiß man, daß die zusammen auf entweder einer Hardware laufen, dann wären die Pingzeiten alle gleich, oder die laufen alle durch einen Router/Tunnel und haben unterschiedliche Laufzeiten, dann stehen die hinter dem Router an verschiedenen Stellen.

Andere Ergebiskombinationen

Jetzt gibts noch die Kombi, daß die Laufzeit für einige IP gleich ist, die Mac auch, aber die Mac noch bei anderen IPs auftaucht, die andere Laufzeiten haben, dann sind die IPs mit gleicher Laufzeit auch auf einer anderen Hardware hinter so einem Router platziert und der Rest steht irgendwo anders.

Wenn man nur von einem Standort aus scannt, bekommt man möglicherweise einen falschen Eindruck, weil wir die „Welt“ nur zweidimensional sehen. Wenn unserer erstes Zwischengerät seine MAC anzeigt, könnten da noch einige andere hinter liegen, die wir nicht mehr sehen können. Deswegen ist eine automatische Topologie zumindest mit dieser simplen Methode hier, bei komplexen Setups nicht ausreichend genau.

Das war natürlich jetzt nur eine theoretische Überlegung, ich hatte ja gesagt, daß es da etablierte Methoden gibt. Wann könnte das also noch mal wichtig sein? z.B. wenn man mit LAHA Audio zeitgleich ans Ziel streamen will: Multi-Netzwerk-Lautsprecher mit Linux

Hier wäre, wenn wir es schon eingebaut hätten, die Laufzeit eine wichtige Komponente, damit die Streams alle zeitgleich zu hören sind. Vielleicht baue ich das ja mal ein. Ich habe gerade erst AndroidStudio wieder zum Leben erwecken können 😀

Anmerkungen:

Alle MACs sind frei erfunden. Je nach Aufgabenstellung kann man auch andere Ports als Scankriterium für Nmap oder gleich einen PING-Scan benutzen. NMAP gibt u.U. einen aufgelösten Domainnamen zurück:

Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-19 13:14 CEST
Nmap scan report for android-501a417bc9ee518.fritz.box (192.168.0.39)
Host is up (0.090s latency).

PORT STATE SERVICE
445/tcp closed microsoft-ds
MAC Address: 6C:F1:76:2D:3B:AA (Samsung Electronics)

da müßt Ihr die SED Anweisungen entsprechend ändern oder nmap die „-n“ Option verpassen, sonst passieren skurille Dinge :DD

 

Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Eine wichtige Ressource für alle, denen der Grub2 Security Fix ihrer Distribution das Booten sabotiert hat, ist:

https://docs.pagure.org/docs-fedora/the-grub2-bootloader.html

Die ist zwar für Fedora, aber da steht alles in Kleinarbeit drin, wie man Bootloaderprobleme selbst behebt.

Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Für alle != Fedora oder RH basierten Distris gelten die gleichen Schritte nur die Pakete heißen anders.

Das Vorgehen ist immer das Gleiche:

1. Von einem USB Stick booten
2. die lokale Systemplatte mounten
3. chroot /*mount_systemplatte*
4. /boot/ einhängen
5. mit dem hoffentlich eingerichteten Netzwerk die alte Grubversion aus dem Repo ziehen.

Beispiel DNF:  „dnf downgrade shim grub2*“

6.  grub2-install /dev/sda

wobei /sda  das richtige Laufwerk von Eurer Systemplatte sein muß, müßt Ihr mal schauen wie das heißt.

7. aus der chroot raus, alles unmounten, rebooten .. sollte wieder gehen.

Für alle, die das mit dem alten Grub2 Paket nicht hinbekommen, auf der LIVE-Disk die Ihr dafür benutzt IST einen alter Grub2 drauf! Den könnte man auch mal direkt versuchen 😉

Wenn Ihr EFI bootet, dann braucht es auch den passenden shim im /boot/efi/ Pfad, das ist schliesslich der Auslöser des Übels gewesen 😉  Und oh Freude, auch der ist schon passend zum Grub2 auf der Livedisk drauf, braucht man nur kopieren.

Noch etwas: Für Fedora gibt es noch kein Grub2 Update, nicht mal im Alpha Stadium. Die wissen schon wieso 😉 (hoffe ich)

32 Sicherheitslücken in Chromium gefixt

Kleine Abschweifung in RHEL:

32 Sicherheitslücken in Chromium-Browser gefixt

Wie man einem Update aus dem RHEL Security Newsletter entnehmen kann, wurden im Chromiumbrowser 32 Sicherheitslücken in einem Rutsch gefixt. Da einige davon Pufferüberläufe waren, sollte man umgehend updaten, auch wenn man nicht bei RHEL ist, da hier typischerweise RCE Lücken schlummern können, sprich:  Jemand kann aus der Ferne Code ausführen. Das bedeutet nicht, daß es so ist, aber i.d.R.  ist das eine Grundvoraussetzung dafür.  Für drei habe ich die Bewertung mal rausgesucht, wer selbst mehr wissen will, kann die  CVE Nummer einfach bei Google eingeben und landet dann hier:

https://nvd.nist.gov/vuln/detail/CVE-2020-6513

Einfach die Nummer am Ende mit der gewünschten ersetzen und man bekommt auch diese Info.

Security Fix(es):

* chromium-browser: Heap buffer overflow in background fetch (CVE-2020-6510) (Score: 7.8 )
* chromium-browser: Side-channel information leakage in content security policy (CVE-2020-6511) (Score: 6.5)
* chromium-browser: Type Confusion in V8 (CVE-2020-6512)
* chromium-browser: Heap buffer overflow in PDFium (CVE-2020-6513) (Score: 8.8)
* chromium-browser: Inappropriate implementation in WebRTC (CVE-2020-6514)
* chromium-browser: Use after free in tab strip (CVE-2020-6515)
* chromium-browser: Policy bypass in CORS (CVE-2020-6516)
* chromium-browser: Heap buffer overflow in history (CVE-2020-6517)
* chromium-browser: Use after free in SCTP (CVE-2020-6532)
* chromium-browser: Type Confusion in V8 (CVE-2020-6537)
* chromium-browser: Inappropriate implementation in WebView (CVE-2020-6538)
* chromium-browser: Use after free in CSS (CVE-2020-6539)
* chromium-browser: Heap buffer overflow in Skia (CVE-2020-6540)
* chromium-browser: Use after free in WebUSB (CVE-2020-6541)
* chromium-browser: Use after free in developer tools (CVE-2020-6518)
* chromium-browser: Policy bypass in CSP (CVE-2020-6519)
* chromium-browser: Heap buffer overflow in Skia (CVE-2020-6520)
* chromium-browser: Side-channel information leakage in autofill (CVE-2020-6521)
* chromium-browser: Inappropriate implementation in external protocol handlers (CVE-2020-6522)
* chromium-browser: Out of bounds write in Skia (CVE-2020-6523)
* chromium-browser: Heap buffer overflow in WebAudio (CVE-2020-6524)
* chromium-browser: Heap buffer overflow in Skia (CVE-2020-6525)
* chromium-browser: Inappropriate implementation in iframe sandbox (CVE-2020-6526)
* chromium-browser: Insufficient policy enforcement in CSP (CVE-2020-6527)
* chromium-browser: Incorrect security UI in basic auth (CVE-2020-6528)
* chromium-browser: Inappropriate implementation in WebRTC (CVE-2020-6529)
* chromium-browser: Out of bounds memory access in developer tools (CVE-2020-6530)
* chromium-browser: Side-channel information leakage in scroll to text (CVE-2020-6531)
* chromium-browser: Type Confusion in V8 (CVE-2020-6533)
* chromium-browser: Heap buffer overflow in WebRTC (CVE-2020-6534)
* chromium-browser: Insufficient data validation in WebUI (CVE-2020-6535)
* chromium-browser: Incorrect security UI in PWAs (CVE-2020-6536)

Für Fedora steht dieses Update leider noch aus, da Chromium-Freeworld von RPMFusion kommt und „chromium“, was aus dem Fedora Repo kommt, vom Maintainer noch nicht gebaut wurde. Ich hab die mal beide angestupst, mal sehen was passiert 😉

RCE: Firefox 79.0 Update einspielen

Mojn, Moin,

bitte spielt mal Eure FireFox Updates auf 79.0 ein, da <79 leider eine RCE Schwachstelle hat ( Remote Code Execution ). Also das Schlimmste vom Schlimmen.

RCE: Firefox 79.0 Update einspielen

Das BSI-Bürger-Cert schreibt dazu:

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Mozilla Firefox und Mozilla
Thunderbird ausnutzen, um Schadcode auszuführen, einen Absturz zu verursachen, vertrauliche
Informationen auszuspähen oder Sicherheitsvorkehrungen zu umgehen. Zur Ausnutzung genügt es, eine bösartige E-Mail, Webseite oder einen Link dorthin zu öffnen.

so spielt Ihr das Update für Fedora ein:

sudo dnf -y update –enablerepo=updates-testing firefox

Einfach noch das Rootpasswort bestätigen, fertig.

Cato der Ältere meinte dazu übrigens: Ave RPM!

Wer wissen will, was das jetzt sollte, die BS LUG trifft sich einmal die Woche zu einem VideoChat, da löse ich das auf 😉

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.

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 😀

Nvidia: Fehlercodes

Seit einigen Wochen nervt meine GTX 1050, eine schöne Gelegenheit Euch mal das Nvidia Fehlersystem näher zu bringen.

Nvidia: Fehlercodes

Zuerst müssen wir natürlich erstmal wissen, welcher Fehler überhaupt aufgetreten ist. Dazu braucht es nur dmesg:

$ dmesg |grep Xid
[ 5552.987812] NVRM: Xid (PCI:0000:01:00): 32, pid=1550, Channel ID 00000033 intr 00040000
[ 5731.173383] NVRM: Xid (PCI:0000:01:00): 32, pid=11658, Channel ID 00000033 intr 00040000
[ 5731.173633] NVRM: Xid (PCI:0000:01:00): 32, pid=11658, Channel ID 00000033 intr 00040000
[ 6326.298292] NVRM: Xid (PCI:0000:01:00): 32, pid=11982, Channel ID 00000033 intr 00040000
[ 6326.298525] NVRM: Xid (PCI:0000:01:00): 32, pid=11982, Channel ID 00000033 intr 00040000

Wie bei allen Kernelmeldungen steht am Anfang die Kernelzeit in Sekunden seit dem Boot. Danach kommt als erstes die PCI ID des Gerätes, aber da selten jemand zwei oder mehr Grafikkarten im PC hat, ist das für die meisten uninteressant. Der Fehlercode selbst ist die unscheinbare Zahl nach der PCI ID, hier „32“.

Auf der Webseite von Nvidia: xid errors findet sich dann die Beschreibung für den Fehler und erste Hinweise zur Ursache:

XIDFailureCauses
HW ErrorDriver ErrorUser App ErrorSystem Memory CorruptionBus ErrorThermal IssueFB Corruption

31

GPU memory page fault

X

X

32

Invalid or corrupted push buffer stream

X

X

X

X

X

Xid 32 meint also, daß der Datenstrom zu Grafikkarte unterbrochen wurde. Mögliche Ursachen: Der Graka-Speicher ist defekt, der PCI Bus hat ne Macke oder irgendwas ist überhitzt. (FB Corruption meint FRAMEBUFFER kaputt, das sind die Strukturen im OS/Programm welche die Grafik handhaben. )

Wie man vorn sehen kann, handelt sich nicht um einen HW Fehler, sondern am wahrscheinlichsten um einen Grafikkartentreiberbug.

Ab jetzt kann man nur noch spekulieren, weil das ja alles mögliche meinen kann. Es geht sogar soweit, daß Xid 32 Probleme bei der Stromzuführung in die Grafikkarte meinen kann, also wenn das Netzteil schwächelt. Da aber der Bildschirm nicht ausgeht, hat die Graka noch genug Saft, das kann es also eigentlich nicht sein.

Jetzt können wir noch etwas ausschließen: Thermalprobleme

55 Grad sind völlig normal. Im Bild oben sind zwar die Lüfter aus, aber die funktionieren nachweislich, denn man hört sie bei der Arbeit 😉

Das Nvidia Settingstool (oben im Bild) kann man beim Gamen auf dem zweiten Monitor mitlaufen lassen und so die Anzeige im Auge behalten.

Vielleicht doch nur ein Treiberproblem?

Jetzt bringt uns das nicht weiter. Wir haben zwar 2 Sachen ausschließen können, aber es blieben immer noch FB Problem, Memoryproblem. Keins davon kann man prüfen.

Was man jetzt noch prüfen könnte, steht im /var/log/messages sofern man das noch hat. ( Habt Ihr nicht mehr, nur noch Systemd? Ihr tut mir so leid .. ehrlich 🙁 )

$ grep NVRM /var/log/messages

Jul 23 00:43:18 eve kernel: NVRM: Xid (PCI:0000:01:00): 31, pid=1923, Ch 00000020, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_PE_0 faulted @ 0x1_0ca39000. Fault is of type FAULT_PTE ACCESS_TYPE_READ

Andere Fehlernummer.. interessant. Ist ein reiner Anwendungsbug. In diesem Fall in WINE. Wine hat in den letzten Wochen unheimlich viele Updates rausgehauen. Es wäre also wirklich im Bereich des Möglichen, daß Wine bzw. der 3D Treiber in Wine ( DXVK ) hier die eigentliche Ursache sind.

Wine hat allerdings noch ganz andere Probleme, die die Entwickler aber leider nicht wahr haben wollen, weil Bugreports ignoriert werden. Ab Wine-Staging 5.5+ kommt es zu einem wahrlich irren Bug:

Es kommt in Verbindung mit dem Grakafehler zu einem IO-Fehler mit dem DVD-ROM, welches aber gar nicht benutzt wird noch eine DVD drin hat. Das sieht dann so aus:

[22163.062313] sr 1:0:0:0: [sr0] tag#26 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[22163.062316] sr 1:0:0:0: [sr0] tag#26 Sense Key : Not Ready [current]
[22163.062319] sr 1:0:0:0: [sr0] tag#26 Add. Sense: Medium not present – tray closed
[22163.062321] sr 1:0:0:0: [sr0] tag#26 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
[22163.062323] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0
[22163.062366] sr 1:0:0:0: [sr0] tag#3 unaligned transfer
[22163.062368] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062370] Buffer I/O error on dev sr0, logical block 0, async page read
[22163.062382] sr 1:0:0:0: [sr0] tag#4 unaligned transfer
[22163.062383] blk_update_request: I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062384] Buffer I/O error on dev sr0, logical block 1, async page read
[22163.062393] sr 1:0:0:0: [sr0] tag#5 unaligned transfer
[22163.062394] blk_update_request: I/O error, dev sr0, sector 2 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062395] Buffer I/O error on dev sr0, logical block 2, async page read
[22163.062404] sr 1:0:0:0: [sr0] tag#6 unaligned transfer
[22163.062405] blk_update_request: I/O error, dev sr0, sector 3 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062406] Buffer I/O error on dev sr0, logical block 3, async page read
[22163.062415] sr 1:0:0:0: [sr0] tag#7 unaligned transfer
[22163.062416] blk_update_request: I/O error, dev sr0, sector 4 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062417] Buffer I/O error on dev sr0, logical block 4, async page read
[22163.062425] sr 1:0:0:0: [sr0] tag#8 unaligned transfer
[22163.062427] blk_update_request: I/O error, dev sr0, sector 5 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062427] Buffer I/O error on dev sr0, logical block 5, async page read
[22163.062436] sr 1:0:0:0: [sr0] tag#9 unaligned transfer
[22163.062437] blk_update_request: I/O error, dev sr0, sector 6 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062438] Buffer I/O error on dev sr0, logical block 6, async page read
[22163.062446] sr 1:0:0:0: [sr0] tag#10 unaligned transfer
[22163.062448] blk_update_request: I/O error, dev sr0, sector 7 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062448] Buffer I/O error on dev sr0, logical block 7, async page read

und das ist nur beim Starten von Wine, da ist noch nicht mal eine GFX Operation gelaufen. Mit WIne 5.13 geht nicht mal ein Fenster auf, das ist derzeit komplett im *****.

Das bestärkt mich in der Annahme, daß es sich um reine Driverbugs handelt, die von WINE getriggert werden. Rein zur Vorsicht, habe ich das .nv/GLCache geleert, vielleicht lag da ja noch was defektes drin.

Mehr ist zu dem Zeitpunkt leider nicht feststellbar. Jetzt hilft nur Testen, updaten, Testen und weiter Testen.