Ubuntu Server 20.04-installer toonde plaintext-encryptiewachtwoord in logboek

De Ubuntu Server 20.04-installer bevatte een beveiligingslek waardoor het encryptiewachtwoord van een schijfvolume na installatie in plaintext werd getoond in het installatielogboek. De bug is inmiddels verholpen.

Het beveiligingslek, waardoor onbevoegde gebruikers de wachtwoorden konden lezen, krijgt de code CVE-2020-11932. Canonicals Subiquity-installer, die alleen wordt gebruikt in de servervariant van Ubuntu, registreerde de LUKS-encryptiewachtwoorden in plaintext in het installatielogboek. Vervolgens werd de passphrase naar de schijf geschreven, waardoor deze na installatie te zien was in enkele bestanden in de /var/log/installer-directory, meldt een gebruiker. Hierdoor konden onbevoegde gebruikers volgens Canonical wellicht de passphrase bemachtigen.

Het lek is inmiddels verholpen in update v20.05.2. Die update is doorgevoerd in de Snap Store. Gebruikers die Ubuntu Server 20.04 proberen te installeren met een actieve internetverbinding, krijgen bij installatie de mogelijkheid om de Subiquity-installer te updaten. Ubuntu 20.04 voor desktops maakt zoals eerder vermeld geen gebruik van Subiquity en heeft dus geen last van het lek.

Canonical heeft in de afgelopen jaren gewerkt aan zijn Subiquity-installer. Het bedrijf stapte met de release van Ubuntu Server 20.04 definitief over op zijn eigen installatieprogramma, zo schrijft Phoronix. Voorheen konden gebruikers kiezen tussen Subiquity en de standaard Debian-installer, maar dit is niet langer mogelijk.

Reacties (51)

[MadEgg]

Dit wordt dus in de log-directory tijdens de installatie geschreven? Het tmpfs bestandssysteem van de live USB-stick? Dan kan dus alleen dit wachtwoord onderschept worden tíjdens de installatie? Wel een flinke fout, maar de impact blijft dan beperkt.

[LEDfan]

Na de installatie worden de logs naar de echte disk gekopieerd, zie: https://github.com/Canoni...uity/releases/tag/20.05.2

[MadEgg]

Ai, dat maakt het een stuk kwalijker. En het is dan vast niet alleen door root leesbaar...

[Waxyen]

Ja het is kwalijk. Het is jammer dat dit door de beta's gekomen is. Maar tegelijkertijd is het niet een slim idee om op de meest belangrijke apparaten de nieuwste versies te installeren. Ik wacht ook altijd even met MacOS updates, Windows updates of welke updates dan ook.

[MadEgg]

Op zich mee eens, aan de andere kant: dit is de final release van een server OS. Iémand zal dit ooit als eerste moeten installeren en tegen deze of andere fouten aanlopen, als ze er niet in de béta uitgehaald zijn. Ik zou wel even wachten met de mission critical servers maar je moet toch ergens beginnen. Natuurlijk kun je dit aan anderen overlaten maar als iedereen dat doet...

[Magic]

De meeste “echte” Ubuntu servers maken vaak gebruik van LTS versies. Deze kun je pas na de .1 release updaten.

[GekkePrutser]

Maar een server zal niet zo gauw FDE gebruiken met paswoord omdat deze de invoer van een paswoord bij bootup vereist.

[Archcry]

Je kan je data schijf ook encrypten en automatische decrypten met /etc/crypttab. Het betreft dus niet alleen fde.

[Reactie gewijzigd door Archcry op 22 juli 2024 16:51]

[GekkePrutser]

Klopt, maar in dat geval gebruik je over het algemeen geen paswoord, dan gebruik je een keyfile. En de setup wizard van Ubuntu verzorgt niet dit soort configuratie Die is puur voor desktop gebruik met een paswoord dat je bij het booten invoert.

[sfranken]

Mua, met de .1 komt de update pas door in de officiele kanalen (of beter: via de officiele manier). Hiervoor kun je echter naar hartenlust updaten met do-release-upgrade -d, dan trekt 18.04 gewoon de volgende versie (in dit geval 20.04.0) binnen en installeert deze zonder gemopper.

Is dat verstandig? Nee, lijkt me niet.

[robkorv]

Ik weet niet of ze dit officieel aan raden, maar doorgaans wachten de meeste professionals op de eerste point release voordat ze met een nieuw Ubuntu versie aan de slag gaan.

[TheVivaldi]

Inderdaad. En ik denk bijna overal wel? Eerste macOS-puntversie, eerste Android-puntversie, etc.

[Vibonacci]

Dan moeten ze 20.04 niet al LTS noemen maar pas 20.04.1

[Waxyen]

Daar kan ik mij volledig in vinden. Als gebruiker/system engineer loop je helaas altijd wel een risico. Daarbij moet de keuze dan ook erg bewust gemaakt worden.

[teek2]

Precies, en om nog voorzichtiger te zijn gaan ze pas de 18.04 gebruikers melden dat er een update is bij 20.04.1, en die release duurt nog even. Goed, voor bestaande gebruikers is deze bug denk ik ook niet relevant...

[foxofinfinety]

Nee, het komt in /var/log/installer, dus hij staat op het geïnstalleerde systeem.

[AverageNL]

Zoals @LEDfan zegt, worden de logs inderdaad naar de disk gekopieerd (naar de /var/logs/installer-directory, om precies te zijn), waardoor ze ook na installatie ingezien kunnen worden.

[Reactie gewijzigd door AverageNL op 22 juli 2024 16:51]

[ataryan]

Die installer, viel mij op, is zowiezo een beetje buggy. Installeren zonder Internet verbinding zorgt bij mij voor een crash van de installer bij het Ethernet scherm. Nieuwigheid. En hoe spannend is dat nou he, zo'n text scherm installer. #90s

[Archcry]

Tjah, dat is wat ik ook altijd zeg. Toch lijkt het veel mensen af te schrikken. Persoonlijk vind ik de installer van bijvoorbeeld Debian ook prima werken. Persoonlijk installeer ik een Linux distributie ook wel eens zelf van scratch zonder installer. Dat laatste is wel oprecht iets lastiger moet ik toegeven.

[Reactie gewijzigd door Archcry op 22 juli 2024 16:51]

[Blokker_1999]

Ah de debian installer. Waar ik, en vele anderen, blindelings doorheen kunnen navigeren. Als men er schrik van heeft omdat het tekst based is, dan kan men imho beter wegblijven van Linux of voor distributies kiezen die echt de nadruk leggen op gebruiksgemak.

[DLGandalf]

Ik kan u verzekeren dat de werking van de text based installer voor automatiserings doeleinden echt een verschrikking is. De hoeveelheid bugs die ik heb moeten oplossen in een datacenter omgeving voor pxe installs in de debian-installer is bijna niet meer op 2 handen te tellen.
And yes, I gave back, o.a. https://bugs.launchpad.ne...ub-installer/+bug/1771845

Ik ben blij dat canonical het aandurft om iets nieuws te maken. (normaal ben ik niet zo van het not-invented-here, maar in dit geval is de debian-installer voor een developer een verschrikking om nog aan verder te knutselen.)

[Verwijderd]

Dit gaat volgens mij ook over een text-installer. Want volgens mij heeft de server editie van Ubuntu helemaal geen grafische installer.

[shades]

klopt. text-based. Ik zou ook niet weten waarom een server installer grafisch zou moeten zijn..

[Reactie gewijzigd door shades op 22 juli 2024 16:51]

[GeroldM]

Alle Linux servers in mijn beheer hebben per definitie helemaal geen grafische schil geinstalleerd. Heb een donkerbruin vermoeden dat ik hierin echt niet de enige ben.

Zie het probleem van alleen een text-installer ook niet echt. Zolang de opties duidelijk zijn omschreven, dan boeit het ook niet. Maar goed, er zullen er altijd een paar personen bijzitten, die menen dat iets alleen modern is als het het een combinatie van node.js/Electron is en in een browser moet plaatsvinden.

[MiesvanderLippe]

Ik heb een stukje van de source code van die installer doorgelezen omdat ik tegen een probleem aan loop. Het is gewoon ronduit een hobbyproject. Zit bijvoorbeeld een ja-nee vraag in die je niet met nee kan beantwoorden. Het zou enterprise software moeten zijn maar zelfs voor mij als hobbyist is het tamelijk onwerkbaar. Dat is nog los van de documentatie...

https://answers.launchpad.net/ubuntu/+question/690496

[shades]

Ik ben in ieder geval wel blij dat php 7.4 en mariadb 10.4 standaard in de repo zit. Op 18.08 moest je eerst de repo van ondrej voor php7.4 toevoegen en voor de meest recente stable van mariadb moest je de repo van mariadb zelf toevoegen. Dat hoeft nu niet meer (tot beide weer naar een hogere versie zijn gebracht uiteraard. Dan begint het weer opnieuw)
Bovendien; nu iedereen weet dat die in de logfile staat: logfile verwijderen.

[Crim]

Ik heb liever in de repo van het OS een oudere versie, het is vaak makkelijker om een nieuwere versie te krijgen met andere repo's dan een oudere versie. En voor wat heb je momenteel nou perse PHP 7.4 of MariaDB 10.4 nodig. De meeste software die ik tegenkom draait op MySQL 5.7 (MariaDB 10.2) en PHP 7.2.

[ataryan]

ik gebruik geen installed services binnenin de ubuntu host install. stateless en statefull data mixen ben ik in 2015 mee gestopt. ubuntu is voor mij al jaren alleen een docker/k8s service hosting platform. base install+ssh is meer dan voldoende. de rest komt via policies aanwaaien. maar ieder z'n feestje. die installer van 20.04 is wel van een nieuw niveau van brak. dat dan weer wel. je zou toch denken dat ze een text installer na 25+ jaar goed draaiend krijgen ?

[Muna34]

De fix is dan wel al doorgevoerd. Fouten blijven menselijk en gelukkig is er adequaat op gereageerd. Zolang er snel en juist wordt gereageerd vind ik het niet super kwalijk. Neemt niet weg dat ze dit moeten meenemen in hun process voor de waarborging van kwaliteit.

[Eonfge]

Ook belangrijk: De meeste Dev-Ops zijn niet te haastig met het uitrollen van nieuwe versies. Het aantal productie systemen dat nu al op 20.04 draait zal dus nog wel heel beperkt zijn. Vorig jaar bijvoorbeeld een server gemigreerd van 16.04 naar 18.04 omdat dit beter aan sloot op andere servers die werden opgetuigd met 18.04. Het upgraden van de servers van 18.04 naar 20.04 laat dus nog wel een jaar op zich wachten.

Ik vindt mijzelf dan nog wel een van de vlotte. Dit jaar ook van Java 8 naar Java 11 gegaan. Terwijl menig enterprise daar nu nog niet over durft na te denken.

Edit. Vereist altijd wel wat mentale gymnastiek. Servers gebruiken nog yum terwijl ik hier lokaal dnf heb. En daarnaast nog wat spul welke naar apt luistert. apt-get is nu wel uitgefaseerd.

[Reactie gewijzigd door Eonfge op 22 juli 2024 16:51]

[Muna34]

Zeker waar. Ik denk ook wel dat het mee zal vallen. Misschien dat er wel experimentele productie systemen zijn die nu al 20.04 draaien en in dat geval kunnen ze de fix installeren. Schade blijft redelijk beperkt. Net zoals je al aangeeft is het juist dat ze oudere versies hanteren voor stabiliteit.

[goarilla]

Voor een OS upgrade. Upgrade jij in-place via een CM recept of schrap en herbouw jij de volledige machine ?

[Eonfge]

Wisselt een beetje. Soms is beter om gewoon een tweede server op te tuigen en in te richten, en deze dan op het eind om te wisselen met de oude server. Ik heb echter ook wel eens een kopie gemaakt van een server, daar een test-upgrade op gedaan, en toen dat beviel gewoon de server zelf geupgradet.

Is ook een kosten-baten-risico analyse. Tweede optie is natuurlijk goedkoper en gaat sneller.

[glatuin]

Heb vorige week vrijdag nog Ubuntu server 2004 geïnstalleerd. In mijn installer logs zie ik echter geen plain text wachtwoord staan. Issue is er dus kennelijk niet altijd. Tenzij vrijdag die patch er al was (heb na install meteen alles bijgewerkt).

[Verwijderd]

Heb je ook een encrypted disk op dat systeem? Want over dat wachtwoord gaat het namelijk.

[glatuin]

Haha inderdaad, nee heb de disk niet encrypted. Wel raar juist als je encrypt ben je kwetsbaar. gelukkig is het nu gepatched.

[MadEgg]

Nou ja... het gaat om het encryptiewachtwoord. Er vanuit gaande dat je geen wachtwoorden hergebruikt (en dat zou je hoe dan ook niet moeten doen) is de kwetsbaarheid dat het wachtwoord van je encryptie versleuteld op het encrypted volume staat. Als iemand dat zou onderscheppen kan hij het bestandssysteem ontsleutelen. Dan ben je exact even ver als je geweest zou zijn als je geen versleuteling zou hebben gebruikt.

Als je wél het wachtwoord ook voor andere zaken gebruikt dan ben je verder van huis, want dan is een wachtwoord waarmee je ook andere dingen kunt doen uitgelekt.

[oef!]

Volgens mij treedt het alleen maar op als je tijdens de installer hebt gekozen voor encryptie op de disk. Ik heb zelf 2 dagen geleden een installatie gedaan op een onversleutelde disk en ik zie ook geen referenties naar deze sleutel.

[Archcry]

Jammer dat Ubuntu toch altijd wel weer iets heeft bij een nieuwe release. In Ubuntu 12.04 de beruchte (en onveilige) searchbar die je gegevens met Amazon deelde (bron) die in Ubuntu 16.04 (eindelijk!) opt-in werd (bron). In Ubuntu 17.04 uefi tools die geflagged waren als "dangerous" door upstream en de uefi (bios) van Lenovo laptops brickte (bron). En nu weer dit.

Ze hebben nu in ieder geval voor het eerst in hun line-up een officiele LTS kernel gebruikt in plaats van een EOL kernel die ze zelf patchen.

[Reactie gewijzigd door Archcry op 22 juli 2024 16:51]

[Niemand_Anders]

Normaal gesproken kunnen alleen admin/root achtige personen inloggen op een server en die zijn dus bevoegd. Ik ben best wel benieuwd wie op hun server onbevoegde (reguliere) gebruikers toelaten op hun servers?

Op onze (Debian) servers kun je alleen inloggen met SSH als er een authorized key is geplaatst..
Hoewel het uiteraard niet netjes is dat een wachtwoord voor encryptie als plaintext in de logs terecht komt, is lijkt mij het reële risico op uitleggen van het wachtwoord minimaal..

[Verwijderd]

Even gekeken, maar `installer-journal.txt` heeft permissies 644 in een dir in `/var/log` met permissies 755.
Dus zodra wie dan ook op die server kan komen, of door login, of door een crappy web project dat buiten zijn root kan komen, kan dat bestand inzien.

Dat is best kwalijk, hoor.

Want ook een bevoegde reguliere gebruiker heeft niets te maken met het encryptie wachtwoord van de schijven.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:51]

[sam_vde]

Inderdaad zeer kwalijk. Blijft de vraag wat je er vervolgens mee kan doen als reguliere gebruiker.

Ik vermoed/hoop dat de meeste server installs zeer spaarzaam omspringen met sudo rechten etc. dus ik hoop dat de impact voor de meeste admins beperkt blijft tot het aanpassen van de bestaande passphrase.

Maar dat maakt dit nu ook weer geen goed nieuws natuurlijk.

[Verwijderd]

Schijfencryptie is om te voorkomen dat data benaderd kan worden als een schijf of server ontvreemd wordt.
Duur kun je dus vervolgens niet meer van op aan, met de mogelijkheid dat je encryptie wachtwoord ergens rondzwerft.

Kortom zodra je niet weet wie je wachtwoord allemaal wel en niet weet, heeft de encryptie eigenlijk niet zo veel nut meer.

Edit: Het logbestand is door *iedereen* in te zien. owner, groep en others hebben allemaal read rechten in een directorystructuur waar owner, groep en others allemaal execute rechten hebben.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:51]

[The Zep Man]

Kortom zodra je niet weet wie je wachtwoord allemaal wel en niet weet, heeft de encryptie eigenlijk niet zo veel nut meer.

Ja en nee. Het wachtwoord is een manier om tot het werkelijke sleutelmateriaal te komen. Een nieuw LUKS wachtwoord kan toegevoegd worden en het oude wachtwoord kan verwijderd worden. Zolang er geen backup is van de oude LUKS header (wat een gewone gebruiker niet kan maken) is het oude wachtwoord waardeloos.

Zo hoef je niet een hele disk opnieuw te versleutelen.

[fastedje]

Op RHEL/Centos is de /var/log directory alleen te openen en te lezen door root, soms vervelend maar precies om.dit soort fouten is het toch geen verkeerde aanpak.

[Douweegbertje]

Het is helemaal niet vreemd dat reguliere gebruikers van een server toegang hebben met een non-root account. Zelfs zonder sudo zou je in de meeste gevallen meuk in de /var/log dir kunnen zien.

[Trommelrem]

Opzich kan dit best positief zijn. Het installatiewachtwoord wordt immers na installatie altijd gewijzigd, en dan staat er een fake wachtwoord in de logfiles.

[Verwijderd]

Dit gaat niet om het installatie wachtwoord maar om het disk encryptie wachtwoord. Waar je dus voornamelijk iets aan hebt als je fysieke toegang tot de server/schijven hebt.

Ik moet heel eerlijk zeggen: volgens mij gebruiken bar weinig enterprises dit. Volgens mij moet je namelijk dit wachtwoord daadwerkelijk intypen voor Ubuntu weer opstart. Totaal kansloos natuurlijk bij een server. Die wil je gewoon een reboot kunnen geven waarna alle services weer moeten draaien...

[NielsFL]

Ah, alleen als je LUKS gebruikt. Dat is een meevallertje. Ik kies tegenwoordig de ZFS optie en zet dan achteraf ZFS encryptie aan.

[SlaSauS]

Doet me denken aan een bug in Ubuntu Breezy Badger 5.10 waarbij het root wachtwoord na installatie in de logbestanden terug was te zien: https://slashdot.org/stor...in-clear-text-with-ubuntu

Edit: bijbehorende T.net artikel: nieuws: Veiligheidsfout Ubuntu onthult password

[Reactie gewijzigd door SlaSauS op 22 juli 2024 16:51]

[MiKE_B]

Eerder deze week heb ik een Ubuntu 20.04 installatie op een server gedaan. Wat ik mooi vond is de optie om je ssh-pubkey van je Github account te kopiëren naar je `.ssh/authorized_keys` - ik wist helemaal niet dat je pubkeys op Github publiek zijn, maar kennelijk wel. Ik vond dit best een goed idee!

(aan de andere kant verwacht ik nog precies 0 installaties 'handmatig' te doen)