Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 34, views: 18.260 •
Bron: OpenSSL

OpenSSL-signatures worden onvoldoende op echtheid gecontroleerd door OpenSSL-versies tot en met 0.9.7j en 0.9.8b, hebben de ontwikkelaars van het pakket laten weten. De signatures, die worden gebruikt om de authenticiteit van een document te waarborgen zonder dat het document zelf gecodeerd hoeft te worden, kunnen onder bepaalde voorwaarden worden vervalst omdat de betreffende software niet alle gegevens uit een digitale handtekening analyseert. Het lek veroorzaakt met name opschudding omdat dergelijke handtekeningen ook gebruikt worden door de Certificate Authorities, die beveiligingscertificaten voor websites leveren.

Blinde RSA-koe De makers waarschuwen dat alle software die van de OpenSSL-programmabibliotheek gebruik maakt kwetsbaar is, en daar zitten grote namen tussen: zo leunen de beveiligde versies van de populaire Apache-webserver zwaar op OpenSSL. De fout in de OpenSSL-software kan misbruikt worden met alle PKCS #1 v1.5-signatures die met een RSA-sleutel met exponent 3 zijn aangemaakt, en volgens het team achter de software zijn dat er nogal wat. Toch hoeven gebruikers niet in paniek te raken: bankgegevens en andere persoonlijke informatie, die doorgaans gecodeerd het internet opgaan, blijft precies even onleesbaar voor derden als voorheen. Gebruikers van OpenSSL wordt aangeraden om zo snel mogelijk de nieuwste versie te installeren, waarin het probleem verholpen is. Omdat niet het aanmaken maar alleen de verificatie van gegevens het probleem is, hoeven bestaande signatures echter niet te worden vervangen.

Reacties (34)

apt-cache show openssl
Package: openssl
Priority: optional
Section: utils
Installed-Size: 2280
Maintainer: Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org>
Architecture: i386
Version: 0.9.8b-2
Hopen dat debian snel met een update komt
[2006-09-05] Accepted 0.9.8b-3 in unstable (high) (Kurt Roeckx)
http://packages.qa.debian.org/o/openssl.html

Sinds gister is de nieuwe versie dus in Unstable.
* Fix RSA Signature Forgery (CVE-2006-4339) using patch provided
by upstream.
http://packages.qa.debian...ews/20060905T213441Z.html

De fix zal naar de stable package gebackport worden, als dat niet al gedaan is. Kan nooit lang meer duren, tenzij de buildds roet in het eten gooien.
Zou dit hem toevallig zijn? :)
Date: Tue, 5 Sep 2006 18:26:10 +0000
Version: 0.9.8b-3
Changes:
openssl (0.9.8b-3) unstable; urgency=high
.
* Fix RSA Signature Forgery (CVE-2006-4339) using patch provided
by upstream.
Ik kan me indenken dat je met dit artikel niet graag er meteen onder vermeldt wilt staan dat je ze te koop aanbiedt. Lang leven Google Adds. :P
meesterlijk gewoon! :Y)
Geen dank voor de Ubuntu-spam.
Hoezo is het spammen als je aangeeft dat een Debian-derivaat snel een oplossing heeft voor het probleem(ook al is het misschien gekleurd).
Fedora Rawhide ook. Die hebben zelfs patches uit de toekomst:

$ rpm -q --changelog openssl |head
* Sun Sep 10 2006 Tomas Mraz <tmraz@redhat.com> 0.9.8b-6
- fix CVE-2006-4339 - prevent attack on PKCS#1 v1.5 signatures (#205180)
Voor Debian komt er dan vast een security update, die natuurlijk iedereen meteen installeert.

Verder is het natuurlijk irritant dat zulke fouten in, toch wel, zeer kritische software zitten. De nieuwste versie? Dat is dus 0.9.7k of 0.9.8c (zie deze advisory)
zeer kritische software
Ehh deze software is nog niet eens op een 1.0 versie aangekomen, dus deze voor iets kritisch inzetten is op z'n best onverstandig.
Begrijp ik nu eigenlijk goed dat probleem zich alleen bevindt in client side checking van een signature?
Implementations
may incorrectly verify the certificate if they are not checking for
excess data in the RSA exponentiation result of the signature.
Dus hoewel het natuurlijk noodzakelijk is om te upgraden, hoeft dit niet overhaast te gebeuren? Of mis ik nu iets?
Inderdaad, het is niet zo dat je encryptie ondergraven is, noch is het zo dat je nieuwe certs moet aanmaken of opnieuw documents gaan signen.
Het is alleen maar de leesimplementatie die hier en daar wat overslaat en dus een gefraudeerd document als een echt zou kunnen aanzien.

Qua impact is dit mogelijk even erg maar voor ons sys admins is het wel een geluk dat je gewoon snel een update moet doen. Indien je niet op certs van anderen betrouwt en er zelf alleen maar uitschrijft, bv voor je LAMP server dan zit er heus geen haast achter.
Tsja, maar het nut van zelf getekende signatures is vrij beperkt. Je wilt juist dat een bekend en "betrouwbaar" bedrijf bevestigd dat het bedrijf waarmee je zaken doet ook echt dat bedrijf is.

Met zelf getekende signatures is het toch een beetje: Oplichter en Co zegt dat Oplichter en Co, Oplichter en Co is waarbij Oplichter en co heel eenvoudig kan beweren dat het een willekeurig ander bedrijf is.

Deze truc maakt het voor het fictieve Oplichter en Co mogelijk te doen alsof zij bedrijf X zijn en dat een bekende certificeringsinstantie dat ook vindt. Dus misschien praktisch niet zo lastig op te lossen maar zeer zeker een groot probleem.
Voor SSL is het anders toch verrekte hendig! En weet je wat een certificaatje kost?
Ik google net dat deze persoon dit al 8 jaar geleden bekend had gemaakt tijdens CRYPTO 98.
http://www.harper.no/vale...41-9c6d-f498cbedce82.aspx
8 jaar geleden was een hele andere bug met het rapporteren van padding ipv het abusievelijk goedkeuren van een signature.

Het verbaast me overigens niet in het minst dat dit met openssl gebeurt. Het hele engineering proces van openssl vormt geen goede basis voor veilige code. De c code is zo'n brei van defines en matig gedefinieerde interfaces dat het eigenlijk nog een wonder is dat het project nog steeds bestaat.

* Rukapul heeft een keer tegen openssl aangeprogrammeerd en extenties geschreven (en diverse bugs gevonden)
Het verbaast me overigens niet in het minst dat dit met openssl gebeurt. Het hele engineering proces van openssl vormt geen goede basis voor veilige code. De c code is zo'n brei van defines en matig gedefinieerde interfaces dat het eigenlijk nog een wonder is dat het project nog steeds bestaat.

Hoewel ik de code zelf niet ken en je misschien wel gelijk hebt, moet je niet vergeten dat het volgens mij sowieso al onmogelijk is om een dusdanig krachtige crypto-library te programmeren, zonder dat het lelijke code wordt. Er zit zoveel in, wat op zoveel verschillende architecturen moet werken, en dat voor dergelijk complexe en voor de meeste mensen (inclusief hele slimme informatici) onbegrijpelijke algoritmes. Als het echt zo slecht geimplementeerd was dan zou volgens mij niet zo'n beetje de hele wereld (certificate authorities inbegrepen) gebruik maken van OpenSSL...
Hoewel ik de code zelf niet ken en je misschien wel gelijk hebt, moet je niet vergeten dat het volgens mij sowieso al onmogelijk is om een dusdanig krachtige crypto-library te programmeren, zonder dat het lelijke code wordt.
Hier heb je geen gelijk in. Er bestaan prachtige cryptolibraries die een stuk toegankelijker zijn in zowel code als documentatie. Het voordeel van een cryptolibrary is dat het allemaal redelijk los kan hangen: een boel encryptie/decryptie, hash, signature functies, ondersteuning voor creatie en verificatie van certificaten en evt. nog een protocol als TLS. Het enige wat deze onderdelen echt moeten delen zijn de interfaces.
Als het echt zo slecht geimplementeerd was dan zou volgens mij niet zo'n beetje de hele wereld (certificate authorities inbegrepen) gebruik maken van OpenSSL...
Dat is geen argument. Punt is dat als je gratis/open source bezig wilt zijn en bovendien in c/c++ en crossplatform wilt werken dat je noodgedwongen bij openssl uitkomt indien je ondersteuning voor certificaten nodig hebt.

Overigens is openssl geen uitzondering. De Racoon key management daemon van IPsec (op BSD en waarschijnlijk ook Linux) is ook zo'n monster van een stuk security code.

Security code moet vooral volgens een proces ontwikkeld wordt dat veilige code toestaat. Een eerste vereiste is daarbij dat de globale architectuur duidelijk en transparant is. Peter Guttman heeft daar een vrij aardig boek over geschreven.

Het probleem van security code is dat zelfs als het niet zo veilig is dat het best lang duurt voordat er daadwerkelijk lekken worden aangetoond. Vrijwel niemand zal een security vulnerability zien al staart hij er een week naar. Veiligheid van de code is vaak dus geen concrete overweging die meegewogen wordt bij de selectie van een library.
Mozilla heeft een security project, zie http://www.mozilla.org/projects/security/pki/nss/. Ik gebruik deze tools voor het inhouse genereren van diverse certificaten. De SUN Java WebServer maakt ook hiervan gebruik voor de ondersteuning van SSL.
FireFox gebruikt deze libraries voor de implementatie van SSL. Voor apache is er mod_nss beschikbaar als vervanger van mod_ssl
heee, en wie maakt er hier ook weer gebruik van? Juist onze eigen Belastingdienst.. Dus de aangiftes die verstuurd worden zijn totaal niet veilig..
volgens mij heb je een iets verkeerde volgorde in je bewoordingen gekozen ;)
Niet totaal veilig is niet hetzelfde als totaal niet veilig.
U kunt uw mond gaan spoelen:
The attack is only good against keys with exponent of 3. There are not too many of these around any more but you still run into them occasionally. It depends on an error in verifying the PKCS-1 padding of the signed hash.
De belanstingdienst service werkt een tikkie anders. Ik zou je eerder zorgen maken om het systeem waarmee je nu je post heb geschreven. ;)

De kans is klein dat die exploit nog bruikbaar is, want meestal wordt er een exponent van 2^16 gebruikt.
Uit de manpages van openssl 0.9.7.g , zoals geleverd met openbsd 3.9

(openssl genrsa)
-3 | -f4
The public exponent to use, either 3 or 65537. The default is 65537.


De kans is dus inderdaad klein.
edit:
openssl 0.9.7.G --> OpenBsd not affected
Dan zou gentoo er ook geen last van moeten hebben. De default daar is ook 65537.
edit:
Klopt, in de config staat die ook default op 65537. EN dit systeem is al zeker 2 maanden niet geupdate.
Nou, ik heb ervaring met die zogenaamde beveiliging van de belastingdienst en kan je melden (zeker voor de grote bedrijven) dat het helemaal geen probleem is om 'verkeerde' gegevens bij de belastingdienst te krijgen zonder dat iemand het door heeft..
Altijd al afgevraagd wat ik met deze software kan. Zou iemand mij het willen uitleggen?
Is het iets wat ik kan gebruiken voor een windows 2003 webserver? En wat kan ik dan?

Bedankt!
Windows 2003 server wordt toch geleverd inclusief SSL certificatie voor IIS ?
Daar heb je dan toch geen OpenSSL meer voor nodig ?
zo'n certificaat krijg je er echt niet bij hoor, moet je aanschaffen bij een van de certificate authorities
Met de CA van Microsoft kun je onbeperkt certificaten genereren.
<i> Bezig met configureren van libssl0.9.8

Er zijn veiligheidslekken gedicht in deze release. Diensten gebruiken deze versie misschien niet totdat ze herstart zijn. Merk op: sshd herstarten zou geen effect mogen hebben op bestaande verbindingen.
Hierna volgt een lijst van gedetecteerde diensten die herstart moeten worden. Verbeter de lijst, als u denkt dat ze incorrect is. De namen moeten overeenkomen met de script-namen in /etc/init.d en moeten gescheiden worden door spaties. Als u de lijst ledigt, dan zullen er
geen diensten worden herstart.

Als er andere diensten mysterieus beginnen te falen na deze opwaardering, kan het nodig zijn om ze ook te herstarten. Er wordt u ten zeerste aanbevolen uw machine te herstarten om SSL-gerelateerde problemen te vermijden.

<Ok> </i>

Herstarten van exim4 en apache2... Klaar. De soep kan blijkbaar na deze afkoeling met volle teugen weer gegeten worden zonder angst op verbranding .... :+

Op dit item kan niet meer gereageerd worden.



Populair: Desktops Samsung Smartphones Privacy Sony Microsoft Apple Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013