'Keine Shell Account' = Security-Aspekte ?

[Julian_G_Guenther_7b033a]

Hallo,

man kann ja problemlos einem Account keine Shell zuweisen wie z.B. /dev/null oder false. DAmit kann man von dem Account logischerweise keine Programme mehr von der Sehll ausführen. Allerdings durch „su“ etc über einen anderen Account schon…

Was passiert nun, wenn ich z.B. einen Webserver (nur als Bsp.) unter so einem Nicht-Shell-Account laufen lassen und dieser „gehackt“ wird. Sprich durch einen Buffer-Overflow verwundbar ist.

Normalerweise hat der Angreifer bei einem Buffer-Overflow ANgriff kompletten Zugriff auf den entsprechenden Benutzeraccount und kann Programm mit dieser Berechtigung ausführen.

Wie ist das aber, wenn der gehackte Account keine Shell hat, wie in diesem Bsp. Kann in diesem Falle der Angreifer nun eigenen Code ausführen oder nicht.??

(Was ist hier mit System(C-Bibliotheks)Aufrufen, „normalen Programmen“ und komplett eigenem Code des Angreifers ? Welche lassen sich wie ausführen…?)

Vielen Dank für Hilfe!

Julian

[Der_Frank_176821]

Hallo,

Hi,

man kann ja problemlos einem Account keine Shell zuweisen wie
z.B. /dev/null oder false.

Ich persoenlich wuerde /bin/false den Vorzug geben, da /dev/null i. A. ja keine ausfuehrbare Datei ist. Prinzipiell aber egal.

Was passiert nun, wenn ich z.B. einen Webserver (nur als Bsp.)
unter so einem Nicht-Shell-Account laufen lassen und dieser
„gehackt“ wird. Sprich durch einen Buffer-Overflow verwundbar
ist.

Normalerweise hat der Angreifer bei einem Buffer-Overflow
ANgriff kompletten Zugriff auf den entsprechenden
Benutzeraccount und kann Programm mit dieser Berechtigung
ausführen.

Er kann beliebigen code unter der uid des Nutzers laufen lassen. Was er damit anstellen kann, verwaltet der Kernel in Abgleich mit Dateiattributen o. ae.

Wie ist das aber, wenn der gehackte Account keine Shell hat,
wie in diesem Bsp. Kann in diesem Falle der Angreifer nun
eigenen Code ausführen oder nicht.??

Ja. Die in /etc/passwd vermerkte shell ist lediglich das Programm, welches von login gestartet wird, nachdem der Nutzer sich angemeldet hat. Dort keine shell anzugeben ist AFAIK mehr ein Schutz gegen versehentliches Einloggen. Ein feature fuer Sicherheit ist das keineswegs. Da hilft nur zeitnahes Einspielen von updates bzw. Verzicht auf chronisch kranke Programme.

(Was ist hier mit System(C-Bibliotheks)Aufrufen, „normalen
Programmen“ und komplett eigenem Code des Angreifers ? Welche
lassen sich wie ausführen…?)

Beliebigen code, also auch Aufrufe in die glibc oder anderen Bibliotheken. Aber immer nur unter der Nutzerkennung. Damit sollte er maximal Schaden an den fuer den exploited server zugaenglichen Dateien anstellen koennen. Und dafuer gibt’s ein backup.

Vielen Dank für Hilfe!

HTH,
Gruss vom Frank.

[Julian_G_Guenther_7b033a]

Thanks:wink:
Hallo Frank

vielen Dank für deinen Beitrag!
Hab einiges dazugelernt. Dachte eigentlich, dass das mit dem /dev/false schon „sehr sicher ist“ und kaum mehr was passieren kann. Dem scheint ja leider nicht so…

Aber über derartige Probleme bescheid zu wissen ist ja schonmal der beste Weg sie erfolgreich zu bekämpfen/zu verhindern. Vielen Dank!

Julian