Ansicht umschalten Baum an
Avatar von Freiheit wird in Hanf gemessen
  • Freiheit wird in Hanf gemessen

mehr als 1000 Beiträge seit 12.11.2004

Was der Heise-Autor uns (bewusst ?) verschweigt...

Punkt 1)
Ein Exploit ohne Benutzerinteraktion ist damit nicht machbar.

Warum?
Die suid-App 'writeconfig' ist mittels der Credential-Verwaltung des
Security-Framework an ein bestimmtes aufrufendes Programm gebunden,
eben an die Binary des GUI-Programms für die Systemeinstellungen.
D.h.: Aufrufe aus anderen Programmen heraus nimmt es nicht gerne
entgegen.
Und diese Systemeinstellungen selbst sind per Default *nicht
skriptfähig*.
(Es gibt zwar eine Möglichkeit, das "GUI-Skripting" freizuschalten,
aber das ist ein generelles Sicherheitsrisiko, das viel
weitreichender ist und auf das man hingewiesen wird.)
Um den Exploit zu nutzen, muss der Nutzer also per Maus ganz bewusst
auf ganz bestimmte Checkboxen in ganz bestimmten Bereichen der
Systemeinstellungen klicken. No other way.

Punkt 2)
Es liegt im Bereich des Möglichen, dass Benutzer es irgendwie seltsam
finden, wenn die Systemeinstellungen ohne ihr eigenes Zutun
aufpoppen.
Zugegeben, das ist kein echter Schutz, aber eine weitere Hürde auf
dem Weg zum Ziel für einen Angreifer.

Punkt 3)
Es handelt sich mal wieder um eine Art von Exploit, die nur für
Administratorkonten gefährlich ist. Normalbenutzer haben auf die
kritischen Einstellungen der System Preferences gar keinen Zugriff,
sie finden sie stets verschlossen und verriegelt vor.
Da hilft der Start mittels manipuliertem PATH einem Angreifer also
exakt gar nichts.

Punkt 4)
Es ist absolut falsch, dass man durch das explizite setzen des Pfades
für PATH im betreffenden Skript wirklich sicher sei. Dank eines
anderen Bugs in der (GNU) bash ist es möglich, dafür einen anderen
Bezeichner zu verwenden und somit auch diesen "Schutz" wirkungsvoll
auszuhebeln.
(Wie gesagt: 'GNU bash' - nicht 'Apple bash'. Jede Linux-Installation
hat den gleichen Fehler...ähem...)

Richtiges Vorgehen wäre vielmehr, das gesamte Skript durchzugehen und
jeden einzelnen Aufruf eines transienten Befehls durch einen
absoluten Pfad und den Aufruf über eine explizit geleerte Umgebung
(env -i command) von *jeglicher* Umgebungsvariable völlig unabhängig
zu machen.
Das aber dürfte weitere Probleme nach sich ziehen, die zu lösen doch
etwas mehr Tippaufwand erfordert als der Heise-Autor denkt. (Ich werd
mir das mal ganz in Ruhe reinziehen. Momentan hab ich keine Zeit
dafür.)

Punkt 5)
Ausgerechnet aus dem Heise-Verlag so eine hämische
"Anfänger"-Schelte?
Nun, dann sehen wir uns doch mal ein wenig auf dem Heise-ftp um und
sehen nach, wieviele Skripten es dort gibt, die im root-Kontext
laufen, undokumentiert sind und noch weitaus gefährlichere
Skriptsprachen nutzen als die Bourne-Shell.
Das ganze dem Leser dann verkauft als "Security"-Tool für dies und
jenes.
Räusper: "Wer im Glashaus sitzt..."
Unwürdig, sowas.

Bewerten - +
Ansicht umschalten Baum an
Anzeige