Nuja, das Debian-Team in allen Ehren - aber "verdammt schnell" wäre ein Datum zwischen dem Mainline-Patch (01.04.2026) und dem CVE-Assignment (22.04.2026) gewesen. Zudem patcht dieses Kernel-Update 303 (!) CVEs.
Man muss aber auch sagen, dass die Maintainer das i.d.R. alles ehrenamtlich machen, und eine Kernel-Update sicherlich das Sensibelste aller Updates sein dürfte.
Hallo,
vor wenigen Stunden ist ein Exploit namens "Copy Fail" (CVE-2026-31431) veröffentlicht worden, mit dem es unter praktisch allen Linux-Distributionen möglich ist, mit nur minimalem Aufwand root-Rechte zu erhalten:
Wir haben das eben mal mit Debian 11 getestet - und auf Anhieb Erfolg gehabt. :-O
Aus diesem Grund empfehlen wir dringend, möglichst schnell den im Heise Newsticker beschriebenen Workaround anzuwenden:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf && rmmod algif_aead 2>/dev/nullWichtig: wenn der Exploit einmal erfolgreich ausgeführt wurde, muss der Server rebootet werden! Zumindest in unseren Tests hatte ansonsten die Ausführung von su jedem Benutzer sofort root-Rechte gegeben - ohne jegliche Passwort-Abfrage.
In der Container-Umgebung (LAC) war es uns bislang nicht möglich, den Exploit auszunutzen. Zum einen sind dort keine setuid-Programme verfügbar, die als Angriffsfläche genutzt werden könnten, zum anderen befindet sich der Benutzer da in einer isolierten Umgebung, welche einen Ausbruch zusätzlich erschwert.
Viele Grüße
-Klaus Keppler
(der Vollständigkeit halber: dieser Exploit bzw. die Sicherheitslücke hat absolut nichts mit LiveConfig zu tun, sondern betrifft schlichtweg alle Linux-Server)
Ab sofort steht v3.2.1-2 (Build 17465) bereit, damit ist (u.a.) dieser Fehler behoben. 
Die Fehlermeldung "key import failed" hat exakt einen Grund: der in /etc/liveconfig/sslcert.pem enthaltene Private Key ist (bzw. war) ungültig (Tippfehler, Copy&Paste-Fehler, ...). Mit CA-Zertifikaten hat das nichts zu tun.
Kurzer Nachtrag (weil es da noch einen anderen Kunden erwischt hatte): wahrscheinlich ist/war die Reihenfolge des Schlüssels und des Zertifikats in dieser Datei falsch. OpenSSL erwartet bei kombinierten PEM-Dateien immer zuerst den Private Key, danach das TLS-Zertifikat und anschließend eventuelle Chain-Zertifikate.
LiveConfig 3.2.1 wird das beim Start prüfen und ggf. ungültige/unerwartete Blöcke "vorspulen" (und dabei eine entsprechende Fehlermeldung ausgeben).
lclogsplit wird nur dann als eigenständiger Service eingerichtet, wenn auch NGINX genutzt wird. War das vielleicht früher mal auf dem Server installiert?
Die Lösung ist recht simpel: deaktivieren Sie den lclogsplit-Dienst (lclogsplit wird in diesem Fall automatisch durch Apache gestartet)
systemctl disable lclogsplit
Ohne Fehlermeldung ist leider keine Hilfe möglich.
systemctl status lclogsplit
journalctl -u lclogsplit
das SitePro Modul "lc-mod-sitepro" würde beim Update auf LiveConfig 2.19.1 entfernt werden ?
Fehler unter Ubuntu 24.04, andere BS hab ich nicht getestet.
Wir haben das lc-mod-sitepro in 2.19.1 eben mit in die Repos aufgenommen (da hatte sich nichts geändert, daher wurde das nicht bereitgestellt - allerdings sind die Dependencies offenbar doch recht streng...)
(bereits per Ticket beantwortet, hier aber nochmal "öffentlich":)
LiveConfig 2.19.1 unterstützt schlichtweg kein include in NGINX-vHosts, wenn die betroffene Domain eine reine Proxy-Konfiguration enthält. LiveConfig 3.x wiederum kann das.
Wir haben die entsprechende Anpassung eben in LiveConfig 2.19.2 "backported" - ab dem nächsten Update ist das dort also (auch) möglich.
Da kommen leider ein paar Sachen durcheinander.
Die Fehlermeldung "key import failed" hat exakt einen Grund: der in /etc/liveconfig/sslcert.pem enthaltene Private Key ist (bzw. war) ungültig (Tippfehler, Copy&Paste-Fehler, ...). Mit CA-Zertifikaten hat das nichts zu tun.
Wenn Sie im LiveConfig (unter Einstellungen -> Web) aus der TLS-Liste ein Zertifikat für die Weboberfläche auswählen, dann hat das wiederum auch nichts mit der sslcert.pem zu tun (die wird nicht angefasst/geschrieben).
Wir haben die Fehlermeldung etwas erweitert - künftig enthält diese zusätzlich den Dateinamen (lautet dann also z.B. /etc/liveconfig/sslcert.pem: key import failed: ....
Was passiert denn wenn Sie diese Datei entfernen (z.B. umbenennen) und anschließend LiveConfig3 starten/installieren? Damit lässt sich einfach herausfinden, ob's daran liegt.
Bei einem LiveConfig-Client gibt's keine sslcert.pem.
Siehe RE: LiveConfig 2.18.9 und 3.1.1 veröffentlicht
Vermutlich ist die /etc/liveconfig/sslcert.pem "kaputt".
Auf den ersten Blick scheint dort kein systemd zu laufen. Das wäre allerdings zwingend notwendig (LiveConfig startet/stoppt die Dienste via dBus mit systemd, und nutzt auch sonst viele der Vorteile welche systemd mit sich bringt).
Mich wundert es sogar, dass man heutzutage überhaupt noch ein Debian 13 (Trixie) ohne systemd starten kann... 
Was meinen Sie mit "in unserer Umgebung"? Welche LiveConfig-Version genau nutzen Sie?
Ist doch schon vorhanden...
Kunden -> (Kunde anklicken) -> Box "Benutzer" -> Button "Passwort ändern"
Siehe https://www.liveconfig.com/de/blog/2025/12/update-lizenzschlüssel/
Schicken Sie bitte einfach eine kurze Mail an support@liveconfig.com, dann senden wir Ihnen den erforderlichen Patch.
Grundsätzlich empfehlen wir natürlich, Server immer möglichst aktuell zu halten.
Ist aktuell in Arbeit (wir haben auch noch Tickets dazu offen) - sollte bis morgen soweit fertig sein.
Auch mit der aktuellsten Version ist liveconfig.log voller Versuche, Zertifikate für in LC längst gelöschte Domains zu erlangen. Teils wurden die Accounts (Verträge), insgesamt gelöscht.
Die Zertifikate sind nicht in der Zertifikatsliste zu finden. Es sind also verwaiste Einträge. Das Log ist so umständlich zu nutzen und der Server wird unnötig beschäftigt.
Ich gehe davon aus, dass es sich hier um "Altlasten" handelt (bei allen unserer Tests werden Domains und Zertifikate korrekt und vollständig gelöscht).
Domains müssen gemäß Datenbank-Constraints immer einem Vertrag zugeordnet sein; wenn da also noch Domains im Log auftauchen, existieren die Verträge möglicherweise noch. Ohne einen konkreten Fall zu prüfen, macht das keinen Sinn. Bitte kurze Mail an support@liveconfig.com, dann gehen wir mal die erforderlichen Datenbankabfragen durch.
"an phpMyAdmin anmelden..." (wofür stehen dabei die "..."?) -> https://.../lc-sso.php
Der Port ist ein privilegierter Port. Von außen (Client mit 3.14 funktioniert er Zugriff, von intern nicht). An Firewall liegt es wohl nicht. GUI ist über diesen Port erreichbar.
Auch damit kann ich leider überhaupt nichts anfangen. Die URLs zu phpMyAdmin (wo auch die lc-sso.php liegen muss) und zum LiveConfig sind zwei völlig verschiedene Baustellen. Schicken Sie uns ggf. die konketen URLs und exakten Fehlermeldungen (möglichst ungekürzt) an support@liveconfig.com.
Zitatssh -o FingerprintHash=sha256 <server> liefert denselben Wert "foobar".
GUI: "foobar" bei "Wert" eingetragen -> speichern -> "Invalid input"
"foobar" ist kein gültiger Hash. Der von o.g. Befehl erzeugte Fingerprint ist nicht im vom DNS erwarteten Format. Verwenden Sie bitte den Befehl ssh-keygen -r <Host> (oder ssh-keyscan -D <Host>)
ZitatRemoving incomplete database backup
mysqldump process received signal 9 and exited
Job for lclogsplit.service failed because a timeout was exceeded.
Wie lange dauert bei Ihnen die Erstellung eines MySQL-Dumps der LiveConfig-Datenbank, und wie groß ist die resultierende Datei?
time /usr/lib/liveconfig/lcdbbackup /root/test.dump
Wir haben eben die Version 2.19.1 bereitgestellt, in welcher dieser Fehler behoben ist.
Ich bitte um Entschuldigung für die Unannehmlichkeiten 
Hintergrund ist, dass wir die "SFTP-Only"-Einschränkung überarbeitet hatten, und hierfür Änderungen an der sshd-Konfiguration vorgenommen werden mussten. Dabei griff LiveConfig 2.x auf eine Funktion zu, die aber erst in 3.x verfügbar ist. Wir haben unsere Tests angepasst, damit so etwas künftig (hoffentlich) nicht mehr passiert. Die SFTPOnly-Anpassung in LC 2.x wird auf ein späteres Update verschoben.
Viele Grüße
-Klaus Keppler
