Fragen? Antworten! Siehe auch: Alternativlos
Ziel der Backdoor ist sshd, wenn er wie bei Debian gepatcht wurde, um systemd-notification zu benutzen.
Update: Hier gibt es noch ein paar Details.
Na das passt ja mal wieder wie Arsch auf Eimer!
Mister "ich bin so genial, ich scheiße einmal auf alle etablierten Standards und erfinde alles neu"? Bei Microsoft? Chef's Kiss!
Mister "udev ist jetzt integraler Bestandteil von systemd und geht nicht mehr ohne" geht zu "Internet Explorer ist jetzt integraler Bestandteil von Windows"? Perfekt!
Mister Pulseaudio geht zur Firma mit DirectX!
Next up: systemd-registry und systemd-activedirectory!
Nun bin ich kein Freund von systemd, aber in diesem Fall haben die bloß eine dokumentierte Instruktion namens rdrand aufgerufen, um sich Zufallszahlen von der Hardware geben zu lassen. Dafür ist eigentlich eine Kernelabstraktion da, die systemd hätte verwenden sollen, dann wären sie jetzt nicht "Schuld" gewesen. /dev/urandom oder getentropy sind der bessere Weg.
Aber daraus, eine Instruktion aufzurufen, kann man ihnen keinen Strick drehen.
Das Problem ist schon länger bekannt und scheint irgendein Initialisierungsproblem bei Ryzen zu sein, wo irgendwelche Prozessor-Status-Flags nicht ordentlich gesetzt werden beim Booten. Das ist im Moment alles Spekulation, aber so sieht es aus, und wenn das stimmt, dann ist das mit einem Bios-Update zu reparieren. Da muss man sich aber schon fragen, wieso AMD ihre Validierung so verkackt. rdrand ist eine für eine Menge Sicherheits-Dinge absolut kritische Instruktion. Alle möglichen Krypto-Protokolle und -Verfahren brauchen Zufallszahlen. rdrand setzt ein Flag, ob es erfolgreich war, und liefert dann einen Wert. Bei AMD setzt es das Erfolg-Flag aber liefert immer alle Bits gesetzt zurück im "Zufallswert". Das ist der Worst fucking Case für diese Instruktion. Die meisten weniger guten Krypto-Implementationen werden keine Prüfung haben, ob der Zufall auch wirklich zufällig ist.
Der einzige Grund, wieso das nicht ein Total-Desaster ist gerade, ist dass eh niemand dem ursprünglichen Intel-rdrand vertraut hat, weil die NSA gerade ein Snowden-Vertrauensproblem hatte und der Zufallszahlengenerator der offensichtliche Geheimdienst-Angriffsvektor auf Open Source Kryptosysteme ist. Daher nimmt der Kernel das auch nur zusätzlich zu anderen Zufallsquellen in /dev/urandom. Hätte systemd also den Zufall vom Kernel bezogen, wäre alles gut gewesen. Auf der anderen Seite hätten wir dann vielleicht gar nicht von diesem Bug gehört. Insofern bin ich systemd doch dankbar. Und bin froh, dass meine Distro nicht auf systemd basiert :-)
To the best of our knowledge, all systemd-based Linux distributions are vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 are not exploitable because their user space is compiled with GCC's -fstack-clash-protection.
unprivileged users with UID > INT_MAX can successfully execute any systemctl commandSchuld ist aber anscheinend nicht systemd sondern polkit, von dem ich noch nie verstanden habe, wofür das eigentlich da ist. Diese Freedesktop-Geschichten haben echt durch die Bank eine furchtbare Codequalität. Das sollte man als Karantäne-Abklingbecken sehen, nicht als Code-Repository.
While the check at (A) tries to ensure that the buffer has enough space left to store the IA option, it does not take the additional 4 bytes from the DHCP6Option header into account (B). Due to this the memcpy at (C) can go out-of-bound and *buflen can underflow in (D) giving an attacker a very powerful and largely controlled OOB heap write starting at (E). (Danke, Ilja)
Hier ist, was ich dem letzten per Mail geschrieben habe:
Früher war es so, dass Freiwillige sich auf der Mailingliste gemeldet haben, und ihren Code geschickt haben. Linus hat ihnen erklärt, was sie noch nachbessern müssen, um reinzukommen, sie haben das gefixt, und wurden reingelassen. Alles gut.Redhat ist mehrfach negativ aufgefallen in der Richtung. Der Kay, um den es in der von mir verlinkten Mail ging, ist auch Redhat-Mitarbeiter. Aus dem systemd-Umfeld. Die haben sich echt massivst danebenbenommen, und als Linus sie nicht im Kernel brandschatzen ließ, haben sie seinen Kernel halt aus dem Userspace sabotiert.Manche kriegen Kritik an ihrem Code, nehmen das persönlich, und entdecken dann ihre anale Phase, pinkeln in die Ecke, machen laute Musik an, stören die anderen. Auf einer Mailingliste kann man da nicht wirklich viel gegen tun. Du kannst denjenigen runterschmeißen, klar, aber dann macht der sich ne neue Mailadresse und kommt wieder.
Später gab es dann Firmen wie Redhat, die haben Leute dafür bezahlt, dass sie Dinge tun. Und als ihnen auffiel, dass die Wartung von Software teurer ist als das Schreiben von Software, haben sie sich gedacht: Die Kosten externalisieren wir doch mal an die Community! Und sie haben ihren Scheiß auf die Mailinglisten gekippt. Linus hat das dann zurückgewiesen. Aber jetzt haben wir eine fundamental andere Ausgangsbasis. Wir haben Leute, die von ihrem Arbeitgeber dafür bezahlt werden, destruktive Dinge zu tun. Die haben dann (einige, nicht alle!) die Kritik einfach ignoriert. Genau so weitergemacht. Immer den selben Scheiß wieder eingereicht. Nach dem Motto: Wehr dich, solange du willst, ich werde hier bezahlt und sitze das aus. Weniger Arbeit für mich.
Und da gehen Linus irgendwann die Optionen aus. Was schlägst du vor, was er tun soll? Seine Strategie war, das dann über ein halbes Jahr oder so (guck selbst auf der Mailingliste! Nichttriviale Zeiträume!) den Ton zu verschärfen. War das die beste Strategie? Vermutlich nicht.
Aber es ist keinesfalls so, dass "der olle Linus halt mal wieder ausfällig wird". Das sind kumulierte Eskalationsstrategien, die das Ziel hatten, Redhat als Firma zum Einschreiten zu bringen. In einigen Fällen hat es auch funktioniert, übrigens.
Die Mails, die da zitiert wurden, sind jedenfalls nicht "Linus tickt halt aus". Das ist "Linus hat dir das jetzt ein fucking JAHR lang erklärt und du sabotierst hier immer noch das Projekt?!".
Update: Ich hatte das alles schonmal erklärt, sehe ich gerade.
Wenn euch das an das systemd-Problem vor einer Weile erinnert, insbesondere Microsofts "Lösung" für das Problem, dann seid ihr nicht alleine :-)
Update: War ein Repost.
Bonus: Einziger Betroffener ist systemd, der Bug wurde von Lennart Pöttering aufgemacht.
Ich finde gerade auf die Schnelle keine Quelle für die Behauptung, Usernamen unter Unix dürften nicht mit Ziffern beginnen. Ich halte das für eine Schutzbehauptung. Möglicherweise weil die shadow-utils den Bug auch haben.
An out-of-bounds write was discovered in systemd-resolved when handling
specially crafted DNS responses. A remote attacker could potentially
exploit this to cause a denial of service (daemon crash) or execute
arbitrary code. (CVE-2017-9445)Ach komm, was ist schon ein bisschen remote code execution unter Freunden!War systemd-resolved nicht auch das Tool, das, wenn kein DNS konfiguriert ist, einfach den öffentlichen DNS-Server von Google nimmt? Datenschutz, Schmatenschutz! Weil "der User ist doof" schonfür Windows so toll funktioniert hat!
Bonus: Pöttering so: Das ist doch gar kein Bug, rm -rf /foo/.* tut das doch auch so?
Spoiler: Nein, tut es nicht.
udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic that triggers an unsafe second checksum calculation during execution of a recv system call with the MSG_PEEK flag.Das klingt jetzt schlimmer als es ist, denn MSG_PEEK wird selten benutzt, UDP wird selten benutzt, und MSG_PEEK bei UDP wird noch seltener benutzt. Mir ist persönlich kein Fall bekannt.Ich habe dieses Flag in meiner Laufbahn 1-2 Mal benutzt. Man nimmt es, wenn man von einem Socket ein paar Bytes lesen will, ohne die zu lesen (d.h. wenn man danach nochmal read aufruft, kriegt man die Bytes wieder). Ich benutze das in gatling, um zu sehen, ob Daten auf einer SSL-Verbindung wirklich wie ein SSL-Handshake aussehen — allerdings auf einem TCP-Socket.
Kurz gesagt: Ich mache mir da jetzt keine großen Sorgen. Die DNS-Implementationen von glibc, dietlibc und djb benutzen jedenfalls nicht MSG_PEEK, und wenn es um UDP geht, ist DNS der übliche Verdächtige.
Ich will das nicht kleinreden, das ist ein ganz übler Bug und die sollten sich was schämen. Aber es ist kein "OMG die NSA hat mich gehackt, ich reinstalliere und mache alle Keys neu"-Bug. Außer ihr fahrt auf eurem Server irgendwelche UDP-basierten Protokolle.
Update: Im OpenVPN-Code findet grep auch kein MSG_PEEK. VPN und VoIP wären die anderen in Frage kommenden Codebasen.
Update: Ein paar Leser haben bei Debian und Gentoo mal ein bisschen rumgesucht und fanden als potentiell verwundbare Pakete dnsmasq und VNC-Implementationen. dnsmasq läuft praktische allen Plasteroutern. Das wäre in der Tat potentiell katastrophal.
Update: Einsender weisen darauf hin, dass systemd angeblich MSG_PEEK benutzt, und dass möglicherweise noch Chrome in Frage kommt als Angriffspunkt, wegen QUIC.
Welche ARM- (oder von mir aus auch MIPS oder PowerPC) Kleingeräte gibt es für wenig Geld zu kaufen, bei denen man dann einen Standard-Kernel selber bauen kann, und der funktioniert auch?
Das andere Gerät, bei dem ich in dieses Problem lief, ist ein Plasterouter, auf dem ich mal ein DD-WRT installieren wollte zum Testen, und da gab es nur eine Version von 2008 oder so, und neuere Kernel gehen nicht. Ja, äh, dann kann ich auch gleich Windows nehmen, wenn ich da keinen eigenen Kernel drauftun kann!
Ich empfinde es als zutiefst unseriös, ein Gerät als "da läuft Linux drauf" zu bewerben, auf dem dann nur ein spezifischer Gammelkernel läuft.
Auch auf Android-Smartphones scheint das ein massives Problem zu sein, wie ich aus zweiter Hand hörte. Sobald da mal was anbootet, ist das halt der Kernel für das Gerät und es wird nur noch das Userland außenrum geupdated, und vielleicht im krassen Notfall mal ein Security-Patch für den Kernel rückportiert.
Das kann doch nicht wahr sein? Ist das wirklich so?!
Update: Einsender empfehlen:
Ein anderer Einsender meint zu Allwinner noch:
ist dein RPI-Clone zufälligerweise ein Allwinner-Gerät? Das sind die beliebtesten China-SoCs. Sie sind ein wunderbares Beispiel für das Problem des "Code Vomittings". Die GPL zwingt Hersteller dazu, Code zu veröffentlichen? Wunderbar, erzeugen wir halt einen Code-Drop auf Github. Es gibt mit linux-sunxi.org eine Seite, auf der der Status für den Support im Upstream-Kernel sowie im eigenen "Fork" dokumentiert sein sollte. Die Situation ist nicht die beste, könnte aber schlimmer sein...
Update: Ein anderer Einsender meint:
the Allwinner ARM Chips do not belong on pole position. Too many critical missing features. A lot has changed in Kernel 4.11 but far from complete especially for the recent Allwinner ARM chips. too much red and WIP...
RaspberryPi is better supported and now also with mainline 64bit Kernel on RPi3.
https://michaelfranzl.com/2016/10/31/raspberry-pi-debian-stretch/
https://github.com/michaelfranzl/rpi23-gen-image
https://michaelfranzl.com/2017/03/21/zero-client-boot-kernel-root-filesystem-network-raspberry-pi2-pi3/
Das schöne an dem Gerät ist, dass man da auf relatig gut dokumentierte Art und Weise eine größere SSD einbauen und Linux parallel installieren kann, und dann hat man ein nahezu vollwertiges Linux-Netbook. Nachteil: Hat nur 2GB RAM, damit muss man halt klarkommen. Aber war in der Praxis nie ein Problem.
Ich dachte mir gerade, ich kauf da noch einen von, aber die sind wohl ausgelaufen und nur noch hie und da gebraucht verfügbar.
Hat zufällig jemand einen Überblick über die anderen aktuellen Chromebooks, ob es ein Modell mit ähnlichen Rahmenbedingungen gibt?
Das war so ein guter Kauf, dass ich mich rückblickend echt ärgere, nicht gleich zwei gekauft zu haben.
Ich hatte da übrigens zum Testen ein Arch-Linux draufgetan, um das mal irgendwo im Einsatz zu haben, und kann die Distro auch nur empfehlen. Ich fahre sie modifiziert, mit eigenem Kernel und ohne systemd, dafür mit minit. Aber so das Paketierungs- und Update-Konzept überzeugt mich bisher.
Update: OK also es stellt sich raus, dass das C720 Nachfolger-Modelle hat. Das C730 sollte man vermeiden, aber das aktuelle heißt C740 und ist vergleichbar. Das gibt es auch in einer 4GB-Variante, aber nicht in Europa. Überhaupt muss man sagen, dass die Chromebook-Auswahl in Europa nur so ein Drittel bis die Hälfte dessen ist, was man in den USA kriegen kann (nur halt mit US-Keyboard dann; manche stehen auf das US-Keyboard-Layout, ich habe lieber das DE-Layout, fürs Bloggen will ich Umlaute haben). Und dann die Preisunterschiede. Hier in den USA $149.99, hier in Deutschland 380 €. Was für eine Frechheit. Und dann wundern die sich immer, dass der Chromebook-Markt in Deutschland schwächelt.
Update: Jemand weist darauf hin, dass das 720 einen core-Prozessor hat, das 740 einen Atom. Vielleicht gibt es da verschiedene Modelle? Ich sah hier was von Celeron 3205U, und das ist ein Broadwell, kein Atom.
Update: Der eine Amazon-Vergleichslink geht offenbar zu dem falschen Produkt. Seufz.
Ihr werdet es euch schon gedacht haben: Ist gar kein Bug. Sowas geschieht nicht aus Versehen. Ist Absicht.
Wobei ich auch sagen muss, dass es sich hier um eine GNU-Extension in einer selten verwendeten Funktion handelt, und die ist obskur genug, dass ich noch nie von ihr gehört habe. Wenn ich schätzen müsste, wer sowas anwendet, würde ich vielleicht auf Bash tippen.
Update: Github findet fünfstellig Hits, und ein Leser schreibt, systemd benutzt das.
Nanu? Was ist denn da passiert? Hier kriegt man einen kleinen Einblick. Dieser Teilthread handelt davon, dass die Hauptbegründung (bei weitem nicht die einzige!) für kdbus ist, dass das alte dbus so ineffizient ist, und man da mal was tun muss, weil das so nicht weitergeht. Also hat Linus mal sehen wollen, und nachdem das nicht sofort klappte (Linus tappt da ganz wunderbar in die üblichen boah-ist-diese-ganze-gnome-kacke-furchtbar Buildprobleme, die sie immer versuchen, hinter configure und pkg-config zu verstecken, aber manchmal suppt es eben stinkend aus irgendeiner Ritze raus), lässt er mal einen Profiler laufen, um zu sehen, was da eigentlich so langsam ist. Und — es ist nicht der Kernelteil. Damit ist das "aber aber aber Performance"-Argument natürlich erstmal vom Tisch.
My guess is that pretty much the entirely of the quoted kdbus "speedup" isn't because it speeds up any kernel side thing, it's because it avoids the user-space crap in the dbus server.IOW, all the people who say that it's about avoiding context switches are probably just full of shit. It's not about context switches, it's about bad user-level code.
Oh, übrigens: Told you so!
Ich frage mich, ob Debian das mitkriegt, wenn ihnen die Nutzerzahlen wegbrechen.
Ich habe neulich ja aus Testgründen mal Arch Linux installiert und der hat mir auch erstmal ungebeten systemd installiert. Ich glaube, das wird bei Linux jetzt was die ganze Ad- und Bloatware bei Windows ist. Nach der Installation muss man erstmal den ganzen ungewollten Scheiß wegoperieren, den einem die Distro so auf die Platte spült. Sehr schade, dass wir die negativen Aspekte von Windows kopieren, bevor wir die positiven nachgemacht haben.
Update: Ich sollte vielleicht dazu sagen, dass ich mir wegen systemd nicht viel Sorgen mache. Demnächst ersetzen sie dann den Linux-Kernel und dann haben wir endlich wieder Ruhe. Kann sich nur noch um ein paar Wochen handeln. Und nächstes Jahr entwickelt systemd dann zu Bewusstsein und beantragt einen permanenten Sitz im Sicherheitsrat. DANN können wir uns wieder Sorgen machen.
Ich für meinen Teil kann systemd ja nicht ernst nehmen. Der soll mal wiederkommen, wenn er einen Mailserver eingebaut hat.