Category Archives: Fedora

Update: Fedora OpenSSH Alarm: Nicht updaten auf 7.2p2-6 !

Posted on by

Wie gestern schon berichtet, ist die openssh Version 7.2p2-6 für Fedora defekt,

Wer keinen Zugang zu seiner Monitor Konsole hat und trotzdem das Downgrade einspielen muß, kann nun auf diesen Weg zurückgreifen:

Workaround V2.0: Downgrade auf 7.2p2-3

Über den Kojilink lädt man die drei Pakete runter:

Koji :  http://koji.fedoraproject.org/koji/buildinfo?buildID=756836

dann loggt man sich via defektem SSHD ein und  downgraded die Files für einen oneshot CronJob:

echo „59 16 * * * root /usr/bin/rpm -U –force /tmp/openssh*rpm > /tmp/log; rm -f /etc/cron.d/onetime“ > /etc/cron.d/onetime

Die Uhrzeit muß man natürlich an seine aktuelle Zeit anpassen 😉

Dann Ausloggen und nach der Zeit wieder einloggen. Der Befehl „rpm -qa | grep openssh“ sollte dann 7.2p2-3 anzeigen, welches die letzte funktionierende Version war.  Danach in /etc/dnf/dnf.conf einfügen:

exclude=openssh*

erst dann zieht das nächste Update nicht wieder die defekte Version auf den Server.

Das ganze klappt, weil der crond als „echter“ Root außerhalb der SSH Session läuft und nicht über sshd angetriggert wird.

Erste Hinweise zu den Ursachen des Problems

Wie im Bugtracker von RedHat einsehbar ist, kristallisieren sich grade Probleme mit der Chroot-Funktion vom SSHD heraus. Ist die Chroot aktiviert, was man tun sollte um Benutzer den Zugang zum System zu verweigern, so daß diese keine lokalen Angriffe fahren können, sondern in einer eigenen Umgebung arbeiten können. werden die für Root nötigen Capabilities nicht mehr gesetzt.

Capabilities sind die Eigenschaften eines Users, die erweiterte Rechte im Linuxsystem beinhalten, wie z.b. das Recht sich mit PTRACE in Prozessen einzuklinken, um diese zu belauschen oder zu verändern. Diese Capabilities machen Root erst aus und fehlen in der aktuellen sshd version:

# capsh --print
Current: =
Bounding set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=

Meine Vermutung: Da hat wer zuviel weggepatcht 😉

Fedora OpenSSH Alarm: Nicht updaten auf 7.2p2-6 !

Posted on by

Achtung: openssh-server version 7.2p2-6 ist defekt

Das heute von Fedora verteilte Update von openssh „7.2p2-6“ ist defekt. Wer per ssh auf einen Server mit dieser Version einloggt, sieht aus wie root, aber man ist nicht root. Man hat keine Root-Capabilities mehr, was z.b. darin gipfelt, daß man nicht mehr in sein eigenes Homeverzeichis wechseln kann.

Wer in seinem dnf.rpm.log das findet:

Oct 19 14:03:16 INFO Upgraded: openssh-7.2p2-6.fc23.i686
Oct 19 14:03:20 INFO Upgraded: openssh-server-7.2p2-6.fc23.i686
Oct 19 14:03:20 INFO Upgraded: openssh-clients-7.2p2-6.fc23.i686
Oct 19 14:03:20 INFO Cleanup: openssh-clients-7.2p2-3.fc23.i686
Oct 19 14:03:20 INFO Cleanup: openssh-server-7.2p2-3.fc23.i686
Oct 19 14:03:25 INFO Cleanup: openssh-7.2p2-3.fc23.i686

ist betroffen.

Aufgrund des Fehler kann man den Fehler auch  nicht via SSH beheben. Ihr könnt natürlich auf das nächste Fedora Update warten, daß dann offentlich einen Bugfix enthält, aber bis dahin habt Ihr im Notfall ein Problem.

Bei RedHat ist bereits ein Bugticket offen und man arbeitet an einem Fix. Scheinbar ist SELinux, bzw. dessen Abwesenheit daran beteiligt.

Workaround: Downgrade auf 7.2p2-3

Über den Kojilink lädt man die drei Paket runter:

Koji :  http://koji.fedoraproject.org/koji/buildinfo?buildID=756836

dann loggt man sich via MONITOR KONSOLE ein und downgraded die Files mit :

rpm -U –force openssh*rpm

danach in /etc/dnf/dnf.conf einfügen:

exclude=openssh*

erst dann zieht das nächste Update nicht wieder die defekte Version auf den Server.

 

ups … DNF deinstalliert und nu ?

Posted on by

Da will man ein harmloses Update einspielen und angeblich stört so eine Lib dabei. Naja, nichts besonders. Kommt öfters vor. Man deinstalliert das fragliche Programm und installiert es wieder: fertig.  Soweit in der Theorie.

„Götter irren sich nie – Root schon!“

Der Befehl : „dnf update –allowerasing“ sollte das eigentlich auch so gleich machen, wenn man Abhängigkeitsprobleme hat.
Vielleicht hätte er das auch, wenn man stattdessen nicht versucht hätte das Paket direkt zu löschen ( dnf erase packagename ). Den dabei unterlief mir ein Fehler bei der Blindbenutzung der Bash :

dnf erase dnf update –allowerasing

Und natürlich blind auf Ja gedrückt 🙂 Schon war DNF , YUM, YUMEX und ABRT verschwunden 🙁 Jetzt versucht mal ohne Paketmanager den Paketmanager DNF zu reinstallieren. Die Lösung ist natürlich relativ einfach: RPM direkt benutzen.

Jetzt ist natürlich nur die Frage: Woher nehmen ?

Die Frage hatte ich zum Glück schon mal in einem anderen Zusammenhang gestellt : Koji

Beispiel für HTTPD: http://koji.fedoraproject.org/koji/packageinfo?packageID=280

Koji ist eine Webseite des Fedoraprojekts, auf dem alle Builds für alle Fedoraversionen verfügbar sind. Dort können alte wie Betaversionen und natürlich die aktuellen Pakete gefunden werden. Einfach Downloaden und mit rpm installieren.

Wenn man die RPMS alle in einem Verzeichnis hat ist das ganz einfach: rpm -i *rpm

Sind alle Pakete mit Abhängigkeiten vorhanden, ist das Malheur in Minuten beseitigt. Allerdings muß man ganz schön viele Pakete runterladen, deswegen zuerst nur DNF und seine Abhängigkeiten installieren, dann per DNF alles, was bei dem Erase mit eliminiert wurde.

Wer eine Liste braucht :  grep Erased /var/log/dnf.rpm.log

Oct 18 00:37:20 INFO Erased: abrt-desktop-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-cli-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-addon-vmcore-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-gui-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-gui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-core-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-tui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: python3-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: python3-meh-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: yumex-3.0.17-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-utils-1.1.31-508.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-langpacks-0.4.5-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: dnf-plugin-system-upgrade-0.7.1-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: createrepo-0.10.3-3.fc21.noarch
Oct 18 00:37:22 INFO Erased: anaconda-yum-plugins-1:1.0-10.fc20.noarch
Oct 18 00:37:22 INFO Erased: abrt-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-addon-ccpp-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-gui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-pstoreoops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-tui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: yum-3.4.3-507.fc23.noarch
Oct 18 00:37:23 INFO Erased: dnf-yum-1.1.10-1.fc23.noarch
Oct 18 00:37:23 INFO Erased: abrt-addon-kerneloops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: gnome-abrt-1.2.2-3.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-retrace-client-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: libreport-python-2.6.4-2.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-xorg-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-plugin-bodhi-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: setroubleshoot-3.3.11-1.fc23.x86_64
Oct 18 00:37:24 INFO Erased: policycoreutils-devel-2.4-21.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-java-connector-1.1.0-6.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-dbus-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: libreport-python3-2.6.4-2.fc23.x86_64
Oct 18 00:37:24 INFO Erased: dnf-1.1.10-1.fc23.noarch

Natürlich kann man das jetzt mit etwas Bashmagie automatisch reinstallieren lassen. Kleiner Denkanstoß :

grep „Erased:“ /var/log/dnf.rpm.log | sed -e „s/^.*Erased:/dnf install -y/g“ | bash

Eine kleine Nacharbeit muß man dann aber noch tun: die Configfiles für YUM und DNF sollten restauriert werden, denn nach dem Install sind die wieder default. Zum Glück ist RPM clever und legt bei sowas eine Sicherungsdatei an:

-rw-r–r–. 1 root root 833 18. Okt 01:00 /etc/yum.conf
-rw-r–r–. 1 root root 833  3. Apr 2016  /etc/yum.conf.rpmsave

Und immer dran denken: bis auf  „dd if=/dev/zero of=/dev/sda1“ aka „format c:“ kann man alles unter Linux reparieren.