Posts by Luto

Error getting authority: Timeout reached (g-io-error-quark, 24)

systemd ist ja ganz schön geil, finden wir. systemd kann einen ganz schön in den Hintern beißen, finden wir auch. So ist uns das gestern Nacht auf dem U7-Host kohoutek passiert. Warum der Host zwei Stunden lang nicht vollständig erreichbar war könnt ihr hier nachlesen. Am 08.01. haben wir ein vergleichsweise großes Update für das Netzwerk-System unserer Hosts sowie unsere HTTP-nginx/httpd-Infrastruktur ausgerollt. Mehr dazu in einem weiteren Blogpost in den nächsten Tagen.

EOL: PHP 5.6 und 7.0 auf Uberspace 7

Alte Versionen gehören bei PHP leider zum Alltag. Während es natürlich viele schicke, moderne PHP-Apps gibt, stolpern wir hin und wieder über Kleinkrams, der doch bitte gerne PHP 5.4 hätte. Auch 5.6 wird noch häufig gefordert. Dennoch müssen wir hier - der Sicherheit wegen - Zöpfe abschneiden. 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 verschwundenen Requests im httpd

Vor nun fast einem Jahr war unsere Uberspace 7 Betaphase in voller Fahrt. Eine Hand voll User prügelte so lange auf U7 ein, bis so ziemlich alle Edgecases ausgereizeit waren. Viele der so gefunden Bugs waren schnell gefixt. Eines Tages bekamen wir allerdings eine vergleichsweise merkwürdige Meldung: 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.

HTTPS-Ausfall von 4 Hosts am 6.6.2018

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.

Reboot tut (nicht immer) gut

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.

Let's Encrypt: TLS-SNI und Shared Hosting

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.

Meltdown & Spectre - Bugs in Intel-CPUs

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.

WordPress CVE-2017-8295 - Unauthorized Password Reset

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:

Eine Runde mit dem Paternoster gefä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.

httpoxy auf Uberspace

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.