Vraag Hoe de Heartbleed-bug (CVE-2014-0160) in OpenSSL te patchen?


Vanaf vandaag fout in OpenSSL is gevonden met betrekking tot versies 1.0.1 door 1.0.1f (inclusief) en 1.0.2-beta.

Sinds Ubuntu 12.04 zijn we allemaal kwetsbaar voor deze bug. Om dit beveiligingslek te repareren, moeten getroffen gebruikers updaten naar OpenSSL 1.0.1g.

Hoe kan elke getroffen gebruiker deze update toepassen? nu?


152
2018-04-07 22:17


oorsprong


Heb je een getroffen versie van openssl? - Braiam
Ik heb de gepatchte versie 1.0.1-4ubuntu5.12 en ik heb de apache-service opnieuw gestart, maar filippo.io/Heartbleed testen op mijn site zegt nog steeds dat ik kwetsbaar ben. Enig idee waarom?
@Mat Ik weet niet wat die site test, maar misschien wordt gedetecteerd dat u een oude sleutel gebruikt. Omdat de sleutel mogelijk is gelekt, moet u deze regenereren. - Gilles
Je wilt OpenSSL echt niet updaten naar nieuwe versies in de groothandel, dat is ongelofelijk pijnlijk. Veel eenvoudiger is om gewoon het bijgewerkte pakket te installeren dat het probleem oplost: ubuntu.com/usn/usn-2165-1 - sarnold
heb je je services opnieuw gestart na het upgraden? - Axel


antwoorden:


Beveiligingsupdates zijn beschikbaar voor 12.04, 12.10, 13.10 en 14.04 zien Ubuntu-beveiligingsmededeling USN-2165-1.

Dus eerst moet u de beschikbare beveiligingsupdates toepassen, bijvoorbeeld door te draaien

sudo apt-get update
sudo apt-get upgrade

vanaf de opdrachtregel.

Vergeet niet om herstarten de services (HTTP, SMTP, etc.) die de betreffende OpenSSL-versie gebruiken, anders bent u nog steeds kwetsbaar. Zie ook Heartbleed: wat is het en wat zijn opties om het te verminderen? op Serverfault.com.

De volgende opdracht toont (na een upgrade) alle services die opnieuw moeten worden opgestart:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Daarna, je moet regenereer alle SSL-sleutels van de server, en evalueer vervolgens of uw sleutels mogelijk zijn gelekt, in welk geval aanvallers vertrouwelijke informatie van uw servers hebben kunnen halen.


141
2018-04-07 22:46



Ik weet niet zeker of dit werkt op Ubuntu 12.04.4 LTS. Na volledige update, openssl version geeft OpenSSL 1.0.1 14 Mar 2012. Dat is niet de gepatchte versie, toch? Of mis ik het verkeerd? - Paul Cantrell
Wat te doen met Ubuntu 13.04? Geen bijgewerkte openssl beschikbaar :-( - Frodik
Op Ubuntu 12.04 geeft zelfs de vaste versie van OpenSSL de versie weer 1.0.1 14 Mar 2012. Lezen Crimi's antwoord om erachter te komen of uw installatie de oplossing bevat. - dan
Bedankt, @dan! Resummariseer @ crimi's antwoord hier: als je rent dpkg -l | grep ' openssl ' en je krijgt 1.0.1-4ubuntu5.12 dan ben je goed om te gaan. - Paul Cantrell
Patchen en herstarten is niet genoeg. U moet de sleutels opnieuw genereren en beoordelen of uw sleutels zijn gelekt, evenals ander vertrouwelijk materiaal. Zie b.v. Bedoelt Heartbleed nieuwe certificaten voor elke SSL-server? - Gilles


De bug staat bekend als heartbleed.

Ben ik kwetsbaar?

Over het algemeen wordt dit beïnvloed als u op een bepaald moment een server uitvoert waarvoor u een SSL-sleutel hebt gegenereerd. De meeste eindgebruikers worden niet (direct) getroffen; Firefox en Chrome gebruiken in ieder geval geen OpenSSL. SSH wordt niet beïnvloed. De distributie van Ubuntu-pakketten wordt niet beïnvloed (het is afhankelijk van GPG-handtekeningen).

U bent kwetsbaar als u een server gebruikt die OpenSSL-versies 1.0-1.0.1f gebruikt (behalve natuurlijk de versies die werden gepatcht sinds de fout werd ontdekt). De getroffen Ubuntu-versies zijn 11.10 oneiric tot 14.04 vertrouwde pre-releases. Het is een implementatiefout, geen fout in het protocol, dus alleen programma's die de OpenSSL-bibliotheek gebruiken, worden beïnvloed. Als u een programma hebt dat is gekoppeld aan de oude 0.9.x-versie van OpenSSL, wordt dit niet beïnvloed. Alleen programma's die de OpenSSL-bibliotheek gebruiken om het SSL-protocol te implementeren, worden beïnvloed; programma's die OpenSSL gebruiken voor andere dingen worden niet beïnvloed.

Als u een kwetsbare server hebt uitgevoerd die is blootgesteld aan internet, kunt u overwegen deze te gebruiken, tenzij uw logbestanden geen verbinding hebben sinds de aankondiging op 2014-04-07. (Dit gaat ervan uit dat het beveiligingslek niet is geëxploiteerd voordat het is aangekondigd.) Als uw server alleen intern is blootgesteld, is het afhankelijk van de andere beveiligingsmaatregelen of u de sleutels moet wijzigen.

Wat is de impact?

De bug staat toe elke klant wie kan verbinding maken met uw SSL-server om ongeveer 64 kB geheugen van de server op te halen. De client hoeft op geen enkele manier te worden geverifieerd. Door de aanval te herhalen, kan de client verschillende delen van het geheugen in opeenvolgende pogingen dumpen.

Een van de kritieke gegevens die de aanvaller mogelijk kan achterhalen, is de SSL-privésleutel van de server. Met deze gegevens kan de aanvaller zich voordoen als uw server.

Hoe herstel ik op een server?

  1. Neem alle betrokken servers offline. Zolang ze worden uitgevoerd, lekken ze mogelijk kritieke gegevens.

  2. Upgrade de libssl1.0.0 pakketen zorg ervoor dat alle betrokken servers opnieuw worden opgestart.
    U kunt controleren of de getroffen processen nog steeds worden uitgevoerd met `` grep 'libssl.(geschrapt) "/ proc // maps`

  3. Genereer nieuwe sleutels. Dit is nodig omdat de bug een aanvaller mogelijk de oude privésleutel heeft gegeven. Volg dezelfde procedure die u in eerste instantie hebt gebruikt.

    • Als u certificaten gebruikt die zijn ondertekend door een certificeringsinstantie, dient u uw nieuwe openbare sleutels in bij uw certificeringsinstantie. Wanneer u het nieuwe certificaat ontvangt, installeert u het op uw server.
    • Als u zelfondertekende certificaten gebruikt, installeert u deze op uw server.
    • Hoe dan ook, verplaats de oude sleutels en certificaten uit de weg (maar verwijder ze niet, zorg er gewoon voor dat ze niet meer wennen).
  4. Nu dat u nieuwe compromisloze sleutels hebt, kunt u breng je server online terug.

  5. Intrekken de oude certificaten.

  6. Schadebeoordeling: alle gegevens die in het geheugen van een SSL-verbindingsproces zijn opgeslagen, zijn mogelijk gelekt. Dit kan gebruikerswachtwoorden en andere vertrouwelijke gegevens omvatten. U moet evalueren wat deze gegevens kunnen zijn.

    • Als u een service gebruikt waarmee wachtwoordverificatie mogelijk is, moeten de wachtwoorden van gebruikers die iets met elkaar hebben verbonden voordat het beveiligingslek werd aangekondigd, als aangetast worden beschouwd. (Een beetje eerder, omdat het wachtwoord een tijdje ongebruikt in het geheugen is gebleven.) Controleer uw logbestanden en wijzig de wachtwoorden van een getroffen gebruiker.
    • Maak ook alle sessiecookies ongeldig, omdat deze mogelijk zijn aangetast.
    • Clientcertificaten worden niet aangetast.
    • Alle gegevens die sinds het begin van het beveiligingslek zijn uitgewisseld, zijn mogelijk in het geheugen van de server bewaard en zijn mogelijk daarom naar een aanvaller uitgelekt.
    • Als iemand een oude SSL-verbinding heeft vastgelegd en de sleutels van uw server heeft opgehaald, kunnen deze nu hun transcript ontsleutelen. (Tenzij PFS was verzekerd - als je het niet weet, was het dat niet.)

Hoe herstel ik op een client?

Er zijn maar weinig situaties waarin clienttoepassingen worden beïnvloed. Het probleem aan de serverzijde is dat iedereen verbinding kan maken met een server en de bug kan misbruiken. Om een ​​klant te kunnen exploiteren, moet aan drie voorwaarden worden voldaan:

  • Het clientprogramma heeft een versie met fouten in de OpenSSL-bibliotheek gebruikt om het SSL-protocol te implementeren.
  • De client is verbonden met een kwaadwillende server. (Dus bijvoorbeeld als u verbonden bent met een e-mailprovider, is dit geen probleem.) Dit moest gebeuren nadat de servereigenaar zich bewust werd van de kwetsbaarheid, dus vermoedelijk na 2014-04-07.
  • Het clientproces had vertrouwelijke gegevens in het geheugen die niet met de server werden gedeeld. (Dus als je net bent weggerend wget om een ​​bestand te downloaden, waren er geen gegevens om te lekken.)

Als u dat tussen UTC 2014-04-07 en uw OpenSSL-bibliotheek hebt gedaan, overweeg dan dat alle gegevens in het geheugen van het clientproces in gevaar zijn.

Referenties


71
2018-04-08 10:02



Ik geloof niet dat "alleen de serverzijde van SSL / TLS-verbindingen wordt beïnvloed" waar is. openssl.org/news/secadv_20140407.txt zegt dat het geheimen van zowel klant als server kan onthullen. ubuntu.com/usn/usn-2165-1 stemt. De kans dat u clientcertificaten gebruikt terwijl u verbinding maakt met een kwaadwillende server is klein, maar de mogelijkheid bestaat. - armb
@armb Je maakt een goed punt. Het maakt niet eens uit of clientcertificaten worden gebruikt, het datalek is niet gerelateerd aan het gebruik van certificaten. ik heb riepen de hulp in van professionals. - Gilles
Clientcertificaten zijn het geval waarin u privésleutels lekt, maar ja, wachtwoorden, autorisatiecookies, etc. kunnen toch lekken. Echter, met een op OpenSSL gebaseerde client zoals curl of wget in typisch gebruik, zou je geen geheimen hebben voor andere sites in het geheugen tijdens het verbinden met een kwaadwillende server, dus in dat geval denk ik dat de enige lekkage zou zijn als je de klant geheimen zou geven anticiperend op het geven van een legitieme site, en Heartbleed lekte ze tijdens handshake voordat certificaatverificatie aantoont dat je niet verbonden bent met de juiste site. - armb
@ Gilles Misschien bent u geïnteresseerd in de antwoorden op Welke klanten zijn bewezen kwetsbaar te zijn voor Heartbleed?. Ik heb "interessant" geheugen weten te winnen op nginx (proxy-modus), wget, links en andere. - Lekensteyn
@ MuhamedHuseinbašić Het pakket openssl bevat opdrachtregelprogramma's. Het wordt niet gebruikt door applicaties die de OpenSSL-bibliotheek gebruiken om het SSL-protocol (zoals Apache) te implementeren. Maar u moet alleen de beveiligingsupdates van de distributie toepassen. - Gilles


Om te zien welke OpenSSL-versie is geïnstalleerd op Ubuntu run:

dpkg -l | grep openssl

Als de uitvoer van de volgende versie wordt weergegeven, moet een patch voor CVE-2014-0160 worden opgenomen.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Kijken naar https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12, het laat zien welk soort bugs opgelost zijn:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...

40
2018-04-08 06:40



Ik heb een upgrade uitgevoerd en krijg versie 5.12, maar deze tool zegt me nog steeds dat ik kwetsbaar ben filippo.io/Heartbleed Gedachten? - toxaq
Ik heb onze bijgewerkte servers aan deze kant getest en het vertelde me dat ik niet ben beïnvloed. Heeft u uw systeem opnieuw opgestart, of weet u tenminste zeker dat alle noodzakelijke processen opnieuw zijn gestart? - crimi
Na het updaten van de OPENSSL hoefde ik alleen maar de apache-service opnieuw te starten, maar sierlijk hielp niet. Ik moest gaan en opnieuw opstarten door te gebruiken sudo service apache2 restart - Tom Hert
Ik heb net de oorzaak van mijn kwetsbaarheid gevonden: ik had mod-spdy-bèta geïnstalleerd. Na het verwijderen en opnieuw opstarten van apache zijn alle tests nu groen. - Andreas Roth
Updaten openssl repareert geen applicaties zoals Apache, Nginx of postfix. Je moet updaten libssl1.0.0 en herstart ze zoals uitgelegd in andere berichten. - tnj


Als jouw apt-get-repositories bevat geen voorgecompileerde verzameling 1.0.1g OpenSSL versie, dus download gewoon de bronnen van de officiële website en compileer deze.

Onder de enkele opdrachtregel voor het compileren en installeren van de laatste openssl-versie.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Vervang het oude openssl binaire bestand door het nieuwe via een symlink.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Je bent helemaal goed!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Zie dit blogpost.

NB: Zoals vermeld in de blogpost, lost deze oplossing geen "Nginx- en Apache-server op die opnieuw moeten worden gecompileerd met 1.0.1g openSSL-bronnen".


17
2018-04-08 02:18



Zoals gewoonlijk biedt Ubuntu niet de nieuwe upstream-versie, maar patcht de versies voor alle ondersteunde releases om de wijzigingen tot een minimum te beperken. - Florian Diesch
Opmerking: Zorg ervoor dat u uw server opnieuw opstart na het updaten van OpenSSL. Apache en Nginx namen het nieuwe lib op en de kwetsbaarheid was gesloten. - dAngelov
Heh, nu ik de tijd neem om het te lezen gegevens van dit bericht ben ik zelfs nog meer ontzet - het downloaden van een tarball van een willekeurig punt op het internet, het uitpakken en het uitvoeren van delen ervan als root is gewoon roekeloos gedrag. Het zou iets beter zijn als de tarball-handtekeningen zouden worden gedownload en gecontroleerd, maar het is een moeilijke vraag om ervoor te zorgen dat de handtekeningen worden gevalideerd door de juiste sleutel. Distributies zijn al bezig met het waarborgen van veilige herkomst van tarballs en patches. Bedankt. - sarnold
het is misschien een goed idee om vanaf NU te compileren en later een nieuwere te installeren van apt, op die manier is je veiliger dan zonder te verwachten op oudere versies van ubuntu, hoe dan ook, gewoon mijn twee cent - nwgat
@sarnold openssl.org lijkt geen willekeurige plaats om de bron voor openssl te downloaden. Canonical zou dit onnodig moeten maken, maar openssl.org moeten de gezaghebbende stroomopwaarts zijn om vanuit te werken. - Rustavore


Voor diegenen die geen pakketbrede upgrade willen doen. Ik heb vandaag een aantal van deze gidsen gelezen en apt-get upgrade openssl === apt-get upgrade hiermee worden alle beveiligingsoplossingen toegepast die door uw machine zijn vereist. Prachtig, tenzij je expliciet ergens op een oude pakketversie leunt.

Dit is de minimale actie vereist op Ubuntu 12.04 LTS met Apache 2:

  • Ga naar dit adres en bewijzen dat je de kwetsbaarheid hebt. Gebruik het DIRECTE EXTERNE ADRES VAN UW WEB SERVER. Als u een loadbalancer (bijvoorbeeld ELB) gebruikt, neemt u mogelijk niet rechtstreeks contact op met uw webserver.

  • Voer de volgende 1 liner uit om pakketten bij te werken en opnieuw op te starten. Ja, ik zag alle gidsen zeggen dat je later dan 4 april 2014 een tijdstempel moet hebben, dit lijkt mij niet het geval te zijn.

    apt-get update && apt-get install openssl libssl1.0.0 && /etc/init.d/apache2 restart

  • Controleer of u geschikte pakketversies hebt geïnstalleerd en controleer uw webserver nogmaals op het beveiligingslek.

De belangrijkste pakketten zijn als volgt, ik heb deze informatie bepaald met behulp van de onderstaande opdracht en vervolgens de cruft weggeschreven (u hoeft niet zo veel te weten over de toestand van mijn machines).

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12 mag de kwetsbaarheid NIET bevatten. Zorg ervoor dat dit het geval is door opnieuw naar de onderstaande website te gaan en uw webserver te testen.

http://filippo.io/Heartbleed/


12
2018-04-08 21:56



Het gebruik van een externe site om een ​​kwetsbaarheid in een server te bewijzen lijkt de verkeerde benadering voor mij te zijn. - Rinzwind
Externe kwetsbaarheidstestscripts worden tegenwoordig steeds gebruikelijker. Het doet precies wat een intern script doet, de verbinding wordt net gestart vanuit een externe webserver. U kunt naar sites zoals WhiteHatSecurity.com kijken voor een voorbeeld van een programma dat alle verbindingen op afstand initieert. Er zijn gevallen waarin dit niet zou vliegen, bijvoorbeeld het testen van netwerkkwetsbaarheid, maar voor het testen van een forward facing webserver (die over het algemeen een SSL-server zal zijn) is dit bijna ideaal. - Adrian
Waarom zou u het pakket installeren als het wordt geüpgraded? - Braiam
apt-get install openssl libssl1.0.0 deed het voor mij. hardlopen openssl version -a laat nu zien: built on: Mon Apr 7 20:33:29 UTC 2014 - topher
"Externe kwetsbaarheidstestscripts worden tegenwoordig steeds normaler." Dat opent de mogelijkheid dat die externe site mijn systeem misbruikt: alles wat ze moeten weten is mislukt en mijn systeem hacken voordat ik het patchen. Nee dit is niet de juiste manier. (en ja host ik mijn eigen sites met apache en openssl). - Rinzwind


Ik heb veel commentatoren opgemerkt die dringend hulp nodig hebben. Ze volgen de instructies en upgraden en rebooten en zijn nog steeds kwetsbaar bij het gebruik van sommige testwebsites.

U moet controleren om te voorkomen dat pakketten in de wacht worden gezet, zoals libssl.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Om deze te upgraden apt-mark unhold libssl1.0.0 (bijvoorbeeld). Upgrade dan: apt-get upgrade -V. Herstart vervolgens de getroffen services.


11
2018-04-08 17:51