Eigentlich kann ich es nicht mehr hören

Angesichts der gegenwärtig massiv ausgebeuteten sicherheitsprobleme in wordpress kommt eine diskussjon auf, die ziemlich sinnfrei ist, aber wohl gerade deshalb mit besonderer intensität geführt wird. Es ist die system-diskussjon, die schier unendliche kwasselei darüber, welches das bessere blogsystem oder die bessere programmiersprache ist. (Ich verlinke diese „diskussjonen“ hier bewusst nicht, aber man stolpert gewiss darüber, wenn man ein bisschen guhgellt.)

Klar haben die s9y-blogger jetzt gut lachen. Aber die empfehlung, „einfach“ auf s9y umzusteigen, ist nicht unbedingt der weisheit letzter schluss. Etliche betroffene blogs laufen ja doch schon etwas länger, sie enthalten zum teil tausende von beiträgen. Alle diese beiträge sollten hinterher – guhgell hat sie ja indiziert und es gibt interne links – unter den gleichen adressen verfügbar sein, so dass hier hinterher sicher ein bisschen handarbeit ansteht, so segensreich import-skripten auch sein mögen.

Wenn man dann einmal probeweise einen import auf einem lokalen system durchführt und dabei feststellt, dass es probleme bei der konvertierung von umlauten gibt, vergeht einem schnell die lust auf einen umstieg. Natürlich kann man das alles noch nachflicken, aber das geht eben alles nicht so schnell, wie manche im moment den anschein erwecken wollen. Und denn ist da noch der applohd-ordner von wordpress, der sich gar nicht in die s9y-medienverwaltung einfügen will…

Wer so beflissen vom einfachen umstieg redet, denke bitte auch einmal daran, dass viele menschen keine besonderen technischen kenntnisse haben. Gerade blogger nicht, denn mit dem bloggen geht ja auch das versprechen einher, dass man relativ mühelos eigene inhalte in das welte weite web bringen kann. In meinen augen bedeutet das, dass die programierer eine ganz besondere verantwortung dafür tragen, dass die softwäjhr auch für menschen mit durchschnittlichen technischen fähigkeiten gut benutzbar ist, ohne dass irgendwelche kräcker sich auf tausende von schwachstellen stürzen können. Allein schon wegen dieser bedingung ist der selbst erzeugte zeitdruck der wordpress-entwickler kontraproduktiv und ausgesprochen schwachsinnig. (Vor allem, wenn sie ihre termine nicht einmal schaffen. Und dass man die versjon 2.4 einfach ausfallen lässt, statt dass man den termin verschiebt, das ist keine meisterleistung der kommunikazjon, sondern unfreiwillig komisches teater.)

Denn gibt es da aber noch einen anderen punkt. Der ist auch nicht besonders hilfreich für die jetzt betroffenen blogger, aber wenigstens substanzjell. Es ist das problem der programmiersprache PHP und der zugriff auf die datenbank, der ohne netz und doppelten boden angriffe recht leicht machen kann.

Ein typischer ausschnitt aus einer wordpress-komponente könnte etwa so aussehen (hier extrem vereinfacht, um das problem klar zu machen):

global $wpdb;
$r = $wpdb->query("select * from comments where ID='$id'");

Dieses $id in der SQL-Anweisung  ist eine PHP-variable. Sie wird im String direkt durch ihren wert ersetzt, typischerweise kommt der inhalt dieser variablen aus einer benutzereingabe. Wenn es ein cräcker jetzt schafft, da etwa folgendes reinzukriegen…

$id = "1'; update posts set post_text = 'Visit my great Viagra Shop www.fock.you'";

…denn wird der folgende text an den MySQL-sörver gesendet (zeilenumbruch von mir hinzugefügt):

select * from comments where ID='1';
update posts set post_text = 'Visit my great Viagra Shop www.fock.you'

Da die einzelnen anweisungen durch semikolon getrennt werden, führt der MySQL-sörver hier gehorsam zwei verschiedene anweisungen aus. In der ersten ermittelt er ein paar daten aus der kommentartabelle, in der zweiten ersetzt er sämtliche beiträge durch einen text mit recht eindeutiger funktion, der zum besuch eines betrügerischen webangebotes auffordern soll.

Es gibt natürlich eine methode $wpdb->quote(), die solche missbräuche unmöglich macht…

$id = $wpdb->quote($id);

…ja, wenn sie nur immer und von allen komponenten mit jeder benutzereingabe aufgerufen wird. Das ist nicht zentral gekohdet, sondern es liegt in der verantwortung des programmieres einer jeden komponente, sich darum zu kümmern. Ein einzige plackin, das hier etwas sorglos vorgeht, und die gesamte wordpress-datenbank kann von jedem derhergelaufen deppen im internet beliebig manipuliert werden. Man nennt diesen angriff übrigens eine „SQL-Injection“, es handelt sich geradezu um ein typisches PHP-problem.

Und genau das wird wohl auch die kwelle der gegenwärtigen angriffe sein, die sich durch eingefügte werbelinks in normalen blogbeiträgen auszeichnen. Ich weiß noch nicht, welches plackin dafür verantwortlich ist, aber ich weiß, dass wahrscheinlich nicht jedes wordpress-blog angreifbar ist. Denn sonst wären noch viel mehr blogs von dieser seuche betroffen.

Man kann das etwa mal mit der vorgehensweise in der programmiersprache python vergleichen (ebenfalls stark vereinfacht, um den blick auf das wesentliche zu richten).

global connection
cur = connection.cursor()
cur.query('select * from comments where ID=%s', (id, ))

Hier fällt hoffentlich auch dem unkundigen auf, dass die variable id hier nicht direkt in die zeichenkette eingefügt wird. (Obwohl man das durch auch in python so machen könnte, wenn man ein bisschen doof ist.) Vielmehr ist die zentrale komponente für den zugriff auf die datenbank dafür zuständig, den eigentlichen text der SQL-abfrage zusammenzusetzen; dabei werden bestimmte zeichen „unschädlich“ gemacht, ohne dass sich der programmierer an jeder stelle selbst darum kümmern will.

Mit diesem unterschied vor augen, kann man durchaus sagen, dass PHP bereits im entwurf seiner schnittstelle zur datenbank sehr unsicher ist. WordPress hat es bislang versäumt, dieses manko durch eine eigene zwischenschicht zu beseitigen; und so kann es immer wieder einmal passieren, dass ein einziges, schäbig programmiertes plackin ein ganzes blog in die klauen der spämmer und kräcker treibt.

Diese grundsätzliche PHP-schwachstelle bestünde auch in s9y. Man hat sich dort bislang durch ein streben nach hoher kwalität des kohds beholfen, und das hat alles in allem gut funkzjoniert. Wenn s9y aber erst einmal so richtig populär wird, denn wird es zum einen immer wieder „inoffizjelle“ komponenten und dieseins geben, zum anderen werden sich alle kräckköppe dieser welt auf die ausbeutung von schwächen stürzen. Dass diese arschlöcher im moment lieber wordpress nehmen, liegt vor allem an der größeren verbreitung von wordpress.

Es wäre nun aber durchaus möglich, die offizjelle wordpress-API um eine bessere schnittstelle zur datenbank zu erweitern, und ich kann mich erinnern, dass ich das auch einmal angeregt habe. Leider müsste anschließend der gesamte kohd von wordpress angefasst werden. Wenn ältere plackins noch laufen sollen, müsste die schlechte schnittstelle weiterhin erhalten bleiben, und damit würde sie auch weiterhin benutzt werden. Auch von deppen, die sich für tolle plackin-programmierer halten.

In meinen augen zeigt sich immer mehr, dass es bei wordpress schon lange nicht mehr darum gehen sollte, neue „Features“ einzubauen, sondern viel mehr darum, systematische schwachstellen aus dem bestehenden kohd zu entfernen. Und zwar gründlich. Auf kompatibilität um jeden preis sollte dabei besser verzichtet werden, da sonst schnell neue probleme eingeführt werden…

Wenn ich doch nur die zeit und die möglichkeiten dazu hätte, ich würde jetzt damit beginnen, meinen eigenen fork zu machen. An vernunft bei den gegenwärtigen WP-entwicklern kann ich nicht mehr glauben.

Wie man bei scientology programmiert…

Nein, ich meine nicht, wie man dort menschen programmiert. Sondern, wie man kompjuter programmiert, wenn die benutzereingaben im berüchtigten 200-fragen-test überprüft werden sollen. Vielleicht sollten die mal jemanden programmieren lassen, der sich mit regulären ausdrücken in javascript auskennt

Aber was erwarte ich von der „Church of Scientology“? Kwalität etwa? Das wäre doch etwas viel verlangt.