Block > Shellshock

Dank Shellshock haben wir nun auf dem Server die FastCGI-Skripte, die ich fuer Rezepte, Urlaube und die Tagcloud genutzt habe, entfernt.
Der Grund dafuer sollte klar sein, FastCGI nutzt z.B. die bash und sollte damit nun eher nicht mehr verwendet werden.
Auch der Wechsel zu sh bringt da nicht viel, ist z.B. die sh unter Arch Linux nur ein Symlink zu /bin/bash ...

Update (2014-10-12): Meillo hat mich fuer die obigen Zeilen kritisiert - und das zu Recht. Daher fange ich mal neu an:

Grund fuer die Abschaltung sind die bekannt gewordenen Luecken in Bash, auch bekannt als Shellshock. Da die FastCGI-Skripte Bash-Skripte waren, waren die damit auch eine Sicherheitsluecke.
Da ich ehrlich gesagt zu faul war, die Skripte abzusichern haben wir uns der Einfachheit entschlossen, (Fast-)CGI nicht mehr zu benutzen.
Und eigentlich wars das auch schon.
Ueber den Einsatz von CGI kann gestritten werden: es ist zwar einfach, aber eben auch fehleranfaellig, gerade weil der komplette Request vom Client teils ohne Ueberpruefung an den Interpreter bzw. Kernel weitergegeben wird (wenn ich das richtig verstanden habe).
Und ein "Wechsel" zur /bin/sh ist laut Meillo auch nicht so sinnvoll, da es ja nur ein Vorgaenger von bash ist. Sinnvoller waere ein Wechsel zu einer ash-Variante, z.B. dash

D.h. von nun an ist alles statisch, selbst die Tagcloud ...
Aenderungen gibt es lediglich bei der URL, aber es gibt ja Redirects ;)

Shellshock

Fuer alle, die keinen Server besitzen, ist Shellshock nicht soo dramatisch, allerdings schadet es auch auf privaten Rechnern nicht, dagegen immun zu sein.

Ob der eigene Rechner anfaellig fuer Shellshock ist, kann z.B. ueber dieses Skript herausgefunden werden.
Oder schneller/einfacher (Skript vorher lesen/verstehen!):

wget -O bashcheck https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck && chmod +x ./bashcheck && ./bashcheck

Update (2014-10-12): Meillo merkte ebenfalls an, dass der obige Befehl natuerlich super unsicher ist, wenn nicht vorher das Skript gelesen/verstanden wurde.
Ich habe es benutzt, weil es mehr testet, als der Einzeiler, der die eigentliche Luecke identifiziert:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Redirects mit Lighttpd

Speziell in meinem Fall wollte ich alle .fcgi-Dateien zu den nun statischen Seiten weiterleiten, und auch insbesondere alles hinter dem Parameter q.
Also z.B.:

//yhaupenthal.org/tagcloud.fcgi?q=vegan => //yhaupenthal.org/tagcloud_vegan.htm

Letztendlich reichen dafuer folgende drei Zeilen (mit HTTP Status Code 302) (Quelle):

url.redirect = ( "^/(tagcloud|holidays|recipes).fcgi$" => "/$1.htm",
                 "^/(tagcloud|holidays|recipes).fcgi\?q=(.*)$" => "/$1_$2.htm" )
url.redirect-code = 302

Geschrieben: 2014-10-04, 15:09 - Tags: ich, neu