Probleme mit GnuTLS

Seit einigen Wochen versuche ich verzweifelt GnuTLS genau so zum Laufen zu bekommen wie mod_ssl, doch bisher ist mir nur der Standard gelungen, dass HTTPS sauber funktioniert. Doch was ich eigentlich erreichen möchte, dass ich eine Client-Authentifizierung mittels Zertifikat und mod_gnutls erreiche, ist mir bisher immer noch nicht gelungen. Bisher trete ich auf der Stelle rum, und das Importierte Client-Zertifikat kommt anscheinend nicht mal bei Webserver an, daher habe ich mich nun an Personen gewandt, die hoffentlich mehr Ahnung zu dem Thema haben:

debianforum.de: GnuTLS und Client-Authentifizierung mittels Zertifikat

Aktuell kann ich nur über mod_gnutls sagen, dass ganz simplen Standards gesicherter Verbindungen bereitstellen kann, aber für erweitere Optionen, welche mit mod_ssl ohne große Probleme funktionierten, findet man bei mod_gnutls kaum Quellen zu. Also aktuell wäre ich schon froh eine saubere Anleitung für GnuTLS zu finden, welche sich auch mit diesen Thema auseinander setzt.

So lange muss wohl eine reine Passwort-Authentifizierung reichen mit langen Passwort, sonst muss ich mir was neues einfallen lassen.

PHP Extention: Wann MySQLi statt MySQL benutzen?

Beim Starten eines Projektes oder bei Verwendung einer fertigen Webapplikation, welche/s auf PHP basiert, kommt man unweigerlich oftmals zu der Frage: Soll ich die MySQLi- oder MySQL-Bibliothek von PHP nutzen.

Die Frage lässt sich heute in 99,9% der Fälle mit MySQLi beantworten. Ausnahmen hierbei sollte es eigentlich nur sehr wenige geben. Eine Ausnahme könnte sein, dass man ein Module für eine Applikation schreibt, welche immer noch die MySQL-Erweiterung nutzt, nur dann stellt sich auch die Frage, ob diese Applikation noch genutzt werden sollte. Alternativ zu MySQLi lässt sich natürlich auch der Datenbankabstraktion-Layer PDO verwenden.
Wieso gerade MySQL nicht mehr verwendet werden soll, ist recht simple. MySQL wird nicht mehr wirklich gewartet, es werden nur noch die nötigsten Dinge erledigt (kritische Sicherheitsupdates), und ab PHP 6 wird es auch nicht mehr unterstützt werden, das heißt lieber jetzt umstellen, um später weniger Arbeit mit der Umstellung zu haben. Als Plus gibt es bei MySQLi zudem noch eine komplett Unterstützung von MySQL 4.1+.

Als kleine Übersicht nochmal die Tabelle von php.de zu diesen Thema ergänzt mit den bisherigen Informationen zu PHP 6:

Funktion MySQLi PDO MySQL
SSL-Verbindung
Eingeführt in PHP Version 5.0 5.0 3.0 und früher
In PHP 5.x verfügbar Ja Ja Ja
In PHP 6.0 verfügbar Ja Ja Nein
MySQL Entwicklungsstatus aktive Entwicklung aktive Entwicklung (as of PHP 5.3) nur Wartung
Empfehlung von MySQL für neue Projekte Ja – vorzugsweise Ja Nein
API Unterstützt Zeichensätze Ja Ja Nein
API Unterstützt serverseitige Prepared Statements Ja Ja Nein
API Unterstützt clientseitige Prepared Statements Nein Ja Nein
API Unterstützt Stored Procedures Ja Ja Nein
API Unterstützt Multiple Statements Ja weitestgehend Nein
Unterstützt alle MySQL 4.1+ Funktionen Ja weitestgehend Nein

Schwachstelle CA/SSL-Zertifikat?

Die gewollte Designschwäche von HTTPS-Verbindungen sollte nicht ignoriert werden. Sie kann wohl nicht als direkte Schwäche von SSL und SSL-Zertifikaten selbst betrachtet werden, doch durch die schiere Anzahl von CAs können wir uns nie ganz sicher sein, dass nicht ggf. doch jemand mithört.

Durch den kurzen veröffentlichen Blogbeitrag von Matt Blaze, habe ich nochmal kurz über die Sicherheit von SSL nachgedacht, und habe es einfach mal selber mit gesponnen. Selbst wenn nun eine Sachen fiktiv sind, so sind sie nicht komplett abwegig.

Ok, es hört sich für den Einen oder Anderen abwegig an, dass jemand eine Man-In-The-Middle-Attacke machen kann, wenn eine Website (o.ä.) mittels SSL-Zertifikat gesichert wird. Trotzdem ist es denkbar, wenn die angreifende Person Zugriff auf ein verbreitetes CA-Zertifikat hat. Immerhin müssen wir uns hier vor Augen führen, dass viele CA-Zertifikate bereits standardmäßig mit dem Betriebssystem oder Browser ausgeliefert werden. Und genau das kann der Knackpunkt sein.
So haben einige Open-Source-Distributionen bspw. CAcert als CA-Zertifikat hinzugefügt, bei welcher durchaus Missbrauch möglich ist. Aber auch wissen wir nicht, wie die kommerziellen Anbieter mit ihren CAs umgehen, ob nicht ggf. sogar den Geheimdiensten im entsprechenden Land Zugriff auf die CA gewährt wird, so dass beliebige SSL-Zertifikate ausstellt werden könnten, oder es selber missbrauchen, kann wohl keiner so einfach widerlegen (oder beweisen). Auch gibt es immer wieder Firmen, die sogenannte kostenlose SSL-Zertifikate anbieten. StartCom, eine israelische Firma, ist eine solche CA, dessen kostenlose Zertifikate werden nur mittels E-Mail validiert. Das CA-Zertifikat von StartCom ist auch entsprechend verbreitet, so dass es schnell in einen Browser zur Verfügung steht. Ich selber habe bei der letzten Neuinstallation es noch händisch entfernt.

Daher sollte wohl immer im Hinterkopf gehalten werden, SSL-Zertifikate sollen zur Absicherung des Datenverkehrs dienen, daher ist es sehr ratsam, diese zu verwenden. Doch muss hier auch sensibilisiert werden, dass nicht jeder CA vertraut werden sollte, und das jeder selber dafür Verantwortlich ist, bedenkliche Zertifikate zu löschen, welche ggf. durch Betriebssystem oder Browser mitgeliefert werden. Selbst dann bleibt immer noch das übliche Restrisiko.
Wer also sehr sicher gehen möchte beim Datentransfer, legt seine eigene CA an, verbreitet Sie auf seine Clients und wirft danach alle anderen CAs raus.

Apache Sicherheit bei Verwendung von PHP

Sicherheit in Webanwendungen ist immer ein großes Thema, dazu gehört auch die sichere Einbindung des PHP-Modules in den Apache httpd Webserver. In diesen Artikel behandele ich kurz, wie PHP in den Apache eingebunden wird und nur von Dateien mit der Endung .php oder .php5 ausgeführt wird, und weshalb hier eine Sicherheitslücke lauern kann.

Wieder mal ist ein sogenanntes Future vom Apache Httpd Auslöser eines Exploits, diesmal bei WordPress.

Grundlegend kann man sich nun Fragen, liegt der Fehler nun beim Apache Httpd, bei WordPress oder beim Administrator des Apache Httpds? Nun, bei gesamter Betrachtung hat jeder etwas Schuld, aber das tut nichts zu Rolle. Interessanter ist es, wie ich als Administrator eines Apache Httpds nicht Opfer dieses Exploits geworden wäre, bzw. der Exploit keine Auswirkungen auf mein System hat.

Um zu verstehen, was hier passiert ist, eine kurze Erklärung des Exploits. Hier entsteht eine Lücke durch ein Future vom Apache Httpd, welche vom WordPress nicht abgefangen wurde. Dieses Future greift vornehmlich bei mehrfachen Dateiendung (bspw. archive.tar.gz oder image.php.jpg), es arbeitet den Dateinamen von rechts nach links ab, um einen diese einen entsprechenden Dateityp zu zuordnen. Wenn bei nun die für die Endung .jpg kein Dateityp im Apache httpd hinterlegt ist, nimmt er sich die nächste Stelle, was bei einer Datei mit den Namen image.php.jpg, die Endung .php wäre. Somit wird die Datei den Typ PHP zugeordnet und wird durch den PHP Parser geschickt und ausgeführt.

[…]
Files with Multiple Extensions

Files can have more than one extension, and the order of the extensions is normally irrelevant. For example, if the file welcome.html.fr maps onto content type text/html and language French then the file welcome.fr.html will map onto exactly the same information. If more than one extension is given that maps onto the same type of meta-information, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html.

Languages and content encodings are treated accumulative, because one can assign more than one language or encoding to a particular resource. For example, the file welcome.html.en.de will be delivered with Content-Language: en, de and Content-Type: text/html.

Care should be taken when a file with multiple extensions gets associated with both a MIME-type and a handler. This will usually result in the request being handled by the module associated with the handler. For example, if the .imap extension is mapped to the handler imap-file (from mod_imagemap) and the .html extension is mapped to the MIME-type text/html, then the file world.imap.html will be associated with both the imap-file handler and text/html MIME-type. When it is processed, the imap-file handler will be used, and so it will be treated as a mod_imagemap imagemap file.

[…]

Quelle: http://httpd.apache.org/docs/2.2/mod/mod_mime.html

Also was sollte man als Administrator eines Apache Httpds machen?

Nun, erstmal sollte dafür gesorgt werden, dass Dateien nur durch den PHP Parser gelangen, wenn die Dateiendung auch wirklich den Abschluss der Datei bildet. Bei Debian Lenny kann dies wie folgt erreicht werden:

/etc/apache2/mods-enabled/php5.conf

<IfModule mod_php5.c>
  AddType text/plain .php .phtml .php3 .php4 .php5
  <FilesMatch "\.php5?$">
    AddType application/x-httpd-php .php .php5
    AddType application/x-httpd-php-source .phps
    SetHandler application/x-httpd-php
  </FilesMatch>
</IfModule>

Damit hätte man als Administrator eines Apache Httpds schon mal sorgfältiger gehandelt und der beschriebene Exploit wäre gar nicht möglich gewesen. Trotz allen müssen PHP-Anwendung, wie WordPress, umsichtig genug entwickelt werden, dass der Exploit gar nicht erst vorhanden ist.

Hinweis: Falls nun jemand meint, der SetHandler würde reichen, der irrt, zu mindestens bei Debian Lenny wird es nicht funktionieren, erst mit den oben gezeigten Beispiel arbeitet der Apache 2.2 zuverlässig, so wie es gewollt ist.

Virenattacke der anderen Art, oder wieso ich meinen Rechner trotzdem absichern sollte

Immer wieder darf ich mir von Personen anhören, die nicht ein Deut vom Fach sind: “Was kümmert es mich, wenn mein Rechner gehackt wird? Da ist eh nichts wichtiges drauf und ich habe auch keine persönlichen Daten darauf.”
Doch was ist es, wenn man genau wegen einer solchen Attacke oder durch einen Virus eine ordentliche Tortur durchmachen darf. Dieser, wenn auch recht ungewöhnliche Fall, zeigt doch nochmal hervorragend, wieso es doch besser ist sich immer Gedanken, um die Sicherheit eines Computersystems machen sollte. In den Fall infiziert ein Virus einen Rechner und lädt auf diesen Kinderpornos, dadurch verliert die entsprechende Person Freunde, Arbeit und einiges mehr, von den Stress mit den Behörden, der Presse und einigen Personen, die Pädophilie nicht gerade freundlich gesinnt sind (klar irgendwie auch verständlich, kaum jemand mag solche Leute). Doch letztendlich stellte sich heraus, dass in Wirklichkeit ein Virus auf den Rechner war, der auch nachweislich entsprechende Websites aufrief und belastendes Material herunterlud. Danach wurde die Anklage nach 11 Monaten fallen gelassen, doch was ist mit allen Anderen?
Die ganze Geschichte ist unter spiegel.de Virenattacke mit Kinderpornos zu finden.

Gut, die gängigere Methode wäre wohl, dass jemand von dem infizierten Rechner weitere Attacken durchgeführt, die ggf. den Betroffenen in eine missliche Lage bringt. Beispiele dafür wäre ein Botnetz, was ggf. an DDoS-Attacken tätig ist, Brute-Force-Angriffe durchführt, oder jemand sich über den Rechner in empfindlichere Systeme häckt, wie Banken, Militär-, Nachrichtendienste u.ä.. Was wohl auch unangenehm genug werden könnte.