Clockwork

Treppenlicht 2.0

Es ist schon fantastisch, was man mit modernen LEDs alles anstellen kann.

Diese Wendeltreppe zum Beispiel soll dezent und Strom sparend beleuchtet werden, damit man sie auch im Dunkeln sicher benutzen kann. Eine Weihnachtslichterkette erfüllte den Zweck bisher. Allerdings war sie recht schwach und gab der Treppe außerdem einen hässlichen Partykeller-Look.

Dieser Blogartikel beschreibt, wie man sich mit ein wenig handwerklichem Geschick und geringem Aufwand eine Treppenbeleuchtung selbst bauen kann.

Read this article...
PHP 5.3.7, eine Analyse

Das PHP-Entwicklerteam veröffentlichte vor wenigen Tagen die Version 5.3.7, nur um schon wenige Tage später vor deren Verwendung zu warnen [Link auf Heise-Artikel wurde nachträglich wieder entfernt]. Der Grund dafür war ein Fehler in der Funktion crypt(), welche bei bestimmten Hash-Verfahren lediglich das Salt zurückliefert. Das kann dazu führen, dass nach einem Update auf PHP 5.3.7 keine Benutzer sich mehr auf einem Webauftritt einloggen können oder sich bei einer Passwortänderung nach einem Update auf eine spätere PHP-Version nicht mehr einloggen können. In PHP 5.3.8 wurde der Fehler wieder behoben.

Dieser Artikel ist der Versuch einer Analyse, wie es zu dem Fehler kam und warum er erst nach der Release bemerkt wurde.

Die PHP-Funktion crypt() ist in der Datei php_crypt_r.c implementiert. Folgender Codeausschnitt baut dort den Passwort-Hash zusammen:

memcpy(passwd, MD5_MAGIC, MD5_MAGIC_LEN);
strlcpy(passwd + MD5_MAGIC_LEN, sp, sl + 1);
strcat(passwd, "$");

strcat() fügt eine Zeichenkette an das Ende eines Puffers. Die Funktion gilt als unsicher, da sie nicht prüft, ob der Zielpuffer genügend Speicherplatz zur Verfügung stellt. Wird die Zeichenkette zu lang, wird der nachfolgende Speicherbereich beschädigt – ein typisches Problem bei C-Sprachen.

Aus dem Grund wurde der Aufruf durch eine sicherere Funktion ersetzt. Leider ist aber gut gemeint das Gegenteil von gut gemacht.

memcpy(passwd, MD5_MAGIC, MD5_MAGIC_LEN);
strlcpy(passwd + MD5_MAGIC_LEN, sp, sl + 1);
strlcat(passwd, "$", 1);

strlcat() stellt sicher, dass der Puffer nicht über sein Ende hinaus beschrieben wird. Dazu wird dessen Größe übergeben. Und genau hier lag das Problem, denn statt der Größe von passwd wurde anscheinend die Größe des zu kopierenden Textes übergeben, nämlich 1. Da passwd zu dem Zeitpunkt bereits deutlich mehr als ein Zeichen enthält, tut strlcat() genau das, was es tun soll, nämlich gar nichts. Das “$”-Zeichen wird nicht angehängt, das tatsächliche Ergebnis weicht damit von dem gewünschten Ergebnis ab.

Solch ein Fehler ist eigentlich ein Lehrbuchbeispiel für Unit-Tests, und der Kommentar zum Bugfix (Revision 315218) deutet auch an, dass ein solcher existiert:

Unbreak crypt() (fix bug #55439)
# If you want to remove static analyser messages, be my guest,
# but please run unit tests after

Tatsächlich gibt es einen Test, der die crypt()-Funktion mit bestimmten Werten aufruft und das Ergebnis mit einem erwarteten Ergebnis vergleicht. Dieser Test schlägt Alarm, wenn er ausgeführt wird.

Dass PHP 5.3.7 dennoch veröffentlicht wurde, lässt eigentlich nur einen Schluss zu: Der Unit-Test wurde nicht ausgeführt oder der Alarm wurde schlichtweg ignoriert. Spätestens beim Bau der finalen Version unmitelbar vor der Veröffentlichung hätte dies aber stattfinden müssen. Alles andere wäre grob fahrlässig.

Zusammengefasst hatte der Fehler also folgende Ursachen:

  • die für C-Sprachen üblichen Probleme bei der sicheren Verarbeitung von Zeichenketten
  • eine missverständliche oder nicht verstandene Dokumentation der Funktion strlcat()
  • keine verbindlich vorgeschriebene fehlerfreie Ausführung der Unit-Tests vor der Freigabe einer Release

Insbesondere der letzte Punkt wiegt schwer und wirft ein schlechtes Licht auf die verantwortlichen PHP-Entwickler.

Android-Debugging unter Fedora

Eine schöne Sache an der Android-Plattform ist, dass man auch unter Linux Apps entwickeln kann. Java und die Entwicklungsumgebung Eclipse steht als fertiges Paket zur Verfügung, und bei Google können die Entwicklertools kostenlos heruntergeladen werden.

Das Testen erfolgt entweder über einen Emulator, oder man geht gleich ans Eingemachte und testet seine Anwendung auf echter Hardware. Bevor das möglich ist, muss Fedora das Smartphone bekannt gemacht werden. Dazu wird mit Root-Rechten die Datei /etc/udev/rules.d/51-android.rules angelegt und mit folgendem Inhalt versehen:

SUBSYSTEM=="usb",SYSFS{idVendor}=="0bb4",SYMLINK+="android_adb",MODE="0666"

Unter idVendor wird die jeweilige Hersteller-ID des Smartphone-Herstellers eingetragen. Eine Tabelle der Vendor IDs gibt es ebenfalls bei Google. Wenn mehrere Smartphones verschiedener Hersteller zum Einsatz kommen, können entsprechend weitere Zeilen ergänzt werden.

Als nächstes muss auf dem Android-Phone das USB-Debugging aktiviert werden. Den Menüpunkt findet man unter EinstellungenAnwendungenEntwicklungUSB-Debugging aktivieren.

Wenn man nun seinen Androiden per USB anstöpselt und in dem Android-SDK das Kommando

platform-tools/adb devices

aufruft, sollte das Smartphone aufgelistet werden. Es steht dann als Zielplattform für die Entwicklung zur Verfügung.

Fedorablog-Artikel sind zurück

Soeben habe ich die wichtigsten Artikel aus dem früheren Fedorablog freigegeben. Sie sind (zusammen mit mittlerweile ein paar neuen Artikeln) unter der Kategorie Fedorado zu finden.

Der Fedorablog war ein von mir betriebener Blog, der sich auf Fedora-Linux spezialisiert hatte und auf fast vier Jahre Laufzeit zurückblicken konnte. Vor etwa anderthalb Jahren habe ich den Blog dann offline gestellt. Seitdem waren die Artikel nicht mehr verfügbar.

Eigentlich hatte ich geplant, sie schnellstmöglich in meinen privaten Blog, der shredzone, umzuziehen, aber die Arbeiten an der eigenen Blogsoftware dauerten dann doch wesentlich länger als erwartet. Wie auch immer: jetzt sind sie wieder da! 😀

Ich habe nicht alle Artikel aus dem alten Blog übernommen. Weggefallen sind im Wesentlichen veraltete Artikel, die inhaltlich mittlerweile keine Relevanz mehr haben (zum Beispiel waren das Ankündigungen zu früheren Fedora-Releases).

Viel Spaß beim Stöbern! Ich freue mich schon, jetzt auch wieder mehr über Fedora schreiben zu können, wenn auch nicht mehr in dem Umfang wie im früheren Fedorablog.

Lenovo ThinkPad X100e und Fedora 14

Nachdem die Installation von Fedora 13 auf dem Lenovo ThinkPad X100e nicht gerade besonders glatt lief, war ich sehr gespannt, wie sich Fedora 14 alias Laughlin auf dem System macht und welche Probleme zwischenzeitlich behoben wurden.

Schon beim ersten Start gab es eine positive Überraschung. Waren bei Fedora 13 noch Kernel-Optionen notwendig, um das System zu starten, fährt es nun bei Fedora 14 ohne Murren mit Plymouth hoch. Probleme gab es bei Fedora 13 außerdem mit der Steuerung der Hintergrundbeleuchtung und mit der Audioschnittstelle. Laughlin konnte auch hier punkten. Die Helligkeit lässt sich regeln, und endlich verstummen auch die eingebauten Lautsprecher, wenn man einen Kopfhörer anschließt. Das Suspend/Resume arbeitet nun ebenfalls einwandfrei, ohne dass ein Quirk notwendig ist. Das X100e geht problemlos schlafen und steht nach dem Aufwachen sofort wieder bereit.

Der für WLAN notwendige Treiber hat offenbar immer noch keinen Einzug in den Kernel erhalten, so dass es bei Fedora 14 weiterhin notwendig ist, den Treiberquelltext von Realtek herunterzuladen und selbst zu kompilieren. Hoffen wir, dass diese Schritte mit Fedora 15 der Vergangenheit angehören werden.

Eine Überraschung war, dass das Touchpad nun auch Multitouch unterstützt. Nach Installation des Pakets gpointing-device-settings konnten die entsprechenden Optionen ausgewählt werden, um zum Beispiel zum Scrollen mit zwei Fingern über das Touchpad zu wischen.

Vom fehlenden WLAN-Treiber abgesehen, zeigt sich Fedora 14 auf dem X100e von seiner besten Seite. Es macht richtig Spaß, mit dem Netbook zu arbeiten.