Eine Verwundbarkeit in den OpenSSL-Paketen von Debian hat gravierende Auswirkungen. Diverse Schlüssel, die mit diesem Paket erstellt wurden, sind angreifbar.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0166

Auf unseren eigenen Systemen benutzen wir ausschließlich Gentoo Linux, insofern sind unsere Server-Keys nicht betroffen. Zur Sicherheit unsere Kunden haben wir alle SSL-Server-Zertifikate und alle SSH-Publickeys (in authorized_keys) überprüft.

Wir fanden keine unsicheren SSL-Zertifikate. Einige wenige SSH-Keys waren verwundbar, wir haben diese deaktiviert und die entsprechenden Nutzer informiert.

Ein gängiges Problem von geschützten https-Verbindungen ist, dass üblicherweise pro IP-Adresse nur ein Zertifikat vergeben werden kann. Daher ist es bei den meisten Shared-Hosting-Angeboten nicht möglich, https-Verbindungen korrekt zu nutzen, da das zugehörige Zertifikat nicht passend ist.

Hierfür existiert die SSL-Erweiterung SNI (Server Name Indication), welche auf unterschiedlichen virtuellen Hosts unterschiedliche Zertifikate ermöglicht. SNI wird bereits von den gängigen Browsern (Firefox, Opera, IE ab version 7) unterstützt. schokokeks.org bietet als einer der ersten Shared-Hosting-Provider seinen Kunden SNI an.

schokokeks.org selbst setzt für seine Seiten Zertifikate der freien Zertifizierungsstelle CAcert.org ein, jedoch können unabhängig davon auch eigene, extern gekaufte Zertifikate eingesetzt werden.

Einige Hintergrundinformationen über SNI haben wir in unserem Wiki bereitgestellt:
https://wiki.schokokeks.org/SNI

Heute früh ging die Meldung über alle einschlägigen Nachrichtenseiten: Ein lokaler Root-Exploit für den Linux-Kernel ist im Umlauf (heise-Meldung hierzu).

Leider gestaltete sich das Update für uns nicht ganz trivial. Wir setzen grsecurity ein, welches für 2.6.24 noch nicht zur Verfügung steht. Für 2.6.23 existiert ein grsecurity-patch, welcher jedoch auf Kernel 2.6.23.16 (wo o. g. Exploit gefixt ist) nicht funktioniert.

Nun läuft folgende Kombination:
- Linux 2.6.23.14
- grsecurity-Patch grsecurity-2.1.11-2.6.23.14-200801231800.patch
- Relevante Änderungen aus 2.6.23.15 in splice.c: splice1
- Relevante Änderungen aus 2.6.23.16 in splice.c: splice2

Wenn man sich von einem Rechner, den andere Personen kontrollieren können (Internet-Café, bei Fremden, ...) mit einem Passwort einloggen möchte, besteht immer die reale Gefahr, dass der Rechner das Passwort irgendwo protokolliert ("Keylogger") und damit andere Personen Zugriff auf das Passwort und damit den benutzten Account haben.

Um diesem Problem ohne zusätzliche Hardware zu begegnen gibt es eigentlich nur eine funktionierende Lösung: One-Time-Passwords bzw. Einmalpasswörter (kurz: OTP).

Ab sofort unterstützen wir Einmalpasswörter nach dem S/Key-Verfahren. Damit kann sich jeder Benutzer bei Bedarf den Zugang mittels Einmalpasswörtern ermöglichen. Mehr Informationen dazu in unserem Wiki.

Ein leidiges Problem mit https-Seiten ist, dass sie, zumindest bei Shared-Hosting-Umgebungen, meist mit falschen Zertifikaten ausgeliefert werden. Das Problem besteht darin, dass in der Vergangenheit eine IP lediglich ein Zertifikat ausliefern konnte.

Inzwischen gibt es eine Erweiterung des SSL/TLS-Standards mit dem Namen »Server Name Indication«, welche genau dieses Problem löst. Ab sofort bieten wir auf schokokeks.org an, dass Kunden über SNI eigene https/ssl-Zertifikate für ihre Domains nutzen können.

Clientseitig funktioniert dies bereits in den meisten Browsern. Firefox, Opera und IE unterstützen dies in der jeweils aktuellen Version, Konqueror wird ab KDE 4 dabei sein. Safari unterstützt im Moment SNI noch nicht.

Wir empfehlen weiterhin, Zertifikate von der freien Zertifizierungsstelle CAcert unterschreiben zu lassen, wir verteilen auch als Assurer Punkte für CAcert.

Nachdem wir kürzlich bereits unser greylisting-System als freie Software veröffentlicht haben, steht nun ein weiteres Tool zur Verfügung.

freewvs dient dem Zweck, Webanwendungen mit bekannten Sicherheitsproblemen ausfindig zu machen.

http://source.schokokeks.org/freewvs/

Ein bekanntes Problem mit über SSL ausgelieferten Webseiten ist, dass https pro IP-Adresse nur ein Zertifikat erlaubt. Das bedeutet, dass üblicherweise Domains, die in Shared-Hosting-Umgebungen betrieben werden, kein korrektes Zertifikat besitzen können, sofern Sie nicht eine eigene IP-Adresse beanspruchen.

schokokeks.org bietet seinen Kunden ab sofort die Möglichkeit, ihre Domains in einem Gemeinschaftszertifikat eintragen zu lassen. Hierfür bieten SSL-Zertifikate die Möglichkeit, mehrere Domains mit der Direktive SubjectAltName einzutragen. Wie bereits bekannt, lassen wir unsere Zertifikate von der freien Zertifizierungsstelle CAcert unterschreiben.

Die Lösung mit SubjectAltNames behebt das Problem zwar rudimentär, jedoch ist diese Lösung nicht sonderlich elegant. Für die Zukunft planen wir deshalb den Einsatz von SNI (Server Name Indication), welches mehrere SSL-Zertifikate auf einer IP vorsieht. SNI ist eine Erweiterung des SSL/TLS-Standards. Interessanterweise ist die Unterstützung von SNI in den meisten Client-Applikationen bereits vorhanden. Firefox, Opera und Internet Explorer sind bereits SNI-fähig, Konqueror wird mit KDE 4 diese Möglichkeit erhalten. Einzig Safari ist bei den großen Browsern noch außen vor.
Was uns davon abhält, SNI nicht jetzt schon einzusetzen, ist die Tatsache, dass openssl (und damit apache mit mod_ssl) dies erst mit Version 0.9.9 unterstützen wird - und wann diese erscheint, ist noch unklar. Alternativ wäre der Einsatz von gnutls mit mod_gnutls möglich, jedoch gilt dies noch nicht als stabil einsetzbar.

Unabhängig davon wäre natürlich langfristig eine Lösung mit IPv6 zu bevorzugen. Auch hier ist schokokeks.org bereits vorbereitet und bietet auf Anfrage eigene Zertifikate über IPv6 schon jetzt.

Die VhostTaskForce bei CAcert bietet einen Überblick über die angesprochenen Möglichkeiten der SSL-Zertifikate.

Gleich zwei kritischere Sicherheitslücken gab es heute zu vermelden: Zum einen vermeldet der Autor des Verschlüsselungstools GnuPG, Werner Koch, über ein von extern manipulierbaren Funtionszeiger. Sämtliche Systeme, die externe Eingaben mit GnuPG überprüfen oder entschlüsseln, sind damit gefährdet. Ein Update auf Version 1.4.6 ist verfügbar, für Version 2.0.1 steht ein Patch bereit.

Desweiteren untersuchte Hendrik Weimer verschiedene Virenscanner auf ihr Verhalten bei fehlerhaft BASE64-codierten Anhängen. Mehrere der untersuchten Scanner scheiterten hier, darunter auch ClamAV. Ein Patch findet sich hier im CVS des Projekts.

Beide Pakete wurden auf dem schokokeks.org Server bereits aktualisiert, für das letztere Problem bietet heise security einen Online-Check an: Eine harmlose Testdatei, die von allen Virenscannern erkannt wird (die EICAR-Testsignatur), wird entsprechend manipuliert versendet. Unsere Kunden, die ihre Mails mit ClamAV filtern, können dies gerne testen.

Vielleicht werden sich einige Leser schon einmal gefragt haben, warum bei Bedingungen in PHP sowohl die Syntax mit zwei als auch mit drei Gleichheitszeichen existiert. Nun, PHP kommt ja mit einem flexiblen Typsystem daher, was nichts anderes bedeutet, dass Variablen in PHP grundsätzlich nicht deklariert werden müssen und dass sie zudem »still« umgewandelt werden können. Diese stille Typumwandlung steht dem PHP-Entwickler auch in Bedingungen zu Verfügung. Sie bringt aber einige Probleme mit sich. Mit einer schlechten Abfrage ist der Entwickler nicht sicher, ob er es wirklich mit einem Integer oder gar mit einem Boolean zu tun hat, denn eine Bedingung kann für beide Typen im Zweifel wahr sein, wie wir weiter unten sehen werden. Dies sorgt für weniger Verlässlichkeit im Code und auch – im schlimmsten Fall – zu Sicherheitsproblemen.

Der Unterschied als Illustration. Hier eine Reihe von Bedingungen, die in PHP immer wahr sind:

1 == true
"beliebiger string" == true
1235 == false
1.12345 == true
0.987 == true

Hatten Sie angenommen, dass ein String automatisch wahr ist oder ein Float-Typ? Erklärt ist das schnell. Wandelt man mit PHPs Cast-Funktionen einen beliebigen String in einen Boolean, so ist dieser immer wahr, selbes gilt für Floats. Wandelt man die Zahl »1« in einen Boolean, so ist dieser auch wahr. Wandelt man eine Zahl die nicht »1« ist in einen Boolean, so ist der zurückgegebene Bool'sche Wert immer unwahr. Beispiel:

• (bool)1: ergibt »true«
• (bool)12345: ergibt »false«
• (bool)"beliebiger string": ergibt »true«
• (bool)1.2345: Ergibt immer »true«

Das Problem also: man kann sich nicht auf das doppelte Gleichheitszeichen verlassen. Die Lösung hierfür sieht ganz einfach aus: sobald man hier drei Gleichheitszeichen verwendet, versucht PHP intern nicht, die Typen zu konvertieren, sondern die beiden Variablen werden einfach nur miteinander verglichen, ohne PHPs krude automatische Magie. Das ist nicht nur ein Vorteil in punkto Verlässlichkeit, auch Geschwindigkeit wird dadurch gewonnen, denn jede Typenumwandlung kostet Resourcen und damit bares Geld. Die Syntax mit drei Gleichheitszeichen ist nicht nur weniger fehleranfällig, sondern auch noch schneller. Ein lohnenswertes kleines Zeichen mehr, würde ich sagen.