Veni, Vidi, VISA

Vim 7.3 Announcement. Was genau geändert wurde, kann man unter :h version-7.3 nachlesen.. mehr oder weniger.. eigentlich mehr weniger, weil es wieder mal keinen brauchbaren Changelog gibt *sigh*


Und eine Sicherheitslücke im Linuxkernel wurde geschlossen. Nach zwei Monaten. Und selbstverständlich ohne irgendeinen Hinweis darauf das es eine Sicherheitslücke war. Hey.. geht ja nur um das kleine Problem das lokale User root-Rechte erreichen können. Langsam wird es echt mal Zeit das jemand einen funktionierenden Fork von Linux rausbringt; allein schon deswegen damit ich nicht ständig *BSD anstelle von Linux installieren muss wenn es sich um sicherheitsrelevante Systeme dreht.

Das es Freiberufler gibt, die für das Ändern eines Passwortes (von root) 400€ verlangen kann man ja noch irgendwie unter "Größenwahn" abtun, aber wusstet ihr das es Firmen gibt die diesen Preis zahlen weil sie einen Admin haben der mit sowas überfordert ist?

Ja. Ich rede hier von einem einfachem init=/bin/sh, mount -n -o remount,rw /, .. auf einem Backupserver ohne verschlüsselte HD oder ähnlichem. Scheisse.. ich bin eindeutig unterbezahlt und sollte meinen Stundensatz auf einen dreistelligen Betrag erhöhen.

http://www.gulli.com/news/root-exploit-im-linux-kernel-entdeckt-2009-11-04
Dem Software-Entwickler Brad Spengler ist es gelungen, einen gefährlichen Bug in allen aktuell produktiv eingesetzten Versionen des Linux-Kernels zu finden. Dieser könnte normalen Benutzern erlauben, Root-Rechte zu erlangen.

Der sogenannte "Null Pointer Dereference Flaw" tritt in allen Versionen des Linux-Kernels bis zum aktuellen Release Candidate 2.6.32 auf. Dies bedeutet, dass praktisch jede produktiv eingesetzte Linux-Maschine verwundbar ist - denn wer setzt schon einen RC produktiv ein? Zwar gibt es eine Möglichkeit, die Ausnutzung der Schwachstelle zu verhindern (es muss das Feature "mmap_min_addr" benutzt werden). Dieses ist jedoch bei Red Hat Enterprise Linux (RHEL), einer populären Linux-Distribution für den professionellen Einsatz, offenbar fehlerhaft implementiert und bietet daher keinen Schutz. Auch zahlreiche Software-Entwickler-Tools sowie das auf Desktop-Systemen beliebte Tool Wine zur Ausführung von Windows-Programmen verhindern eine Nutzung des Features. Dieses ist daher auf zahlreichen Linux-Rechnern deaktiviert. So könnte die Anzahl verwundbarer Rechner beunruhigend hoch sein.

Spengler kritisiert nicht nur die Verantwortlichen von RHEL für ihre fehlerhafte Implementierung der Schutzfunktion (offenbar dem Wunsch nach mehr Kompatibilität geschuldet). Auch an den Entwicklern des Linux-Kernels und ihrem Umgang mit Sicherheitsthemen übt er Kritik. "Ich finde es interessant, dass ich [den Bug] zwei Wochen vor den Leuten gefunden habe, deren Job es ist, so ein Zeug zu finden," sagte er am gestrigen Dienstag, "Sie haben ganze Teams von Leuten und ich bin nur eine Person, die das in ihrer Freizeit macht." Dies ist nicht das erste Mal, dass Spengler die Linux-Kernel-Entwickler für Sicherheitslücken und auch für mangelnde Transparenz beim Bekanntgeben gestopfter Lücken kritisiert.

Quelle: The Register

Linux saugt immer mehr; kann das mal bitte jemand fork()'en oder die dafür zuständigen Leute erschlagen? Danke!

Es gibt drei Sorten von Admins: Die einen wissen was sie machen, die anderen wissen es nicht und lassen es von den Admins machen, die wissen was sie tun und dann gibts da noch die, die meinen sie wissen was sie machen und das auch tun obwohl sie keine Ahnung haben. Letztere legen dann auf einer Linux-Kiste ein SVN-Repo an, dessen Root unter / im Dateisystem zu finden, alle User read+write besitzen und eine gültige Loginshell via SSH zur Verfügung haben.
Der Witz an der Sache ist ja eigentlich das ich das grad durch Zufall entdeckt hab und gar nicht dafür bezahlt werde mich darum zu kümmern. Ich glaub ich sag dem Oberadmin später mal Bescheid.

Kaum empfehle ich mal Debian, schon taucht ein Exploit dafuer auf. Und was fuer ein gefaehrliches. Man muss nur jemandem der in der Gruppe utmp ist dazu bringen chgrp utmp /tmp/fillutmp; chmod 2755 /tmp/fillutmp und schon funktioniert es. Gefaehrlich das.. zumal per Default root der einzige User ist der die Gruppe fuer /tmp/fillutmp auf utmp aendern koennte.

So war die Frage nachdem einige Konfigurationsdateien unter /etc kaputtoptimiert bzw. geloescht wurden. Fuer die Frage gibt es eine Antwort; naemlich root. Allerdings stellt sich dann die Frage: Welcher?

grep -c 'x:0:0' /etc/passwd

19

Nein! Ich war das nicht!

hat er gesagt der selbsternannte "Ich halte bei Gelegenheit die Schulung bezueglich Sicherheit"-Uberh4x0r als ich ihm im Beisein seines Chefs einige Passwoerter im Klartext vorgelegt und sie dadurch auf die Problematik aufmerksam gemacht habe. Auf mein "Wer redet von den Sekretaerinnen? Die Passwoerter hab ich aus der Datenbank von Deinem Server, weil Du Dich staendig als root von Deiner Workstation aus ein-, aber nie ausloggst oder die Putty-Session beendest. hatte er abgesehen von einem hochrotem Kopf nichts mehr zu entgegnen; wobei der Grund fuer seinen Farbwechsel im Gesicht IMO die Blicke seines Chefs waren.
Ich liebe meinen Job. Ehrlich!

egrep -A1 '\<su\>' $HISTFILE Ich war wirklich erstaunt wie viele User es nicht erwarten konnten und schneller als die Verbindung via SSH war. Parallel dazu aber rumjammern, dass ein Host gecrackt wurde (Und ja. Die $HISTFILE war im $HOME fuer jeden lesbar!). Wieso darf man solche Typen nicht einfach erschlagen und aus dem Genpool der Menschheit entfernen?
Manchmal fuehle ich mich einfach nur noch muede..