Dus alleen de gevolgen zijn ernstig, en niet het lek zelf... Het lekken van de private key die bij een certificaat hoort, is zelf dus niet zo ernstig... Waar zit de logica hier?
Als er ooit een lek een 10 moet krijgen op die schaal, is dit het wel. Daar is de hele wereld het wel over eens. Alléen Oracle denkt er dus anders over. Dat zegt waarschijnlijk voldoende over het bedrijf.
Nooit meer Oracle producten aanschaffen, zou ik zeggen. Dat is een te groot security risico voor je eigen bedrijf.

Niet alleen Oracle denkt hier zo over, ook de officiele CVE op NIST (https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160) kreeg een score van 5.3. Volgens de schaal die vulnerabilities rate klopt dit ook. De confidentialiteit en integriteit van de service kan misschien gebroken worden, maar de availability niet.

De schaal is niet fijlloos. Daarbuiten, ja het klopt dat je private keys kan bekomen, maar laat ons eerlijk zijn, je moet nog steeds succesvol een MiTM doen om er gebruik van te maken. Tenzij je een overheidsinstelling bent die stukken van het internet beheerd is dit onmogelijk om op een grote schaal te doen.

Berichtgeving in de reguliere media staat niet gelijk aan het dreigingsniveau van een kwetsbaarheid ;)

Wel geeft de waarde die Oracle hanteert iets aan over de impact van de kwetsbaarheden in hun eigen software, die regelmatig met een "10" worden ingeschaald.

Maanden? Dat lijkt mij wel zeer overdreven. Wat veel mensen in deze discussie vergeten is dat Heartbleed tot maximaal 64 KB kan lekken uit het geheugen! Dat betekent dat die gegevens al die tijd in het geheugen moeten hebben staan binnen hetzelfde proces waarin OpenSSL draait en dan ook nog eens net voorbij het adres moeten staan waar OpenSSL het codewoord in het geheugen heeft geplaatst.
Een server die zeer druk is, zal dan ook continu het betreffende geheugengebied "verversen" met nieuwe data, dus de mogelijkheid dat er data van een maand geleden in staat is dan al erg klein. Een server met weinig verkeer zou misschien jaren aan data kunnen bevatten, mits deze al jaren draait zonder enige updates of herstart. (Het herstarten van het proces is al voldoende!) Ook dat is onwaarschijnlijk.
De angst om het lekken van een private key is wel reeel, omdat OpenSSL deze nodig heeft. Deze staat dan ook in het geheugen. Of het voor of na het geheugenadres staat vanaf waar het lek plaatsvindt is dan maar de vraag. Het geheugen is in principe virtueel, dus lineair. Heartbleed lekt maximaal 64 KB aan data vanaf een bepaald punt in het geheugen en dat is het risico-gebied. Dus de kans is aanwezig, maar realistisch gezien vrij klein. Je zult behoorlijk wat pogingen moeten doen voordat je een key te pakken kunt krijgen. (Maar hackers zijn er wel toe bereid, dus een serieuze hacker gaat gewoon door tot hij raak schiet.)
Daarnaast moet je alle binnenkomende data ook nog omzetten naar informatie. Het is immers een ruwe geheugendump vol binaire data. Leesbare tekst zoals accountnamen, wachtwoorden en email adressen zijn wel herkenbaar. (Zeker als er geen speciale tekens in het wachtwoord zijn gebruikt!) Een binaire private key is echter lastiger te herkennen, hoewel het natuurlijk helpt als je van tevoren de key al kent en in ieder datablok gaat zoeken naar die key, zoals sommige onderzoekers doen om aan te tonen hoe schadelijk het is.
-
Het allerergste vind ik nog dat enkele bedrijven die onder Microsoft IIS draaien ook hebben besloten om aan de paniek mee te doen, terwijl zij geeneens OpenSSL gebruiken! Een Oracle database (of MySQL) achter een IIS webserver is gewoon nog steeds veilig. De risico-gebieden zijn alleen die delen van servers die blootgesteld zijn aan de "boze buitenwereld" en die gebruik maken van OpenSSL.

@Wim: De private keys zullen meestal niet 'los' in het geheugen staan, maar in een X509 certificaat 'formaat' en zijn zodanig weldegelijk hardstikke makkelijk te herkennen. Daarnaast kan 'maanden oude data' natuurlijk prima in geheugen staan, de leeftijd van de entry-date zegt niets of de last-processed date. En hoe hoger de doorvoersnelheid van de data hoe meer er dus per uur gelekt wordt; een idle server lekt minder data dan een drukke server. Als je toch al MitM kan uitvoeren, maakt dat echt niets meer uit.

En mbt 'alleen de external facing servers' patchen: Naief ! Iets lagere prio, ja, maar niets dom is echt struisvogel politiek; die al ín het wild' IS afgestraft.