In etwas über einer Woche ist es dann so weit: Ab dem 28.4.2011, also dem Release-Termin der finalen Version von Ubuntu 11.04 (natty), wird knapp die Hälfte der Menschheit endgültig zu blöd für diese Distribution sein. Denn nur so kann man sich erklären, dass in einem kürzlichen Usability-Test der neuen Unity-Oberfläche neben einer ganzen Reihe anderer interessanter Phänomene 5 von 11 Testern das GUI zum crashen brachten.
OK, also das Benutzernamen-Feld unserer Windows-Clients war wohl für die letzten Wochen eine root-Shell auf unseren Fileserver. Dort hatte ich logwatch installiert, um Benutzer zu fangen, die ihre Accountdaten weitergeben (d.h. z.B. auf einer geographisch völlig unmöglichen Kombination von Clients gleichzeitig eingeloggt sind).
Seit ein paar Tagen bekam ich dann von logwatch keine Mails mehr, was ich dann heute mal gedebuggt habe. Nun hat sich wohl irgendwann mal ein User mit irgendwelchem Random-Kram versucht einzuloggen (“3836jai)xoh)”). Unser Samba-Server ist so eingerichtet, dass er eine Logdatei pro User anlegt. Äh, das hat so mal Sinn gemacht … wirklich. Und deshalb gab es jetzt also eine Datei namens “log.3836jai)xoh)”. Und das fand logwatch gar nicht so lustig, denn logwatch wirft eine Liste der Logdateien die es so findet einfach so ohne sanity checks oder Quoting oder sonst was in die sh. Das resultierte dann in ein bisschen Fehlerausgabe und einem unsauberen Ende:
sh: -c: line 0: syntax error near unexpected token `)' sh: -c: line 0: `cat /var/log/samba/log. 4023 /var/log/sa .........
Ist natürlich alles in allem ärgerlich, und irgendwie sollte man dieses komische Log-Setup auch mal wieder abschaffen. Aber dennoch, ich finde ein logwatch sollte das nicht einfach so tun. Nehmen wir mal an, ein User hätte sich aus Versehen als “; rm -rf /” oder “; poweroff” angemeldet. Dann hätte der Fileserver am nächsten Morgen um 6:25 sauber die Platte gewiped oder sich zur Ruhe gebettet. Echt unschön sowas …
Habe das jetzt mal an die Entwickler gefaxt, aber die lesen ihren Bugtracker offenabr nie. Mal schauen ob sie auf Mails reagieren … und der logwatch darf vorerst in seiner Hütte bleiben 
.
Update 1.3.2011: Bereits nach wenigen Stunden hatte einer der logwatch-Entwickler auf meine Mail auf der Mailingliste reagiert und einen Patch veröffnetlicht. Heute kriegte ich dann dank Google Alerts mit, dass Ubuntu was dazu in den Security Notices hat.
Und hier ist sie – meine erste offiziell entdeckte Vulnerability – CVE-2011-1018 (CVE | NVD | USN | …). Irgendwie bin ich ja dann doch so’n bisschen stolz. Darf ich jetzt eigentlich noch in die USA einreisen 
?
Übrigens war mir bis gerade eben gar nicht klar wieso man da so einen Aufstand drum macht (gut, den macht man um jede Sicherheitslücke, aber es wirkt irgendwie erschlagend). Ich dachte ja das wäre nur in meiner komischen Samba-Konfig. mit den Benutzernamen im Log-Dateinamen so dramatisch, aber dann fiel mir auf, dass das sogar auf den meisten Linux-Distributionen mit Standard-Konfig. exploitbar ist. Viele Default-Konfigs setzen nämlich den NetBIOS-Namen des Clients in den Logdateinamen ein (log file = log.%m). Den kann man sich als Client im Prinzip ja auch selber ausdenken. Samba wird dann zwar unter Umständen sagen “Ne du, das Ding sieht komisch aus” oder “Häh, wer bist denn du?” – aber das wird es nicht nur dem Client mitteilen sondern das auch loggen. Und zwar wohin? Genau …
Update 4.3.2011: Die Debianer haben es dann heute mit DSA-2182-1 auch schon zu einem Advisory gebracht. Boah, sind die flott!
Wenn man sich im Internet ein wenig umsieht, stellt man fest, dass so ziemlich die halbe Netzgemeinde sich schon vor dem Problem sah, dass sie die aktuelle Joomla-Version auf einem System mit PHP 5.3 nicht mehr installieren können. Das liegt an der Inkompatibilität zwischen PHP 5.2 und PHP 5.3. Ich persönlich finde es ja mehr als erstaunlich, wie kaputt man eine Sprache mit einem Sprung in der Minor-Version machen kann. So etwas kann man seinen Benutzern eigentlich nicht antun, und deshalb werde ich in Zukunft auch erst recht die Finger von diesem Krampf lassen.
Nun wollen die anderen ja aber nicht immer ganz so, wie der Admin will, und deshalb muss ich auf dem neuen Ubuntu 10.10 maverick-Server natürlich Joomla (ebenfalls Krampf) supporten. Und in Ubuntu 10.10 ist PHP 5.3 an Bord.
Nun kursieren im Internet die kuriosesten Lösungen. Zum Beispiel könnte man PHP 5.2 selber kompilieren oder einfach aus den alten Repositories installieren, je nach gusto parallel zur neuen 5.3er-Version oder alleine. Beides möchte man so einfach eigentlich nicht. Ersteres könnte irgendwann die Selbstmordrate in der IT-Abteilung enorm steigern, letzteres rollt jedem sicherheitsbewussten BOFH die Fußnägel auf den Rücken.
Zum Glück hatte ich dank des Schneechaos bei der Bahn genügend Zeit, über die Problematik nachzudenken. Und kam auch tatsächlich zu einer Lösung,die ich persönlich für zwar nicht unbedingt resourcenschonend, aber sehr sauber halte: eine chroot-Umgebung mit Ubuntu karmic, darin ein Apache mit mod-php5 in der korrekten Uralt-Version. Und den dann nach außen geproxied.
Dass die meisten elektronischen Übersetzer an irgendeinem Punkt immer ziemlichen Mist ausspucken, ist ja hinlänglich bekannt, aber der hier hat mich gerade meine Unterrichtsstunde gekostet.
Aufgabe:
Finde heraus, was der Slogan “Linux for Human Beings” bedeutet.
Schlau wie meine Kiddies ja sind, landet der Satz direkt in Google Translate …
Danke, Google, das war’s dann erstmal mit dem seriösen Unterricht 
…
P.S.: Um den anderen Klugscheißern zuvor zu kommen: ja, das ist case-sensitive …
Am 30. April begann mit dem Upload der Toolchain offiziell die Entwicklung der neuen Ubuntu-Version 9.10, die den Release-Namen Karmic Koala trägt. Am 28. Mai wurde beim Ubuntu Developer Summit die zu verwendende Kernelversion abgestimmt, am 18. Juni einigten sich die Entwickler auf die zu implementierenden Features, die bis dahin als Spezifikationen in Launchpad definiert wurden.
Am 29. Juli begann für Felix und mich der aktive Beta-Test. Karmic war zu diesem Zeitpunkt im Alpha 3-Stadium. Eigentlich war uns klar, dass das nicht gut gehen konnte (schließlich benutzten wir die Version auf Produktivsystemen, was an sich schon eine mutige Entscheidung ist). Doch tatsächlich war Karmic schon so weit benutzbar, dass es für den täglichen Einsatz geeignet war (Anm. d. Red.: nicht zu Hause nach machen). An diesem Tag entstand auch ein interesantes Foto: Felix und ich waren gerade dabei zu einer Radtour aufzubrechen, während unsere Systeme das dist-upgrade zu Karmic fuhren. Dass wir dabei mit Helmen vor den Monitoren saßen, mag ein Zeichen gewesen sein .
