On 04/09/2014 12:10 PM, Paul van der Vlis wrote: Hoi,
> Zijn gnupg keys die zijn aangemaakt op Wheezy vulnerable m.b.t. de > openssl bug? > > Volgens mij gebruikt gnupg geen openssl of tls, maar ik hoor het graag > als jullie daar anders over denken. De beste informatie die ik over heartbleed kon vinden was dit: http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/ Over de impact: - met heartbleed krijgt een aanvaller een *willekeurig* blok van 64K uit het geheugen van de server - de aanvaller kan niet sturen welk blok 'ie ontvangt - de aanvaller kan de aanval onbeperkt herhalen Met andere woorden: in potentie kan *ALLES* wat in het geheugen van de server zit/zat gecompromitteerd zijn. Dat kunnen read/write caches zijn van gegevens op de disk, actieve sessies, sleutels van welke soort dan ook, ontsleutelde data, wachtwoorden die op dat moment gecheckt worden, wat dan ook. Op het internet zijn inmiddels scripts te vinden die blokjes geheugen doorzoeken naar specifiek zaken als (sessie)cookies. Ik weet niet hoe groot de impact in de praktijk is. Het blijft namelijk ook toevalszaak: de gegevens die een aanvaller zoekt, moeten maar net op dat moment in het geheugen zitten en dat blok geheugen moet dan maar niet het blok zijn dat de aanvaller ontvangt. Als een aanvaller specifiek naar 1 blok data op zoek is, dan is de kans om precies dat ene blok te krijgen op een server met 8GB aan geheugen De kans om precies het juiste blok data te krijgen kleiner dan 0,001%. Oftewel: je moet tienduizenden requests sturen en gigabytes aan data ontvangen voordat je een redelijke kans begint te krijgen om het blokje dat je zoekt te ontvangen. Een andere strategie voor een aanvaller is een aantal blokjes opvragen en dan kijken wat daar toevallig in zit. Je hebt een redelijke kans dat er wel wat vertrouwelijks in zit. Dat maakt het opvragen veel makkelijker maar de analyse van de ontvangen gegevens veel moeilijker: je moet goed weten waar je naar moet zoeken en in staat zijn om bijvoorbeeld het geheugen dat een database gebruikt te 'decoderen'. Op wat laaghangend fruit na, verwacht ik dat deze aanvalsroute alleen bruikbaar is voor aanvallers die er hooggeschoold personeel voor langere tijd aan kunnen en willen zetten. Maar niets garandeert je dat je meest geheime data niet al (al dan niet toevallig) gelicht is door een aanvaller. Om aan de veilige kant te zitten zou ik alle gegevens vervangen die, indien ze uitgelekt zijn, later nog de veiligheid in gevaar kunnen brengen. Denk dan aan: - Secret keys van welke soort dan ook (ssl, ssh, GPG) - Ongehashte wachtwoorden - Tokens van langdurige gebruikerssessies (voor zover die niet gehasht zijn op de server) Ik vind het nog wel een vraag of je de wachtwoorden die op de machine gehasht worden (bijvoorbeeld van lokale accounts of van websites) moet vervangen: ze kunnen op het moment dat ze ingevoerd zijn en verwerkt werden gelekt zijn. Maar zo een wachtwoord vinden zou echt een flink 'lucky shot' zijn. Voor andere zaken die al uitgelekt zouden zijn geldt: jammer, maar niets meer aan te doen. groet, Winfried -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5347b3cf.7080...@tilanus.com