Archive for the ‘Security’ tag
SSLv3: Uralt, bröckelig, abschalten!
[EDIT] Tja, da schreibt man gerade drüber und ein paar Minuten später wird die Lücke veröffentlicht: Poodle . Details im Google Blog. Das Problem liegt im SSLv3 Protokoll selbst, es wird keine Patches geben, es muss ausgeschaltet werden. Eigentlich wäre nur uralt-Software wie der IE6 unter WindowsXP betroffen, aber durch Downgrade-Attacken die bei TLS möglich sind, sind alle betroffen und können auf das schwache SSLv3 downgegraded werden wenn es denn auf Server+Client unterstützt wird. Also abschalten!
Seit 2 Tagen gibt es Gerüchte über eine kritische Lücke in SSLv3. Aktuell (Mitternacht) ist noch nichts publik geworden außer ein eventuell interessanter Patch von Microsoft, und eine Falschmeldung eines OpenBSD-Patches, der in Wirklichkeit schon einige Monate alt ist.
Sicher ist dass SSLv3 18 Jahr alt ist, und vor 15 Jahren durch TLSv1.0 abgelöst wurde. Bei mail.de haben wir SSLv3 bereits vor einigen Monaten deaktiviert auf den Webseiten da kaum ein Client dieses alte Protokoll benutzte außer der IE6 auf WindowsXP Systemen. Da wir den IE6 eh schon lange nicht mehr unterstützen war es sehr einfach, SSLv3 abzuschalten.
Für die anderen Protokolle wie IMAP, POP3 und SMTP haben wir SSLv3 allerdings noch aktiviert gelassen da es noch diverse E-Mail-Clients gibt die TLS >1.0 noch nicht beherrschen. Auch einige ältere Smartphones beherrschen noch kein TLS1.0 oder neuer, sodass es Sinn machte es noch aktiviert zu lassen, denn es gab auch (noch) keine bekannten Angriffsvektoren.
SPDY Beta-Patch für nginx verfügbar: Ein erster Test
Endlich ist es soweit, mein favorisierter Webserver nginx erhält SPDY Support. Für Apache gibt es schon seit längerem ein SPDY-Modul das seit einigen Wochen als stabil gekennzeichnet ist. SPDY wird wahrscheinlich das neue HTTP 2.0, von Google entwickelt bietet es einige neue Features die das Web schneller und sicherer machen sollen. Unter anderem wird alles komprimiert (auch die Header), SSL ist zwingend vorgeschrieben und mittels Multiplexing können alle Resourcen über eine TCP-Verbindung geladen werden, und noch einiges mehr. Wer mehr über SPDY wissen will schaue sich am besten das Video von Google über SPDY an, es ist sehr empfehlenswert!
Sicherheitsupdate für PHP bei CGI-Verwendung
Gestern wurden neue Versionen für PHP 5.4 und 5.3 released, namendlich: 5.4.2 und 5.3.12. Grund für diese neuen Versionen ist eine gravierende Sicherheitslücke bei der Verwendung von PHP im CGI-Modus.
Aber erstmal Entwarnung: Wahrscheinlich nutzt ihr kein CGI mehr sondern FastCGI oder mod_php, dann seid ihr nicht gefährdet. Wer aber noch auf die alte CGI-Schnittstelle setzt sollte sich schleunigst informieren und updaten um schlimmeres zu vermeiden, denn dank dieser leicht auszunutzenden Lücke ist es jedermann möglich, die Quelltexte euer PHP-Dateien im Document-Root anzuschauen oder auch beliebigen eingeschleusten PHP-Code auszuführen.
Wer seine alte Installation nicht anfassen darf oder kann, für den gibt es Hilfe in Form einer Rewrite-Regel:
HashDoS Angriff legt (unter anderem) PHP lahm
Ich bin leider die letzten 2 Tage nur wenige Stunden dazu gekommen die Live-Streams vom 28. Chaos Communication Congress (28C3) zu schauen, aber bzgl. PHP ist heute Nachmittag ein interessanter Talk gehalten worden mit dem Thema Effective Denial of Service attacks against web application platforms dem ich hier einen kurzen Artikel widmen werde.
Es geht darum wie PHP (und die anderen anfälligen Sprachen auch) Hash-Tabellen erstellen und verwalten. Die hier interessante Hash-Tabelle ist das $_POST Array, das man von außen füllen kann, und das anfällig ist wenn man nur genügend „passende“ Datensätze reinfüllt. Der Algorithmus der die Hash-Tabelle befüllt wird nämlich langsamer sobald Kollisionen der Keys auftreten. Schickt man also beispielsweise 300KB POST-Daten an ein PHP-Script ist eine schnelle CPU damit ca. 30 Sekunden unter Volllast. Bei 8MB (dem Standard-Maximum für POST-Daten in der php.ini) wären es immerhin schon 5 Stunden, die die CPU benötigt um die Hash-Table zu füllen. Man kann also mit einer relativ kleinen DSL-Leitung einigen Schaden anrichten. Mit einer Gigabit-Leitung kann man so 10.000 CPU-Kerne dauerhaft beschäftigen.
Die Reporting-Funktion der Content-Security-Policy (CSP)
CSP hatte ich vor fast 2 Jahren bereits vorgestellt, mittlerweile hat es eine gute Verbreitung gefunden, sodass wir uns nochmals die Details anschauen. CSP ist ein Header, den der Server an den Browser schickt, und darin festlegt, von wo Javascripte, Bilder, CSS, Media-Dateien und mehr geladen werden dürfen. Mit sinnvollen Einstellungen ist es möglich, Cross Site Scripting (XSS) sowie Clickjacking zu verhindern, eine dieser essenziell wichtigen Einstellungen ist das Verbot von Inline-Javascript. Falls also ein Angreifer Javascript beispielsweise in die Datenbank einfügen kann, und bei der Ausgabe nicht oder falsch escaped wird, wird das Inline-Javascript das der Angreifer platziert hat nicht ausgeführt, XSS ist effektiv unterbunden.
In der Apache Konfiguration kann das beispielsweise so aussehen:
<VirtualHost *:80>
DocumentRoot /path/to/wwwroot
ServerName domain.de
Header add X-Content-Security-Policy "allow 'self'; img-src images.domain.de; script-src static.domain.de;"
</VirtualHost>
oder hier mittels PHP gesetzt:
<?php
header("X-Content-Security-Policy: allow 'self'; img-src images.domain.de; script-src static.domain.de;");
Sollten nun Bilder oder Javascripte eingebunden sein die nicht von den angegebenen Domains kommen wird der Browser sie blockieren und nicht laden. Es gibt neben img-src und script-src auch noch frame-src, xhr-src und weitere.
