Re: externes USB DVD+-RW LW

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Thu, 6 Oct 2005 12:47:14 +0200 (CEST)

Oliver Lietz <de-bsd-questions(at)oliverlietz.de> wrote:
> Am Mittwoch, 5. Oktober 2005 12:02 schrieb Oliver Fromme:
> > Oliver Lietz <de-bsd-questions(at)oliverlietz.de> wrote:
> > > Am Dienstag, 4. Oktober 2005 08:56 schrieb Andreas Braukmann:
> > > > ich persoenlich wuerde zu diesem Zweck eine eigene Gruppe
> > > > verwenden. Mit der "operator"-Mitgliedschaft sind zu po-
> > > > tentiell zu grosse Privilegien verbunden (shutdown z.B. ;-))
> > >
> > > Ich denke, für eine private Workstation ist das so (noch) ok
> >
> > Sofern sie keinen Internet-Zugang hat.
>
> Für Internetnutzung lässt sich problemlos ein unterprivilegierter Benutzer
> extra anlegen. Das schränkt den Komfort weniger ein und der Sicherheitsgewinn
> ist größer.

Es ist kein Sicherheitsgewinn, sondern einen Sicherheits-
verlust, wenn man für einen bestimmten Zweck eine Grupe
mißbraucht, die gleich einen ganzen Hügel weitere Rechte
mit sich bringt, die völlig unnötig sind. Ob man für
Internetnutzung einen unterprivilegierten Benutzer anlegt,
ist unerheblich.

Da das Thema offenbar ein wenig auf die leichte Schulter
genommen wird, möchte ich es mal etwas ausführlicher er-
läutern.

Das Stichwort lautet »priviledge escalation«: Ein erfolg-
reicher Einbruch erfolgt häufig in vielen kleinen Schrit-
ten, von denen jeder allein »harmlos« erscheinen mag, aber
in der Summe führt es dazu, daß der Angreifer root-Rechte
erhält. Beispiel:

1. Durch eine Lücke in einem Netzwerkprogramm kann ein An-
greifer bestimmte Dateien lesen.
2. Dadurch findet er Informationen, die ihn zu einer ande-
ren Schwachstelle führen, durch die er Dateien uploaden
und als »nobody« ausführen kann.
3. Eine weitere Lücke ermöglicht es dann, Zugriff auf
einen Benutzer-Account zu erhalten.
4. Er findet einen Exploit, mit dem er die Zugriffsrechte
der Gruppe "operator" erhält.
5. Dadurch schließlich kann er sich root-Rechte verschaf-
fen.

Das war jetzt nur ein Beispiel; die Kette kann auch auf
ganz anderen Wegen verlaufen.

Der Schritt 1. ist häufig ganz einfach. Es genügt schon,
wenn ein Benutzer einen nicht ganz aktuellen Browser ver-
wendet, der eine oder mehrere hinlänglich bekannte Schwach-
stellen hat. Auch Schritt 3. ist sehr einfach, wenn z.B.
ein Benutzer ».« im $PATH hat (leider eine verbreitete Un-
sitte), aber es gibt auch andere Tricks. Schritt 5. ist
auch einfach, es gibt sogar viele Möglichkeiten, z.B. kann
man die Tatsache ausnutzen, daß die Grupper »operator«
Leserecht auf /dev/mem und /dev/kmem hat, oder auf die
ganzen Raw-Devices (und somit natürlich auch auf den Swap
und alle Dateisysteme).

Grundsätzlich kann man sagen: Wer operator-Rechte hat,
kann sich problemlos root-Rechte verschaffen.

Man sollte daher sehr vorsichtig mit der Vergabe von Rech-
ten sein. Ein scheinbar harmloser Schritt kann der ent-
scheidende Sprung für einen Agreifer sein.

Um auf das ursprüngliche Problem zurückzukommen: Was ist
eigentlich so schwierig daran, für den Brennerzugriff eine
eigene Gruppe anzulegen? Eine Zeile in /etc/group hinzu-
fügen, ein chgrp(1), fertig. Das ist ein »Aufwand«, den
man gern in Kauf nehmen sollte, wenn man dadurch es dadurch
verhindern kann, potentiellen Angreifern einen Schritt
zur Systemkontrolle zu ermöglichen.

> > > - für alle
> > > anderen Einsatzszenarien natürlich eher nicht.
> >
> > Also eigentlich für fast alle.
>
> Ähm, ja. Alle minus eins gleich fast alle. Passt.

Wieso eins? Ich kenne mehrere Rechner, die keine Verbin-
dung zum Internet haben. Aber im Vergleich zu allen ande-
ren ist das trotzdem eine verschwindend geringe Zahl,
daher »fast«.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"That's what I love about GUIs: They make simple tasks easier,
and complex tasks impossible."
        -- John William Chambless
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 06 Oct 2005 - 12:48:04 CEST

search this site