Skip to content

Webex sucht deine Zertifikate auf einem Cisco-Build-Server

Webex 46.8.0.35631 auf Fedora 44 sitzt hinter einem gelben Banner mit der Aufschrift „Offline - No internet connection“, während jedes andere Programm auf der Maschine ohne Murren ins Internet kommt. Es hat die VoIP-Leitung totgelegt. Das Netz war nie das Problem: Cisco liefert einen eigenen Fork von OpenSSL mit und hat ihn mit OPENSSLDIR auf /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl gebaut, einem Verzeichnis, das es auf einem Build-Container gibt und sonst nirgends, also lädt es keine Vertrauensanker und jeder Handshake scheitert. Der Beitrag geht der Reihe nach vor: was der kaputte Zustand tatsächlich ist, die mitgelieferte Bibliothek fragen, wo sie ihre Zertifikate vermutet, den exakten Fehlercode außerhalb von Webex reproduzieren, warum nichts warnt, die zwei Lösungen, die nicht funktionieren, und warum, und die eine, die funktioniert. Dann der Build-Prozess: sie haben $ORIGIN für den Code benutzt und drei Datenpfade absolut gelassen, der RPM-Header nennt eine Container-ID, der Container war also schon in der Pipeline und wurde nie benutzt, um das Ergebnis auszuführen, das Paket verlangt eine glibc von 2018, weil sie nicht statisch linken wollen, 2,2 GB werden zweimal ausgeliefert, und es bringt keine Dokumentation und keine als Konfiguration markierte Datei mit. Dann, wie es hätte gebaut werden müssen, die sechs Korrekturen und die einzeilige Prüfung, die das findet. Und zum Schluss der Gegencheck: Cisco hält 98 Einträge im Katalog bekannter ausgenutzter Schwachstellen der CISA, nur Microsoft liegt davor, und ein ungeprüfter Vertrauenspfad und eine ungeprüfte Umgehung sind derselbe Fehler bei unterschiedlichem Einsatz.

15. September 2026 Â· 41 Minuten Â· 8850 Wörter Â· Damien Dye

Ein VPN aus Einzelteilen: PPP, Tap-Devices und Netcat

Ein VPN sind zwei Aufgaben: etwas, das einen virtuellen Link macht, und etwas, das die Bytes trägt. PPP erledigt die erste seit 1994 und ist es egal, was die zweite ist — deshalb sind PPTP, L2TP und jede Wählleitung, die du je benutzt hast, dasselbe Protokoll über verschiedene Träger. Netcat ist ein Träger. Dieser Beitrag baut es auf beide Arten. Zuerst pppd: die pty-Option und was sie mit einem Pseudo-Terminal macht, die TCP-Variante, die jeder zuerst probiert, warum ein Stream-Protokoll in TCP unter Verlust zusammenbricht, die UDP-Variante, die man nehmen sollte, das asynchrone HDLC-Framing und die ACCM, die entscheidet, wie viel Bandbreite auf das Escapen von Steuerzeichen geht, Adressierung und Routing und IPV6CP, und den Link am Leben halten, wenn der Träger stirbt, ohne es zu sagen. Dann derselbe Tunnel ganz ohne PPP — ein Tap-Device, ein Datagramm pro Frame über UDP, das Längenpräfix, das man über TCP selbst erfinden muss, tun gegen tap, und Bridging. Dann der Teil, für den Netcat keine Antwort hat: den Träger in TLS wickeln mit ncat, stunnel und openssl, und in DTLS mit socat, was die Form ist, die man eigentlich will. Es ist nie wirklich das richtige Werkzeug, und das ist der Punkt: Es zeigt, wie sich Egress verhält, sobald ein Angreifer in deinem Netzwerk Root hat und der ausgehende Zugang nicht standardmäßig blockiert war, und warum Default-Deny an der Grenze die einzige Kontrolle ist, die je real war.

14. September 2026 Â· 58 Minuten Â· 12620 Wörter Â· Damien Dye
Eine Gast-Uhr, die von der Host-Uhr wegläuft, und ein Hypercall, der sie zurückholt

Der Uhr einer VM ist nicht zu trauen — und die ptp_kvm-Lösung für QEMU/KVM

Die Uhr einer virtuellen Maschine steht auf einer Annahme, die Virtualisierung zerbricht: dass die CPU weiterzählt. Warum Gast-Zeit auf jedem Hypervisor wegläuft, was der Versatz tatsächlich kaputt macht — Kerberos, TLS, Ceph, Windows — und wie ptp_kvm es auf QEMU/KVM richtig löst.

7. August 2026 Â· 15 Minuten Â· 3040 Wörter Â· Damien Dye