Diese Woche im Netz

Freie Software kann teuer werden, bis zu 17.500 € für eine Workstation mit freien Cpu’s und freier Software.

Quelle: golem.de

Julian Assange wurde vom Netz getrennt 🙂

Quelle: The Hacker News

Der Hacker für den LinkedIn Hack 2012 wurd jetzt in Prag verhaftet.

Quelle: The Hacker News

US Regierung scannt die Führerscheindatenbankbilder ein. Wer hätte das gedacht 😉

Quelle: The Hacker News

In Indien sind 3,2 Millionen Bank- und Kreditkartendaten erbeutet worden.

Quelle: The Hacker News

Raubkopierender YouTube Star, „kauft“ sich von seinen Sünden frei 🙂

Quelle: Torrent Freak

43 Millionen Kundendatensätze beim Webseitendienste Weebly „abhanden gekommen“.

Quelle: heise.de

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

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 😉