Security fail pt3: Userauthentifizierung über externe Kommandos
Tim schlug hier vor, im Vorpost etwas anderes zur Authentifizierung als $USER zu nutzen: id. Auch das ist unsicher, wenn man es falsch macht. Ich benutze hier einfach mal die UIDs statt der Usernamen. Der folgende Code wäre dann die id-Variante, wer findet das Sicherheitsproblem? 
#!/bin/bash
if [ "$(id -u)" != "1001" ] && [ "$(id -u)" != "1002" ]
then
echo "Zugriff verweigert."
else
echo OK
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Umgehen kann man es jedoch wieder trivial, man erstelle ~/id:
[stefan@srv2342 ~]$ sh authme.sh
Zugriff verweigert.
[stefan@srv2342 ~]$ echo "echo 1001" > ~/id
[stefan@srv2342 ~]$ chmod +x ~/id
[stefan@srv2342 ~]$ PATH=".:$PATH" sh authme.sh
OK
[stefan@srv2342 ~]$
Wir haben hier PATH so geändert, dass zuerst im aktuellen Pfad nach id Datei gesucht wird – die Datei haben wir grade angelegt und sie gibt aus, was das Script als Antwort sehen möchte. Whoops! ;D
raf
dann bliebe wohl nur noch eine abfrage:
ID_BIN=”
if [ -x /bin/id ]; then
ID_BIN=/bin/id
else
if [ -x /usr/bin/id]; then
ID_BIN=/usr/bin/id
fi
fi
if [ -z "$ID_BIN" ]; then
echo “unable to authenticate”
exit 1
fi
raf
jetzt noch mit netten xhtml-tags
dann bliebe wohl nur noch eine abfrage:
ID_BIN=”
if [ -x /bin/id ]; then
ID_BIN=/bin/id
else
if [ -x /usr/bin/id]; then
ID_BIN=/usr/bin/id
fi
fi
if [ -z "$ID_BIN" ]; then
echo “unable to authenticate”
exit 1
fi
Daniel
Was hindert den potentiellen Angreifer daran, die Befehle aus dem Hochsicherheitsscript einfach direkt aufzurufen?
stefan
In dem Fall: eine restriktive Shell. Leider kann ich hier nicht alle Details preisgeben und den Originalcode posten.
Dirk Deimeke
Kommandos in sicherheitsrelevanten Skripten sollten auch nur mit dem kompletten Pfad aufgerufen werden.
Habt Ihr eigentlich etwas gegen “case .. esac”-Anweisungen?
case $(/usr/bin/id -u) of
1001|1002) Mach das richtige. ;;
*) Du bist falsch hier ;;
esac