News

Überblick und Timeline

Für neue Server steht bei cloudscale eine Reihe von beliebten Linux-Distributionen zur Auswahl. Noch individuellere Setups sind möglich dank sogenannten Custom Images: Als Kunde lädst du ein Festplatten-Abbild hoch, mit dem dann das root-Volume deiner neuen virtuellen Server initial befüllt werden kann – inklusive all den Tools und Settings, die du brauchst. An dieser Stelle gab es eine Sicherheitslücke in OpenStack – dem Open-Source-Projekt, auf welchem unser Cloud-Angebot basiert: Mit dem Hochladen von speziell präparierten Images im QCOW2-Format war es möglich, auf Dateien von Systemen zuzugreifen, die bei uns am Import-Prozess von Custom Images beteiligt sind.

Als Sofortmassnahme hatten wir den Import von QCOW2-Images vorübergehend deaktiviert. Konkret wurden alle Images als "Raw" behandelt; wo es sich tatsächlich um QCOW2 handelte, booteten virtuelle Server damit deshalb nicht. Uns war klar, dass dies für einige Kunden einen Zusatzaufwand bedeutet, da sie Images vor dem Import manuell ins Raw-Format konvertieren müssen. Im Interesse der Sicherheit für uns und unsere Kunden haben wir uns aber dennoch kurzfristig für diesen temporären Schritt entschieden.

Timeline:

• Dezember 2020: Einführung von Custom Images, Unterstützung für Raw-Format
• Mai 2022: Zusätzlich Unterstützung für Images im QCOW2-Format
• Februar 2023: Spezifizieren des Image-Formats beim Import nicht mehr nötig
• 02.07.2024: Veröffentlichung der Sicherheitslücke OSSA-2024-001 / CVE-2024-32498
• 03.07.2024: Import von Images im QCOW2-Format als Sofortmassnahme blockiert
• 31.07.2024: Import von Images im QCOW2-Format wieder möglich, Anpassung der API

Hintergrund zur Lücke

Image-Dateien im QCOW2-Format haben einige besondere Features, z.B. den tendenziell geringeren Platzbedarf. Zudem können sie nicht nur die eigentlichen Daten eines Datenträgers enthalten, sondern auch Verweise auf ausserhalb liegende Dateien. Kern der Sicherheitslücke in OpenStack war eine mangelhafte Prüfung in einigen OpenStack-Komponenten, die solche Verweise bzw. deren Zieldateien während der Verarbeitung von QCOW2-Images mit-verarbeitet haben. Da Custom Images im Fall von cloudscale immer im Raw-Format gespeichert werden, betraf die Lücke insbesondere das automatische Erkennen des zu importierenden Formats sowie die Konvertierung von QCOW2 zu Raw. Gemäss unserer Analyse gibt es jedoch keine Hinweise darauf, dass die Lücke bei cloudscale tatsächlich ausgenutzt worden wäre.

Die Konvertierung von Images, für die OpenStack auf qemu-img convert zurückgreift, wurde mittlerweile dahingehend gepatcht, dass auch mit speziell präparierten Images kein Ausnutzen mehr möglich ist. Somit können wir bei cloudscale das Importieren von QCOW2-Images wieder freigeben. Für die automatische Erkennung des Formats mit qemu-img info gibt es in der Entwickler-Community von OpenStack jedoch (noch) keine verlässliche Lösung. Deshalb werden auch wir bei cloudscale künftig nicht mehr versuchen, das Image-Format automatisch zu erkennen.

Nutzung von QCOW2-Images bei cloudscale

Das Importieren von QCOW2-Images ist bei cloudscale ab sofort wieder möglich, allerdings muss das Format beim Import mit angegeben werden. Beim Import via API wird hierzu das Attribut source_format verwendet: Nachdem dieses seit Februar 2023 als "deprecated" deklariert war, wird es aus gegebenem Anlass wieder offiziell genutzt. Bei Images im Raw-Format kann das Attribut weggelassen werden, für QCOW2-Images wird source_format hingegen zwingend benötigt. Wir sind uns bewusst, dass diese Änderung des API-Verhaltens nicht vollständig "non-breaking" ist; mit der gewählten Lösung versuchen wir jedoch, den Anpassungsaufwand so klein als möglich zu halten.

Die aktuellen Versionen unserer Module/Plug-ins unterstützen das Attribut source_format und können somit benutzt werden, um QCOW2-Images zu importieren. Antworten auf alle wichtigen Fragen dazu findest du in den untenstehenden FAQ.

Wir freuen uns, dass wir nach dem kurzfristig nötig gewordenen Ausschluss von QCOW2 den Import von Custom Images in diesem Format wieder freigeben können. Das Wiedereinführen eines alten Attributs im entsprechenden API-Call liess sich dabei leider nicht vermeiden. Uns war wichtig, keine bekannten Schwachstellen offen zu lassen, und gleichzeitig möglichst wenig Anpassungsaufwand zu verursachen. Wo trotz allem Anpassungen nötig werden, bitten wir um dein Verständnis.

Umsichtig und pragmatisch.
Dein cloudscale-Team

FAQ

Was passiert mit existierenden Custom Images?
Nichts. Die Änderung betrifft nur den Import-Vorgang. Existierende Images sind nicht betroffen.

Was ändert sich beim Import via webbasiertes Control-Panel (control.cloudscale.ch)?
Du musst neu im Drop-Down "Source Format" das Format des Images spezifizieren.

Mein Import zeigt die Error-Message "Import could not be processed", was muss ich tun?
Wahrscheinlich hast du versucht, eine Datei als "QCOW2" zu importieren, welche aber keine solche ist. Überprüfe das Format und die URL.

Ich importiere ausschliesslich Raw-Images. Bin ich betroffen?
Nein. Stelle jedoch sicher, dass das source_format Feld entweder nicht übergeben wird oder "raw" enthält. Bei anderen Werten tritt ein Fehler auf.

Ich verwende Terraform, was muss ich tun?
Um QCOW2-Images importieren zu können, musst du den Provider "cloudscale" ab Version v4.4.0 verwenden und das import_source_format für neue Images spezifizieren. Bestehende Images können unverändert weiter verwendet werden; das Format sollte nicht nachträglich spezifiziert werden.

Ich verwende cloudscale_ch.cloud für Ansible, was muss ich tun?
Stelle sicher, dass das korrekte source_format übergeben wird. Du musst die Ansible Collection nicht aktualisieren.

Ich verwende cloudscale-go-sdk in meiner Go Applikation, was muss ich tun?
Wenn du damit Custom Images importierst, musst du sicherstellen, dass das korrekte source_format übergeben wird. Die Dependency muss nicht aktualisiert werden.

Ich verwende cloudscale-python-sdk in meiner Python Applikation, was muss ich tun?
Wenn du damit Custom Images importierst, musst du sicherstellen, dass das korrekte source_format übergeben wird. Die Dependency muss nicht aktualisiert werden.