Tag Archives: Linux

Warnung: Libreswan kann Ihren Bootprozess stören – F29

Posted on by

Argss! Ja Argss! Da upgraded man 7800 Schritte lang seinen Desktop-PC auf ein Fedora 29, das auf den Servern ohne Probleme eingespielt werden konnte, auf dem Tablet und Laptop läuft, wo es exakt so per DNF eingespielt wurde, nur um dann festzustellen, daß das System nicht mehr bootet! Warum? Weil das Libreswan Paket wohl „defekt“ ist. ARGS!

Da tust Du alles um sicher zu sein und dann das!

Von dem Gedanken, das mein Desktop schnell mal eben auf ein neues Fedora hochgezogen werden kann, habe ich mich ja schon vor Jahren verabschiedet. Seit 0AD da drauf ist, dauert allein das  Herunterladen der Paket 25 Minuten und mehr, und 7800 Updateschritte brauchen auch mit SSD Support so um die 2 Stunden. Also schnappt man sich das Tablet, während der Desktop sein Upgrade fährt und macht was sinnvolles.. Kernel Updates einspielen z.B. 😉

Irgendwann war auch der Desktop durch und das obligatorische „reboot“ war fällig. Getan, gewartet, Festplattenpasswort eingetippt und …. tod.

Weil sich das schwer beschreiben läßt, hier der Bootlogauszug dazu:

Jun 14 19:13:06 meinpc systemd[1]: Started Restorecon maintaining path file context.
Jun 14 19:13:06 meinpc systemd[1]: Started LSB: Init script for live image..
Jun 14 19:13:06 meinpc systemd[1]: avahi-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-logind.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> Caught signal, shutting down...
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> ModemManager is shut down
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-machined.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: NetworkManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start RealtimeKit Scheduling Policy Service.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Accounts Service.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Modem Manager.
Jun 14 19:13:06 meinpc systemd[1]: Started NTP client/server.
Jun 14 19:13:06 meinpc systemd[1]: Started Hardware Monitoring Sensors.
Jun 14 19:13:06 meinpc systemd[1]: Starting SYSV: Late init script for live image....
Jun 14 19:13:06 meinpc systemd[1]: Starting ABRT Automated Bug Reporting Tool...
Jun 14 19:14:37 meinpc systemd[1]: Failed to get initial list of names: Connection timed out
Jun 14 19:14:37 meinpc systemd[1]: systemd-logind.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd[1]: Failed to start Login Service.
Jun 14 19:14:37 meinpc systemd[1]: systemd-machined.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Due to PID 1 having crashed coredump collection will now be turned off.
Jun 14 19:14:37 meinpc systemd[1]: Caught <ABRT>, dumped core as pid 1748.
Jun 14 19:14:37 meinpc systemd[1]: Freezing execution.
Jun 14 19:14:37 meinpc kernel: printk: systemd: 61 output lines suppressed due to ratelimiting
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Process 1748 (systemd) of user 0 dumped core.

Stack trace of thread 1748:
#0 0x00007fa4b3f9087b kill (libc.so.6)
#1 0x00005583475eeeda n/a (systemd)
#2 0x00007fa4b4133070 __restore_rt (libpthread.so.0)
#3 0x00007fa4b3f9057f raise (libc.so.6)
#4 0x00007fa4b3f7a895 abort (libc.so.6)
#5 0x00007fa4b3fd39c7 __libc_message (libc.so.6)
#6 0x00007fa4b3fda2cc malloc_printerr (libc.so.6)
#7 0x00007fa4b3fdbafc _int_free (libc.so.6)
#8 0x00007fa4b4066ac7 __vasprintf_chk (libc.so.6)
#9 0x00007fa4b43d0630 log_format_iovec (libsystemd-shared-239.so)
#10 0x00007fa4b43d0b09 log_struct_internal (libsystemd-shared-239.so)
#11 0x0000558347610a0f n/a (systemd)
#12 0x00005583476132cb n/a (systemd)
#13 0x000055834766368e n/a (systemd)
#14 0x000055834763fb3b n/a (systemd)
#15 0x00005583476436aa n/a (systemd)
#16 0x0000558347626eed n/a (systemd)
#17 0x00007fa4b4455f02 n/a (libsystemd-shared-239.so)
#18 0x00007fa4b4457da5 sd_event_dispatch (libsystemd-shared-239.so)
#19 0x00007fa4b4457f30 sd_event_run (libsystemd-shared-239.so)
#20 0x00005583476300f6 n/a (systemd)
#21 0x00005583475ea78b n/a (systemd)
#22 0x00007fa4b3f7c413 __libc_start_main (libc.so.6)
#23 0x00005583475ec41e n/a (systemd)

So, jetzt sitzt der User da und hat kein System mit dem er was machen könnte, weiß nicht, was da nicht ging und hat natürlich auch kein Backup gemacht, von dem der User jetzt eh nicht wüßte, wie er es in dem Zustand zurückspielen sollte 🙂

Was also machen ?

  1.  Resetknopf drücken, wenn alle Festplattenindikatoren aufgehört haben zu blinken.
  2.  Kernelbootmenü abwarten
  3.  „e“ drücken, und die Zeile „linux ……“ um “ 1 init=/bin/bash“ am Ende erweitern, ggf. noch „splash quite rghb“ entfernen,  damit man bei nächsten boot was sieht.
  4.  STRG+x drücken
  5.  Jede Menge Kernel Meldungen laufen über den Bildschirm, wenn die aufhören, RETURN drücken.
  6.  /etc/init.d/network start
  7.  mount / -o remount,rw
  8.  dnf update

Jetzt wird uns dnf erzählen, daß crypto-policies wegen libreswan-libs nicht installiert werden kann. Das löst man so auf:

dnf erase libreswan*

es fliegen runter :

NetworkManager-libreswan-gnome-1.2.10-1.fc29.x86_64
NetworkManager-libreswan-1.2.10-1.fc29.x86_64
libreswan-3.27-1.fc29.x86_64

und jetzt kann man mit dnf update auch das letzte Paket für einen aktuelles Fedora installieren und oh Wunder, der Rechner booted wieder. Bugreport filed!

Hinweis: Dieses Problem wird natürlich nur ausgelöst, wenn man libreswan auch mal irgendwann installiert hatte 😉

Bitte lesen Sie auch das Update dazu : Update: Fedora 29 bootet nicht nach Upgrade

Exim < 4.92 mit CVE-2019-10149

Posted on by

Jetzt muß ich es Euch doch erzählen, wo ich doch dachte, es dauert noch länger bis die Katze aus dem Sack ist. Ok, Exim < 4.92 hat eine schwerwiegende Sicherheitslücke, die man auch noch trivial ausnutzen kann: CVE-2019-10149

Um die Schwachstelle wurde viel Wirbel gemacht, dummerweise bekam bislang niemand die Zähne auseinander, ob man das auch ohne Update abwehren kann. Schauen wir uns mal an worum es überhaupt geht.

Was ist der triviale Exploit?

Es reicht, wenn man als lokaler Angreifer eine Email mit dem Sendmailersatz von Exim an „<${run{bash}}@zieldomain.de>“ sendet. Im Augenblick wo die zugestellt wird, wird der eingebettete Befehle (hier bash) als Root ausgeführt.

Das ganze kann man ggf. auch per Remote ausführen, so daß es eine richtig fiese Schwachstelle ist. Betroffen sind aber nur Versionen  > 4.87 < 4.92 . Dazu müssen aber diverse Dinge in der Config erlaubt sein, was in der Defaultkonfig nur teilweise der Fall ist. z.b. kann man keine „/“ in dem Befehl unterbringen, weil das unerlaubte Zeichen sind. Das schränkt den Angreifer natürlich stark sein.

Da selbst auf der Eximliste bis heute viel Geheimniskrämerrei im Spiel war, hier die ebenso triviale Gegenmaßnahmen:

Gegenmaßnamen

Einfach kein „$“ in Emailadressen erlauben 😀 Das war es. Da fiel mir nur ARGS zu ein 😀

Das hier kommt in Eure Exim Konfiguration rein, dann Exim neu starten:

acl_check_rcpt:

deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[\$@%!/|]

deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[\$@%!] : ^.*/\\.\\./

….

acl_check_mail:

…

drop message = Restricted characters in address
condition = ${if match{$sender_address}{\N.*\$.*run.*\N}{1}{0}}

# WICHTIG: Vor dieser Anweisung reinschreiben, sonst Essig!

accept hosts = +relay_from_hosts

…

Das würgt den Angreifer ab, bevor die Email zugestellt wird.

Die bessere Gegenmaßnahme wäre natürlich auf einen aktuelleren Exim umzusteigen. Aber wie das so ist, es gibt halt immer „Gründe“ warum und wieso was nicht aktualisiert werden kann.

Keiner bekommt die Zähne auseinander…

Was mich am allermeisten an der Lücke nervt ist, daß diese billige Gegenmaßnahme im Advisory von Qualys und in den Hinweisen vom Exim Team nicht vorkommen. Bei den Exim Leuten kann ich es noch verstehen, weil die den Bug selbstständig schon Anfang des Jahres gefixt hatten und halt mit Recht sagen können: Mach halt Updates.

Bei Qualyssieht anders aus, die schreiben :

As per the distros list policy:

Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.

We believe that it makes no sense to delay this any longer than that:
this vulnerability is trivially exploitable in the local and non-default
cases (attackers will have working exploits before that, public or not);
and in the default case, a remote attack takes a long time to succeed
(to the best of our knowledge).

Schön das Ihr den Exploit weggelassen habt, wie wär es mal mit dem Workaround, so das die guten Jungs einen kleinen Vorsprung haben?  Und dieser kryptische Hinweis „a remote attack takes a long time to succeed“ meint übrigens, das man seinen Exim mal alle 24h neu starten sollte, weil es da wohl irgend einen Scheiß mit „Teergruben“ gibt.

Das sind i.d.R. Spamfallen, die so langsam antworten, daß der Angriff des Angreifers einfach zäh wie in einer Teergrube abläuft, bis hin zu „gar nicht voran kommt“. So was in der Art nutzen die Angreifer hier aus. Daher einmal im Cron „killall -9 exim; systemctl restart exim“ per Cron: Fertig.

Linux: auf SD-Karten installieren, gut oder schlecht?

Posted on by

Einem kleinen Experiment gleich, habe ich am Samstag Fedora Linux auf einem i3 Surface Tablet auf einer SD-Karte installiert, da der Besitzer seine WIN-Installation nicht direkt zerstören wollte. Das hat an sich auch geklappt. Leider gab es da ein „kleines“ Problem …

Linux auf SD-Karten und USB-Sticks

Bleiben wir erstmal beim Surface, das normalerweise eine SSD, einen USB-Slot und einen SD-Kartenslot aufweist. Die Installation von Linux auf die SSD ist natürlich die favorisierte Installationsmethode. Jetzt kann man Linux aber auch auf die SD-Karte oder einen USB-Stick installieren und wenn man es nur mal ausprobieren will, ist das ein legitimes Vorgehen. Grub hat das Dualboot auch im ersten Versuch sauber hinbekommen, klasse!

Nun hatte der Besitzer des besagten i3 Surface Pro eine Installation auf die SD-Karte gewünscht. Den Hinweis, daß es auf einer SD Karte natürlich nicht so schnell gehen würde, wie auf einer SSD, hat er akzeptiert. Das Gerät verließ unseren LPD Stand dann auch mit einem aktuellen Fedora 29, RPMFusions MPV, Thunderbird und anderen Apps, was man halt so braucht, mit der Auflage Zuhause dann mal ein Update laufen zu lassen, weil das SD-bedingt ewig dauern würde. Natürlich war es am Mittwoch dann nicht aktualisiert, also haben wir das nachgeholt. Das hätten wir besser nicht gemacht 🙁

Das Update war 1 GB groß und der Download der RPMs noch das kleinste Problem. Die Energieeinstellungen von Gnome waren leider so eingestellt, daß das Gerät irgendwann ausgeht. Da das i3 Surface von 2013 vom aktuellen Kernel voll unterstützt wird, hätte das eigentlich kein Problem sein sollen, zumal ja gerade eh ein Update per DNF läuft. Da würde man annehmen, daß das Abschalten des Bildschirms nicht zu Problemen führt, weil ein Updateinhibitor gesetzt wird. Führte es aber!

Es kam wies kommen mußte…

Die Hardware vom Surface wurde offensichtlich nach einer gefühlten Ewigkeit komplett abgeschaltet und als wir das Tablet wieder aktiviert haben, meldeten die RPMs nur noch IO Fehler. Die Root-Partition sprang wegen eines IO Fehler in den Read-Only-Modus und war auch nicht dazu zu bewegen, daß Read-Write wohl die bessere Wahl während eines Updates wäre. Meine Vermutung: Die Hardwareabschaltung hat den SD-Cardreader wohl überrumpelt und der hat den Schreibschutz von der SD-Karte fälschlich als aktiv gemeldet. Da eine Installation auf einem Read-Only Filesystem nicht funktionieren kann, stoppe DNF dann auch irgendwann… so 200 Fehlermeldungen später 🙁

Ich habe das System schon im Nirvana gesehen und beim nötigen Reboot die Augen zugekniffen 🙂 Es bootete doch tatsächlich noch, was bei Update 650 von 1563 nicht wirklich zu erwarten gewesen ist. Nach dem obligatorischen manuellen Filesystemcheck kam Gnome tatsächlich hoch. DNF ist schlau, aber nicht schlau genug. Natürlich war die RPM Datenbank defekt und mußte repariert werden. DNF aktualisierte dann im Rucksack die restlichen Pakete, als der Besitzer per Fahrrad gen Heimat fuhr. Natürlich hatten wir gelernt und den Akku aufgefüllt und die Energiesparoptionen so angepaßt, daß das hoffentlich nicht nochmal passiert.

Der ganze Update wäre in 5 Minuten durch gewesen, wenn Linux auf der SSD installiert gewesen wäre. Der Besitzer sollte dann Zuhause noch dnf reinstall „*“ ausführen, ob das geklappt hat, erfahren wir dann nächsten Mittwoch.

Sind USB-Stick und SD-Karten wirklich eine gute Idee für Linux?

Nach dieser Erfahrung muß ich sagen : Nein, sind sie nicht. Man kann sich nie sicher sein, ob die Hardware das Speichermedium nach einem Sleep/Hibernate wieder sauber anbietet und das „laufende“ System weiter funktioniert. Ein Strom-Aus für den USB-Port oder den SD-Kartenleser kann halt zu Fehlern führen wie man sieht. Im Gegensatz zum IDE/SATA Port des Mainboards sind USB und SD eben nur untergeordnete Peripherie-Geräte. Da wird von den Kernel- und Treiberentwicklern auch nicht soooooo viel Ambition reingeflossen sein, wie in die Hauptgerätetreiber SATA/IDE/SCSI. Wenn dann noch eine eher exotische Hardware wie ein Surface Pro angesprochen wird, kann es zu dem Fehler kommen.

Dazu kommt, daß die SD-Karte echt lahmarschig war. Für die 650 Updates vergingen locker 2 Stunden. Der USB Port wäre vermutlich schneller gewesen, weil der schafft auch 1 Gb/s aka 120 MB/s. Also, wenn Ihr das vorhaben solltet, und ich rate dringend ab, nehmt einen schnellen USB-3-Stick.

Zum Glück hängt der Besitzer nicht soooooo an Win10, nach einer kleinen Datensicherung und Umpartitionierung von Windows, werden wir wohl auch Linux noch auf die SSD quetschen können. Das wird an sich eine spannende Sache, weil… wie wird Win10 auf den Verlust einer geliebten Partition reagieren? Auch das erfahren wir nächste Woche 😉