Category Archives: Fedora

TLS: Timing Attacke RACCOON

Posted on by

Intel kennt das Problem: Laufend kommt einer an und kann an der Laufzeit von Berechnungen Daten ableiten, die er nicht sieht. Jetzt ist mal wieder TLS dran mit so einem Angriff auf den DH Schlüssel.

TLS: Timing Attacke RACCOON

Wie die Hacker News berichten, gibt es eine neue, aber sehr spezielle, Methode an einen Serverschlüssel zu kommen. Voraussetzung ist allerdings, daß der Server seine verwendeten Schlüssel erneut benutzt. Das sollte er wegen PFS sowieso nicht tun, aber nicht alle Dialekte von TLS 1.2 sind PFS fähig.

Um die Lücke ausnutzen zu können, muß der Angreifer zu dem sehr präzise Messungen zur Laufzeit machen können, daher muß er technisch sehr dicht am Server dran sein, um die Messungen akkurat vornehmen zu können. In den meisten Fällen wird der Versuch da bereits scheitern. Auch Scheitern wird der Angriff, wenn PFS zum Einsatz kommt, weil der Server den privaten DH Schlüssel dann nicht wieder verwendet.

F5, Mozilla, Microsoft und OpenSSL haben schon Updates parat, wobei M$ sich darauf beschränkt, die DHE einfach abzuschalten, statt das Problem zu lösen 😀 Auch ne Methode 😉 Wie man hier nachlesen kann: OPENSSL: https://www.openssl.org/news/secadv/20200909.txt hat OpenSSL das Problem in älteren OpenSSL Versionen bereits durch eine andere Defaulteinstellung behoben. Damit ist die Gefährlichkeit des Angriffs eher gering einzuschätzen.

Ich habe mir mal die Mühe gemacht und konnte selbst in einer 2 Jahre alten OpenSSL Version den nötigen Cipher nicht und damit ist der Webserver auch nicht anfällig. Ein Test durch SSLLabs hat das bestätigt:

Uses common DH primesNo, DHE suites not supported
DH public server param (Ys) reuseNo, DHE suites not supported
ECDH public server param reuseNo

Also, keine Panik, wenn Ihr nicht 10 Jahre alte Software einsetzt, ist alles gut.

Linux: Runes of Magic zurück

Posted on by

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.)

LUKS: Wie man einen Cloud-Container erstellt.

Posted on by

Wer kennt das Bedürfnis nach Synchronisation des Dateibestandes von verschiedenen Geräten über einen Cloudanbieter aka Webhoster nicht? Ok, Ihr könnt jetzt zur nächsten OSBN News wechseln, außer Ihr möchtet an einem Zweitstandort eine sicher aufgehobene Kopie Eurer Daten haben, auf die nur Ihr Zugriff habt, dann lest jetzt weiter …

LUKS: Wie man einen Cloud-Container erstellt.

Verschlüsselungssysteme gibt es ja viele, aber nicht alle sind bei jeder Distro onboard und osübergreifend verfügbar, LUKS schon. Deswegen heute ein kleiner Beitrag wie man seine Daten bei einem Webhoster so parkt, daß man sie von überall aus einbinden kann.

ACHTUNG: Bei einer Cloud-Container-Lösung auf Basis von Luks oder Truecrypt darf nur ein PC das System aktiv einbinden, sonst Datenverlust! Möglich ist aber ein READ-ONLY-Einbinden mehrerer Rechner gleichzeitig. Ich warne ausdrücklich davor so etwas zu versuchen und es dann zu versemmeln!

Der Hintergrund für die Warnung ist ganz einfach der, daß Eurer PC der Meinung ist, daß er den Datenträger exklusiv hat und daher Sachen im RAM vorhält, die nicht auf den Datenträger synchronisiert sind um die Leistung zu steigern. Wenn zwei Rechner das machen und dann vermeidliche freie, aber vom anderen PC schon im RAM anvisierte Blöcke beschreibt, kommt es unweigerlich zum Datenverlust. Wer schon einmal mit SSHFS gearbeitet hat, das einen entfernten PC als Laufwerk einmountet, der wird bemerken, daß da keine lokale Pufferung stattfindet, weil der PC hier nicht wissen kann, ob und wer sonst noch so auf die Datenquelle zugegriffen hat. SSH greift auf der  anderen Seite auch nicht als Filesystem, sondern über die OS API auf Dateien zu und simuliert Euch nur ein Laufwerk.

Anders ist das, wenn zwar der Container per SSHFS verfügbar gemacht wird, aber das Einbinden des entschlüsselten Filesystems dann lokal stattfindet. Das findet dann wieder mit den OS eigenen IO-Steigerungsamethoden statt. Beim Mounten von Datenträgern kann man über die Mount-Options noch einiges abändern, da geht vielleicht sogar was, aber empfehlen kann ich das definitiv nicht.

Die Ausgangslage

Wir behandeln daher einen PC der auf einen Webserver zugreift, dort seinen Container lagert und die ganze Ent- und Verschlüsselung auf dem eigenen PC auflaufen lässt.

Wir brauchen: CryptSetup, einen Webserver, schnelles Internet ( ist von Vorteil )

Der Webserver

Der Webserver muß eine der folgenden Anbindungen unterstützen: SSH, SAMBA oder NFS und zwar genau in der Reihenfolge sollte man das auswählen. Für diesen Artikel nehme ich SSH, da das auf jedem LinuxPC vorhanden ist und der Transportweg so zusätzlich verschlüsselt ist. Da sieht man dann auch nicht, was da eigentlich auf dem Webserver gemacht wird.

Samba ist zwar mittlerweile auch im Datentransport verschlüsselt, aber viele Router halten das auf, damit die Windowskisten nicht das Providernetz vollspammen, die sind sehr mitteilungsbedürftig 😉

NFS kennt keine Authentifizierung außer IPs, ist unverschlüsselt und ist im allgemeinen bestenfalls zwischen Servern einzusetzen.

Das PRE-SETUP

Wir machen das alles als ROOT, weil CryptSetup und mount das gern so möchten. Da hier FUSE nur sekundär im Einsatz ist, weil es sich um normale Filesysteme des Kernels handelt (kommt gleich),  kommt mount zum Einsatz, welches zwingend als ROOT laufen möchte. Das Ergebnis der Aktion kann aber dann von jedem User benutzt werden. Wenn man sich da nicht besonders blöd im Rechtemanagement anstellt, dann ist das auch auf einem Mehrbenutzersystem kein Problem.  Kommen wir zu …

Schritt 1: Einen Mountpoint für den Container erstellen

mkdir -p /media/container/server

Der Ort ist in der Regel für jeden Benutzer erreichbar, was z.b. beim Mounten im eigenen Home nur für den aktuellen Benutzer gelten würde.

Schritt 2: Der Server als Laufwerk einbinden

sshfs demo@meine.demo.de:/home/demo /media/container/server -o allow_other

Je nachdem was man als Authmechnismus eingestellt hat ( KEY oder PASSWORD )  macht da der SSH-AGENT, der hoffentlich in irgendeiner Form bei Euch läuft ( gpg-agent, ssh-agent, gnome-keyring-daemon ) das mit dem Schlüssel automatisch für Euch, oder Ihr müßt ein Passwort eingeben.

Schritt 3: Das Containerfile anlegen

Hier im Beispiel benutze ich jetzt ein 100MB File ( 1M * 100 ) :

# dd if=/dev/zero of=/media/container/server/container.luks bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
104857600 bytes (105 MB, 100 MiB) copied, 29,0354 s, 3,6 MB/s

Wer da übers Netz GBweise Dateien anlegt, der sollte sich fragen, ob er verstanden hat, was er da gerade tut, denn das dauert Stunden und man könnte es ja auch auf dem Webserver erledigen lassen, daß dauert nur Sekunden, denn noch ist da weder Crypto noch ein Filesystem dran beteiligt, es wird nur ein BLOCK mit NULLEN erzeugt.

Schritt 4: Den Container mit LUKS formatieren

Der nächste Schritt sollte allerdings zwingend vom PC aus erledigt werden, da dazu ein Passwort nötig ist, welches, solange der Vorgang dauert, auch im Speicher des Webservers verfügbar wäre, würde man es dort tun. Das Formatieren dauert dann auch ein gutes Weilchen.

# cryptsetup -y luksFormat /media/container/server/container.luks

WARNING!
========
Hiermit werden die Daten auf »/media/container/server/container.luks« unwiderruflich überschrieben.

Are you sure? (Type ‚yes‘ in capital letters): YES
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************
Passphrase bestätigen: ***********************

Ein sinnvoll langes Passwort > 20 Zeichen ist angeraten! Es sollte nicht 123456789… lauten 😉

Schritt 5: Den Container öffnen und zum Mounten bereitstellen

Dieser Schritt geht dann recht zügig von statten. Ihr müßt nicht zwangsweise den gleichen Cryptocontainernamen benutzen wie ich, da seid Ihr flexibel.

# cryptsetup luksOpen /media/container/server/container.luks cryptocontainer
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************

Schritt 6: Das Filesystem erstellen

Beim ersten mal muß man jetzt das Filesystem einrichten:

# mkfs.ext4 -j /dev/mapper/cryptocontainer
mke2fs 1.45.5 (07-Jan-2020)
Ein Dateisystem mit 86016 (1k) Blöcken und 21560 Inodes wird erzeugt.
UUID des Dateisystems: bcbccb1b-794e-4700-bd64-cd021a42bf32
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden geschrieben: erledigt

ich habe jetzt EXT4 ausgewählt, weil das in jedem Kernel vorkommt und als Journalingfilesystem keine ellenlangen Reparaturen vor dem Mounten braucht, was gerade bei einem Netzwerkcontainer ein wichtiger Entscheidungsgrund ist, sonst wartet Ihr da auch schon mal Stunden auf den Mount.

Schritt 7: Den Containerinhalt ins System einbinden

Das Einbinden in das System ist dann denkbar einfach:

# mount /dev/mapper/cryptocontainer /mnt
# df -h | grep mnt
/dev/mapper/cryptocontainer 78M 1,6M 70M 3% /mnt

Das wärs schon, wenn da nicht das Zugriffsproblem wäre. Also muß Root da jetzt z.B. noch ein Verzeichnis anlegen, weil die User keine Schreibrechte haben:

# ls -ls /mnt/
insgesamt 12
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found
# ls -lad /mnt/
drwxr-xr-x. 3 root root 1024 13. Sep 12:01 /mnt/
# mkdir /mnt/demo
# chown demo:demo /mnt/demo
# chmod 700 /mnt/demo/
# ls -ls /mnt
insgesamt 14
2 drwx——. 2 demo demo 1024 13. Sep 12:10 demo
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found

Nun kann der Benutzer „demo“ da machen was auch immer er möchte.

Einbinden beim System-Boot

Das ist nicht ganz ohne. Man könnte dem Cron sagen, daß er das nach dem Boot machen soll, indem man da ein kleines Script benutzt, daß alle Schritte als Root macht, aber wer sagt uns, daß das auch passiert, wenn ein Netzwerk vorhanden ist? Niemand, also müssen wir das wohl oder übel an den Systemd übergeben. D.b. Ihr schreibt einfach ein kleines Start/Stop Script nach /etc/init.d/ oder direkt eine Unit für Systemd direkt, in dem die Anhängigkeiten zum erfolgreichen Netzwerkstart angegeben sind z.b. wie hier:

xl2tpd.service:After=network.target

So ist sichergestellt, daß es auch klappen kann, sofern alles mit dem Netzwerk und dem Server ok ist.

Sicherheitsanalyse

Wo liegen hier die Vorteile zu einem USB Stick? Zum Einen macht der Hoster normalerweise ein Backup von dem Server oder bietet Euch zumindest an, daß Ihr eins machen könnt. Dann ist das von überall aus erreichbar und i.d.R. kann man das nicht verlieren. Auch ein „Diebstahl“ wäre nicht tragisch, da der Dieb nicht an den Inhalt kommt, außer Eurer Passwort war „123456“ 😀

Die gesamte Ver- und Entschlüsselung der Daten findet zur Laufzeit auf Eurem PC statt, d.b. jemand muß sich Zugang zu Eurem PC verschaffen und dann auf die Daten zugreifen, wenn diese lokal verfügbar sind. Das könnt Ihr mit Updates und Festplattenvollverschlüsselung leicht kontern, denn dann können Euch lokale Angreifer mal am ….. . Auf diese Sicherheit müßt Ihr sowieso bauen, da ansonsten der Aufwand die Daten verschlüsselt im Netz zu speichern kompletter Unfug wäre. Also ganz klar: Entweder alles oder nichts verschlüsseln, sonst nützt es im Zweifel nichts.

VeraCrypt vs LUKS

Aus Benutzersicht ein klares Ja zu VeraCrypt: Kommt mit GUI und bindet sich ohne Root auch beim Login automatisch per FUSE ein.. 1a!

Der LUKS Container hat aber den Vorteil, daß man damit nur den Leuten vertrauen muß, die sowieso schon Eurer OS zusammenbauen. Wenn man denen nicht trauen würde, könnte man auch VeraCrypt nicht einsetzen, weil wenn das OS unsicher ist, wozu dann noch Verschlüsseln?

Über die /etc/crypttab kann LUKS Medien auch automatisch ins System einbinden lassen, allerdings muß zu dem Zeitpunkt das Netzlaufwerk mit dem Container verfügbar sein, sonst ist Essig. Hat also alles Vor- und Nachteile. Welche davon für Euch interessant sind, müßt Ihr entscheiden.

Wie bekomme ich den Container wieder zu?

Wichtige Frage, einfache Antworten:

umount /media/container/server
cryptsetup luksClose cryptocontainer
fusermount -u /media/container/server

CryptSetup: Update behebt CVE-2020-14382

Posted on by

Hi,

wer von Euch LUKS2 einsetzt sollte jetzt weiterlesen und nebenbei schon mal schauen, ob die Updates eingespielt sind.

CryptSetup: Update behebt CVE-2020-14382

CryptSetup fällt auf manipulierte Dateien herein, die sich als Luks2 Container ausgeben. Möglich ist es, damit ein nicht vorgesehenen Schreibzugriff auszulösen. Das ist per se nicht gut für Eure Datenintegrität 😉

Behoben wurde die in Version 2.2.0 eingeführte Ursache mit dem Update auf 2.3.4.

Nicht betroffen ist, wer Luks nicht benutzt um manipulierte Datencontainer aufzumachen aka. nicht auf alles draufklicken, was per Post kommt 🙂

Problematisch wird das nur, wenn jemand einen manipulierten USB Stick bei Euch einschieben kann, der sich als LUKS2 Laufwerk ausgibt. Da solche Laufwerke automatisch eingebunden werden, wird der Container sofort geöffnet. Hier hilft USB-Guard weiter, der nicht autorisierte USB Geräte gar nicht erst an das OS lässt.

Updates für Fedora gibts z.B. so:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/cryptsetup/2.3.4/1.fc31/x86_64/cryptsetup-2.3.4-1.fc31.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/cryptsetup/2.3.4/1.fc31/x86_64/cryptsetup-libs-2.3.4-1.fc31.x86_64.rpm

Quelle: https://access.redhat.com/security/cve/CVE-2020-14382

Schwachstellen im Apache Webserver < 2.4.44

Posted on by

Wer Apache als Webserver einsetzt, sollte jetzt aufpassen, denn wir haben jeweils eine  RCE und eine DOS Schwachstelle.

Schwachstellen im Apache Webserver < 2.4.44

In Apache wurden drei Schwachstellen identifiziert und im August behoben. Leider hat man u.a. bei Fedora vergessen, das publik zu machen, deswegen hier die Erinnerung für Euch:

Im HTTP2 Modul sind zwei Schwachstellen enthalten, die zum Crash führen und damit als DOS (Denial of Service) gelten:

important: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-9490)
moderate: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-11993)

Beide Schwachstellen kann man auch per Konfigurationsänderung abwehren, falls man keine gepatchten Webserver bekommen kann, oder noch nicht hat:

Je nachdem was Ihr für eine Distro habt, wird HTTP2 an verschiedenen Stellen aktiviert. Bei Fedora bietet sich an, eine eigene kleine Config in conf.modules.d/ anzulegen. In die Datei kommen zwei Einträge:

99-mitigate-http2.conf:

H2Push off
LogLevel warn mod_http2.c:error

Dann mit „systemctl httpd restart“ den Server neustarten. Die erste Anweisung behebt die 2020-9490 und die zweite sagt dem HTTP2 Modul, es soll nur kritische Sachen loggen, anstatt auch Warnungen. Das ist wichtig, da Angreifer über einen provozierten Fehler den Logging-Pool der Prozesse stören können und das führt dann zum Crash, was aber nur geht, wenn der Fehler auch geloggt wird.

moderate: mod_proxy_uwsgi buffer overflow (CVE-2020-11984)

Wer mit dem WebSocket Proxy uwsgi arbeitet, der muß updaten, eine Mitigation der möglichen Remote-Code-Schwachstelle ist nicht möglich. Bis zum Update kann man das Modul auch abschalten:

Für Fedora wäre das hier in conf.modules.d/00-proxy.conf:

# LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

Einfach ein # vor die Ladeanweisung und den Webserver mit „systemctl httpd restart“ neustarten. Natürlich funktionieren die Proxy Tunnel, die auf „uwsgi:://server:port/uri“ lauten, dann nicht mehr. Habt Ihr noch einen vhost konfiguriert, der das benutzen möchte, wird der Start des Webservers nicht funktionieren.

Updates vorhanden

Updates auf die 2.4.46 liegen für Fedora bereit. Für alle, die Ihre Server per Autoupdate versorgen, hat sich das Problem damit bereits erledigt.

Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

„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

Kernel 5.7.8+ Problem entdeckt

Posted on by

Es ist mal wieder soweit, ein fieses Kernelproblem wurde entdeckt. Ja ok, passiert dauernd, aber meisten sind nicht alle davon betroffen, hier schon, da es ein Speicherzugriffsfehler ist.

Kernel 5.7.8+ Problem entdeckt

In den letzten zwei Tagen sind zwei verschiedene Computer mit dem gleichen Fehlerbild stehen geblieben:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation

Der PC bleibt dabei nicht gleich stehen, sondern der Zugriff auf Strukturen im /proc Filesystem ( procfs ) friert einfach ein. Als Resultat bleiben Programme wie „top“ oder „pidof“ stecken. Das ist besonders blöd, weil „pidof“ beim Startprozess eines Terminals für die Bash mitmischt und man so keins mehr starten kann.

Ich hatte erst gedacht, daß wäre ein VM Problem, weil es zunächst im Servercluster aufgetreten ist, aber da es jetzt auch bare-metal auf einem Desktop-PC passiert ist, was es Zeit Alarm zu schlagen.

Wer Kernel 5.7.8 einsetzt kann sich derzeit nicht sicher sein, daß der PC durchläuft. Bei mit lag der Ausfallzeitpunkt bei knappen 15 Stunden Betriebszeit für bare-metal und ~2 Wochen für eine VM in der heute das gleiche passiert ist. Da das Problem frisch entdeckt wurde, gibt es noch keine Reaktion vom Kernel Team. Ich kann aber nur dazu raten einen anderen Kernel lauf zu lassen.

Wenn Ihr das Problem rechtzeitig bemerkt, könnt Ihr noch über die Desktop-Systemüberwachung in die Prozessliste und die „pidof“ Prozesse abbrechen, die das Starten eines Terminals verhindern. Danach kommt die Bash i.d.r. sauber hoch und Ihr könnt Reboot eingeben. Ein „systemctl reboot -i“ wird nötig sein, da der normale Reboot, zumindest bei mir, verweigert wurde.

Hier für Euch die ganze Kernelmeldung für Vergleichszwecke:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation
Aug 2 18:01:18 shortname kernel: PGD 2a0c067 P4D 2a0c067 PUD 3800067 PMD 1ffff2067 PTE 100001e2e48065
Aug 2 18:01:19 shortname kernel: Oops: 0003 [#3] SMP NOPTI
Aug 2 18:01:19 shortname kernel: CPU: 0 PID: 96 Comm: kswapd0 Tainted: G D W 5.7.8-100.fc31.x86_64 #1
Aug 2 18:01:19 shortname kernel: RIP: e030:ptep_clear_flush_young+0x1d/0x30
Aug 2 18:01:19 shortname kernel: Code: 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 90 0f 1f 44 00 00 48 8b 05 ec 74 40 01 48 25 00 f0 ff ff 48 f7 d0 48 23 02 83 e0 20 74 0c <f0> 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 66 0f 1f 44 00 00 0f 1f 44
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90001127a48 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: 0000000000000020 RBX: ffff888101c64ed8 RCX: 0000000000000000
Aug 2 18:01:19 shortname kernel: RDX: ffff8881e2e48630 RSI: 00007fe123ac6000 RDI: ffff888101c64ed8
Aug 2 18:01:19 shortname kernel: RBP: ffffea00049c2e80 R08: 0000000000000101 R09: 0000000000000125
Aug 2 18:01:19 shortname kernel: R10: ffff8881f483e8d0 R11: ffffea0005ddc2a0 R12: ffffc90001127b08
Aug 2 18:01:19 shortname kernel: R13: 0000000000000000 R14: 00007fe123ac6000 R15: 0000000000000186
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660
Aug 2 18:01:19 shortname kernel: Call Trace:
Aug 2 18:01:19 shortname kernel: page_referenced_one+0x59/0x150
Aug 2 18:01:19 shortname kernel: rmap_walk_file+0x157/0x2f0
Aug 2 18:01:19 shortname kernel: page_referenced+0xdb/0x150
Aug 2 18:01:19 shortname kernel: ? rmap_walk_file+0x2f0/0x2f0
Aug 2 18:01:19 shortname kernel: ? page_get_anon_vma+0x80/0x80
Aug 2 18:01:19 shortname kernel: shrink_active_list+0x2e5/0x560
Aug 2 18:01:19 shortname kernel: shrink_lruvec+0x3b9/0x6b0
Aug 2 18:01:19 shortname kernel: ? do_shrink_slab+0x52/0x2c0
Aug 2 18:01:19 shortname kernel: shrink_node+0x169/0x680
Aug 2 18:01:19 shortname kernel: balance_pgdat+0x2d9/0x5c0
Aug 2 18:01:19 shortname kernel: kswapd+0x1ed/0x3a0
Aug 2 18:01:19 shortname kernel: ? __schedule+0x2c2/0x730
Aug 2 18:01:19 shortname kernel: ? finish_wait+0x80/0x80
Aug 2 18:01:19 shortname kernel: kthread+0xf9/0x130
Aug 2 18:01:19 shortname kernel: ? balance_pgdat+0x5c0/0x5c0
Aug 2 18:01:19 shortname kernel: ? kthread_park+0x90/0x90
Aug 2 18:01:19 shortname kernel: ret_from_fork+0x35/0x40
Aug 2 18:01:19 shortname kernel: Modules linked in: fuse btrfs blake2b_generic xor raid6_pq hfsplus hfs minix vfat msdos fat jfs xfs nfsv3 nfs_acl nfs lockd grace fscache xt_owner ipt_REJECT nf_reject_ipv4 xt_connlimit nf_conncount nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c xt_multiport ip6table_filter ip6_tables cls_u32 sch_htb iptable_filter intel_rapl_msr intel_rapl_common cfg80211 sb_edac x86_pkg_temp_thermal coretemp crct10dif_pclmul rfkill crc32_pclmul ghash_clmulni_intel intel_rapl_perf sunrpc ip_tables xen_netfront xen_blkfront crc32c_intel
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630
Aug 2 18:01:19 shortname kernel: —[ end trace 7fb962ee698fa150 ]—
Aug 2 18:01:19 shortname kernel: RIP: e030:unmap_page_range+0x631/0xec0
Aug 2 18:01:19 shortname kernel: Code: fe e8 03 f8 ff ff 48 83 7c 24 18 00 48 89 c3 74 09 48 85 c0 0f 85 c0 05 00 00 41 f6 44 24 20 01 0f 84 25 03 00 00 4c 8b 6d 00 <48> c7 45 00 00 00 00 00 4d 39 7c 24 10 4c 89 f8 49 0f 46 44 24 10
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90002a2bb38 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: ffffea0001b72500 RBX: ffffea0001b72500 RCX: 0000000000000125
Aug 2 18:01:19 shortname kernel: RDX: 0000000000000000 RSI: 00005589f49e7000 RDI: 000000083aa94125
Aug 2 18:01:19 shortname kernel: RBP: ffff8881e3d90f38 R08: ffff88810011e320 R09: 0000000000000000
Aug 2 18:01:19 shortname kernel: R10: 0000000000007ff0 R11: 0000000000000000 R12: ffffc90002a2bc80
Aug 2 18:01:19 shortname kernel: R13: 000000083aa94125 R14: 00005589f49e8000 R15: 00005589f49e7000
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660