SSI exec bug

[Jens Nödler]

Hallo SELFcommunity,

vor rund einem Monat wurde bei heise.de über eine Sicherheitslücke auf www.tagesschau.de berichtet. http://www.heise.de/newsticker/data/ju-05.07.02-001/

Es ging dabei über den SSI exec-Befehl, der per Formular übergeben werden konnte und somit zur Ausführung kam. Das sollte aber doch nur möglich sein, wenn der Eingabestring aus dem Formular dazu verwendet wird eine HTML-Seite zu erzeugen, die anschließend noch durch den SSI-Parser wandert, oder?

Diese Lücke sollte nach meinen Überlegungen bei einem CGI-Script (zB Perl) nicht bestehen, dass die HTML-Seite direkt an den Browser sendent. Mache ich einen Denkfehler?

Wäre klasse, wenn ihr mir auf die Sprünge helfen könnte.

Gute N8.

[xwolf]

Hi,

SSI wird vom Server interpretiert, so aehnlich wie z.B. PHP, welches als Servermodul laeuft.
Damit jedoch eine Datei als SSI interpretiert wird, muss sie in der
Regel auch als solche definiert sein.
Im Apache z.B. durch

AddHandler server-parsed .shtml

Der Weg ist dabei:

Der User gibt einen Reuest an ein Dokument an den Webserver.
Dieser liesst die Datei und schaut nach den Typ der Datei. Wenn es
vom Typ server-parsed ist, wird der Server sie entsprechend bearbeiten.
Danach werden die AUsgaben an den Client weitergegeben, nachdem noch
Headerinfo hinzugetan wurden.
Das SSI kann noch ueber include's weitere Dateien und Skripten
einbinden. Bei diesen wird dasselbe dann gemacht und an der Stelle, wo das include war, eingebunden.

Bei einem CGI-Skript ist es etwas anders und etwas auch gleich.
Der Key ist: Ein CGI-Skript ist ein CGI-Skript und ein SSI-Dokument ist ebensolches.
Der AddHandler und die Options definieren jeweils nur eins von beiden.

Wenn nun ein CGI-Skript ausgefuehrt wird, wird dessen Ergebnis zwar an den Server gegeben, jedoch wird dieser diese Daten nicht nochmals parsen, weil es ja schon geparst wurde entsprechend des Dokumententypes. Und zwar als CGI.

ERgo wird der Webserver nur seinen Header hinzufuegen und dann die Ausgaben an den CLient leiten.

Alles etwas pi mal Daumen formuliert.

Ciao,
 Wolfgang

[Jens Nödler]

Hallo Wolfgang,

SSI wird vom Server interpretiert, so aehnlich wie z.B. PHP, welches als Servermodul laeuft.
Damit jedoch eine Datei als SSI interpretiert wird, muss sie in der
Regel auch als solche definiert sein.

Ja, soweit ist mir die Sache auch noch klar.

Doch wie kommt der exec-Befehl aus dem Eingabeform in eine .shtml-Datei, damit er Befehl zur Ausführung kommt?

Der User gibt einen Request an ein Dokument an den Webserver.
Dieser liesst die Datei und schaut nach den Typ der Datei. Wenn es
vom Typ server-parsed ist, wird der Server sie entsprechend bearbeiten.
Danach werden die AUsgaben an den Client weitergegeben, nachdem noch
Headerinfo hinzugetan wurden.
Das SSI kann noch ueber include's weitere Dateien und Skripten
einbinden. Bei diesen wird dasselbe dann gemacht und an der Stelle, wo das include war, eingebunden.

Klar.

Wenn nun ein CGI-Skript ausgefuehrt wird, wird dessen Ergebnis zwar an den Server gegeben, jedoch wird dieser diese Daten nicht nochmals parsen, weil es ja schon geparst wurde entsprechend des Dokumententypes. Und zwar als CGI.

Und entsprechend würde der Server evtl. enthaltene SSI-Befehle nicht interpretieren, oder?

Die einzige Möglichkeit über diesen Weg SSI-Befehle einzubauen dürfte folgende sein: Form mit SSI-Befehl -> CGI, CGI schreibt .shtml-Seite, CGI Redirect auf .shtml-Seite und dann die Interpretation von SSI. Doch das wäre extrem unüblich...

Schon mal vielen Dank für deine Hilfe.

[xwolf]

Hi,

SSI wird vom Server interpretiert, so aehnlich wie z.B. PHP, welches als Servermodul laeuft.
Damit jedoch eine Datei als SSI interpretiert wird, muss sie in der
Regel auch als solche definiert sein.

Ja, soweit ist mir die Sache auch noch klar.

Doch wie kommt der exec-Befehl aus dem Eingabeform in eine .shtml-Datei, damit er Befehl zur Ausführung kommt?

Erklaer ich unten. Du warst schon auf den richtigen Weg.

Wenn nun ein CGI-Skript ausgefuehrt wird, wird dessen Ergebnis zwar an den Server gegeben, jedoch wird dieser diese Daten nicht nochmals parsen, weil es ja schon geparst wurde entsprechend des Dokumententypes. Und zwar als CGI.

Und entsprechend würde der Server evtl. enthaltene SSI-Befehle nicht interpretieren, oder?

Genau.

Die einzige Möglichkeit über diesen Weg SSI-Befehle einzubauen dürfte folgende sein: Form mit SSI-Befehl -> CGI, CGI schreibt .shtml-Seite, CGI Redirect auf .shtml-Seite und dann die Interpretation von SSI. Doch das wäre extrem unüblich...

Genau so ist es.

Obs unueblich ist?

Leider nein.
Siehe zum Beispiel die alte Form des Boards von Matt Wright oder sehr viele Gaestebuecher. Bei diesen werden die EIntraege nicht dynamisch aus einer Datenbank generiert, sondern es wird eine HTML-Datei abgelegt.
Will dann der Betreiber ggf. ueber include virtuals irgendwelche festen Infos oder Werbebanner einbauen, macht er das vielleicht als SHTML.
Wenn dann das Gaestebuch kein HTML parst, weisst du was passiert.

Solche Skripten gibt es Haufenweise.

(Bei PHP ist das aber keineswegs sicherer. Auch dort gibt es solche
Skripten mit Tuecken und Tricks :)

Ein aktuelles Beispiel ist das eCard von der CSU/CDU (vgl: http://www.intern.de/news/3236.html, noch hier
im EInsatz:
http://www.stoiber.de/fs_pop.php?id=030101
http://www.zickensinddafuer.de/
http://www.krassgut.de/
http://www.wechselparty.de/
).
Dort ist es moeglich beliebigen HTML- und JavaScriptcode in eine Message einzugeben, die dann spaeter irgendwer mit entsprechender Unerfahrenheit lesen wird.

All diese Bugs werden unter "Cross-Site Scripting"-Bugs zusammengefasst. Wenn du in BugTraq mal danach suchst und das ganze ausdruckst, wirst du von Papiermassen erschlagen.

Ciao,
 Wolfgang

[Jens Nödler]

hi wolf,

Erklaer ich unten. Du warst schon auf den richtigen Weg.

Wenn nun ein CGI-Skript ausgefuehrt wird, wird dessen Ergebnis zwar an den Server gegeben, jedoch wird dieser diese Daten nicht nochmals parsen, weil es ja schon geparst wurde entsprechend des Dokumententypes. Und zwar als CGI.

Und entsprechend würde der Server evtl. enthaltene SSI-Befehle nicht interpretieren, oder?

Genau.

Die einzige Möglichkeit über diesen Weg SSI-Befehle einzubauen dürfte folgende sein: Form mit SSI-Befehl -> CGI, CGI schreibt .shtml-Seite, CGI Redirect auf .shtml-Seite und dann die Interpretation von SSI. Doch das wäre extrem unüblich...

Genau so ist es.

Obs unueblich ist?

Leider nein.
Siehe zum Beispiel die alte Form des Boards von Matt Wright oder sehr viele Gaestebuecher. Bei diesen werden die EIntraege nicht dynamisch aus einer Datenbank generiert, sondern es wird eine HTML-Datei abgelegt.
Will dann der Betreiber ggf. ueber include virtuals irgendwelche festen Infos oder Werbebanner einbauen, macht er das vielleicht als SHTML.
Wenn dann das Gaestebuch kein HTML parst, weisst du was passiert.

Solche Skripten gibt es Haufenweise.

Danke für die ausführlich Erklärung. Dann werde ich mich jetzt mal unter einem Haufen BugTraqAusdrucke begraben. ;-)

ciao
der http://noedler.de