Wie bei php selbst und auch in unserem Manual dokumentiert, laufen die PHP-Versionen 5.6 und 7.0 dieses Jahr aus. Danach gibt es keine Updates mehr, auch nicht für Sicherheitslücken. Die beiden Version fliegen demnach bei Uberspace 7 mit dem 31.12.2018 raus. Da wir standardmäßig die Version 7.1 einstellen, sind von der Änderung nur User betroffen, die explizit eine alte Version eingestellt haben: 96 Stück bei PHP 5.6 und nur 37 bei 7.0.

Seit ca. 3 Minuten: Wenn ich https://usr.betahost.uberspace.de/ aufrufe, lande ich auf einer Loginseite von “Mattermost”. Ich hab aber doch gar kein Mattermost auf meinem uberspace.

Magie ist kompliziert - aber halt auch cool. Auf Uberspace 7 setzen wir auf ein klein wenig Magie, um Let’s Encrypt Zertifikate für alle eure Domains zu holen. Das klappt auch voll gut! … meistens.

tldr-intermezzo: HTTPS für User-Domains (also alle relevanten) ist vom 6.6.2018 4 bis circa 8 Uhr auf 4 Hosts (whipple, taylor, kojima und klemola) ausgefallen. Es handelte sich dabei um einen einmaligen Fehler und kein generelles Problem. Fürs Warum und zukünftige Gegenmaßnahmen, einfach weiterlesen.

TLDR: Es gab heute um 13:15 einen ungeplanten Reboot und eine damit verbundene, sehr kurze Downtime bei allen U7-Hosts. Grund war, dass wir wegen einem journald-Bug einen Reboot benötigt haben, diesen aber (intern) nicht sauber kommuniziert haben: Code ausgerollt, zack Reboot! Das tut uns leid und sollte in Zukunft nicht mehr passieren. Mehr dazu weiter unten.

Heute am 22.01.2018 gegen 13:15 wurden alle unsere Uberspace 7 Hosts nicht 100% geplant rebootet. Die meisten Hosts waren nach weniger als zwei Minuten wieder da; geplant oder gar angekündigt war der kurze Ausfall allerdings dennoch nicht. Wir möchten euch in diesem Blogpost darlegen, wie es überhaupt dazu gekommen ist.

TLDR: Eine Hand voll Shared-Hosting-Anbietern ist im Moment von einer Lücke im Zusammenhang mit Let’s Encrypts tls-sni-01 Challenge betroffen. Wir nicht. Warum steht weiter unten.

Let’s Encrypt unterstützt neben der bekannten http-01 Challenge (das ist die mit den wunderschönen /.well-known/acme-challenge/evaGxf...-URLs) auch andere Validierungsformen wie dns-01 (involviert “Magic”-Records im DNS) und auch tls-sni-01. In diesem Fall findet die Validierung im TLS-Protokoll selbst, noch vor HTTP statt. Dazu müssen spezielle, selbst-signierte Zertifikate ausgeliefert werden. Die von euch, die das genauer interessiert: hier geht’s lang zum Standard-Dokument.

TLDR: Wir sind (wie alle mit Intel-CPUs) von Meltdown und Spectre betroffen. Es gibt Fixes. Sie einzuspielen erfordert einen Reboot. Siehe Liste dazu weiter unten.

Das Problem

Anfang Jänner wurde bekannt, dass alle neueren Intel-CPUs, AMD-CPUs in manchen Konstellationen und sogar einzelne ARM-CPUs von zwei Timing-Sicherheitslücke betroffen sind. Sie tragen die wunderschönen Namen Meltdown und Spectre. Diese Lücken ermöglichen es im Worst-Case privaten Speicher aus dem Kernel auszulesen und so fremde Daten in die Hände zu bekommen.

Standard WordPress-Installationen der Version 4.7.4 sind im Moment für die Lücke CVE-2017-8295 anfällig. Mithilfe dieser Lücke kann ein Angreifer Password-Reset-Mails an beliebige Mailserver umleiten und so an den kritischen Link gelangen. Seitens WordPress gibt es hierfür noch keinen Fix.

Das funktioniert, da WordPress den Host-Header 1:1 für diverse Mail-Header in der ausgehenden Mail benutzt. Wie das genau funktioniert könnt ihr in der Exploit-DB nachlesen.

Ein Angriff würde also beispielsweise so aussehen:

POST /wp/wordpress/wp-login.php?action=lostpassword HTTP/1.1
Host: injected-attackers-mxserver.com   <== oh noes! D:
Content-Type: application/x-www-form-urlencoded
Content-Length: 56

user_login=admin&redirect_to=&wp-submit=Get+New+Password

In unserem Setup werden Requests anhand ihrer Host-Header an die jeweiligen Uberspaces und damit an die WordPress-Instanzen verteilt. Wenn nun eine Angreiferin den Header modifiziert, landet der Request gar nicht erst bei der angegriffenen WordPress-Instanz, sondern auf unserer “Diese Domain kennen wir leider nicht”-Seite. Ein WordPress, das bei uns gehostet ist, ist für diese Lücke also nicht anfällig.

Wie ihr im aktuellen Blogpost der Uberspace-7-Reihe lesen könnt, ändert sich im Bereich unserer Shellscripts gerade eine ganze Menge. Aus Config-Dateien werden Ansible-Facts, aus Bash werden Playbooks oder Python-Skripte. Um all diese Teile wieder unter einen Hut zu bekommen, müssten wir einen Ausflug in die Softwareentwicklung machen.

Viele unserer Features - wie das allseits beliebte uberspace-add-domain - erfordern, dass wir euch mehr Rechte einräumen, als ihr eigentlich haben dürft. Auf diesem Weg könnt ihr beispielsweise mit uberspace-add-domain auf die Konfiguration unseres Webservers oder mit uberspace-add-port auf das iptables-Ruleset in engen Grenzen und indirekt, aber dennoch schreibend, zugreifen.

Wie ihr sicherlich schon auf Hackernews oder anders wo gelesen habt, kursiert gerade eine “neue” Lücke für diverse GCI-Applikationen im Netz: httpoxy.

Konkret geht es darum, dass der Proxy-HTTP-Header des Clients aufgrund der CGI-Spezifikation in der Umgebungsvariable $HTTP_PROXY landet. Diese wird von unzähligen Applikationen dazu benutzt, Verbindungen nach außen aufzubauen. Somit hätte ein potentieller Angreifer die volle Kontrolle über diese Aufrufe, die zum Beispiel die API eines Zahlungsanbieters als Ziel haben können.