... verwacht ik dat het snel wordt geupdate in alle repositories.
Voor Debian 4.0 (aka Etch, de huidige stable release) zijn updated packages al beschikbaar in de security repositories.
Maar het probleem is dat keys die met de foute openssl gegenereerd zijn voorspelbaarheid bevatten, maar die keys worden niet vervangen als je de updated packages installeert. Dat kan ook niet zomaar, want andere machines kunnen voor authenticatie of idenfiticatie afhankelijk van die keys zijn, en dat kan problemen geven als die zomaar veranderen. (Een ietwat kromme vergelijking is dat de sloten van je huis automatisch vervangen worden zonder dat je een nieuwe sleutel hebt)
De
Debian Security Advisory bevat gedetailleerdere informatie, waaronder een link naar
deze Debian pagina waar de key rollover van populaire software beschreven zal worden (de pagina is nu nog leeg).
Voor SSH bijvoorbeeld (want dat zal de meeste mensen treffen) gaat dat ongeveer als volgt:
De SSH host keys worden gebruikt om te bewijzen dat je SSH client ook daadwerkelijk inlogt op de SSH server waarop je in wilde loggen. Als een aanvaller deze keys kan voorspellen/raden, en hij weet zich (netwerktechnisch) tussen je SSH client en server te wurmen, dan kan hij een man-in-the-middle attack uitvoeren.
De SSH host keys zijn te vinden in /etc/ssh/ssh_host_* . Je kunt ze met ls -l inspecteren, als ze ouder zijn dan 2006-09-17 dan zouden ze in orde moeten zijn (ervan uitgaande dat de datum op je systeem klopt(e), etc).
Je kan nieuwe SSH host keys genereren met de volgende commando's (na eventueel de oude keys te backuppen):
# ssh-keygen -N '' -t dsa -f /etc/ssh/ssh_host_dsa_key
# ssh-keygen -N '' -t rsa -f /etc/ssh/ssh_host_rsa_key
SSH clients die je computer met de nieuwe keys al kenden zullen vanaf dat moment (terecht) klagen dat de SSH host key veranderd is. Je zal de client dan wijs moeten maken dat dat echt de bedoeling is.
Voor de OpenSSH commandline client kan dat door de host te verwijderen uit ~/.ssh/known_hosts en daarna opnieuw proberen in te loggen. SSH zal dan zeggen dat hij die host nog niet kent (klopt, je hebt hem verwijderd) en vragen of je hem wil accepteren. Als je gecontroleerd hebt dat de key fingerprint hetzelfde is als de fingerprint die ssh-keygen uitspuugde, dan kun je "yes" antwoorden.
Vergeet, als je gebruik maakt van public key authentication ("passwordless login"), ook niet de keys in ~/.ssh van de client machine aan te pakken, en de client host te verwijderen uit de ~/.ssh/authorized_keys op de server machine.
(Als bovenstaand verhaal niet duidelijk genoeg was, dan kun je waarschijnlijk beter even wachten tot die key rollover pagina van Debian een verhaal voor SSH bevat.)
edit:
Er zijn nieuwe updates voor de ssh, openssh-server en openssh-client packages. Deze updates helpen met het bovenstaande key verhaal voor SSH. Als je de updates installeert, dan krijg je ook een blacklist van zwakke keys (nieuw package: openssh-blacklist) welke op de volgende manieren gebruikt wordt:
- Tijdens installatie van de nieuwe updates wordt gecontroleerd of je SSH host keys (/etc/ssh/ssh_host_*) geblacklist zijn, en zo ja, dan zal de installer nieuwe host keys genereren.
- Public key authentication ("passwordless login") vanaf andere machines wordt gecontroleerd tegen de blacklist en geweigerd als de public key in de blacklist voorkomt. Passwordless logins vanaf accounts met een zwakke SSH user key werken dus niet meer na het installeren van deze updates.
De
Debian Security Advisory voor deze updates bevat gedetailleerdere informatie (waaronder ongeveer het hele SSH host key verhaal dat ik gisteravond hierboven heb geschreven).
Tot slot nog dit:
Als je apt-get of aptitude gebruikt om te updaten, dan kan het zijn dat hij openssh-server en openssh-client niet wil installeren omdat die op een extra package dependen (namelijk openssh-blacklist). Je krijgt dan iets a la "Kept back: openssh-client openssh-server".
In dat geval helpt het om dist-upgrade te doen in plaats van upgrade. Wat ook helpt is iets als apt-get install openssh-server doen, waarmee je duidelijk maakt dat je toch echt die nieuwe openssh-server wil, ook als dat openssh-blacklist meesleept. Wat ook kan is openssh-blacklist expliciet installeren en daarna nog eens upgrade doen.
edit2:
Meer leesvoer:
http://wiki.debian.org/SSLkeys
Zo te zien bevatten de door de foute openssl gegenereerde keys maar een bit of 16 aan randomness, wat passwordless logins die deze keys gebruiken makkelijk te bruteforcen maakt. Het is dus
zeer aan te raden om passwordless login setups goed te controleren. Keys verwijderen / opnieuw aanmaken, en vooral de ~/.ssh/authorized_keys op de doel-machines goed te inspecteren (of gelijk maar helemaal te verwijderen).
[Reactie gewijzigd door deadinspace op 24 juli 2024 04:16]