OpenSSL compromis sur Debian(et ubuntu \o/)

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 3 4 Page Suivante Page Précédente Bas de page
Auteur	Sujet : OpenSSL compromis sur Debian(et ubuntu \o/)

masklinn

í dag viðrar vel til loftárása

http://lists.debian.org/debian-sec [...] 00152.html

Citation :

Luciano Bello discovered that the random number generator in Debian's
openssl package is predictable. This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166). As a
result, cryptographic key material may be guessable.

This is a Debian-specific vulnerability which does not affect other
operating systems which are not based on Debian. However, other systems
can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch. Furthermore, all DSA keys ever used
on affected Debian systems for signing or authentication purposes should
be considered compromised; the Digital Signature Algorithm relies on a
secret random value used during signature generation.

Sarge n'est pas affectée, tout ce qui est plus récent (etch, testing et unstable) l'est.

Allez voir l'alerte pour des outils permettant de tester la compromission de vos clés et les méthodes de rattrapages (globalement, dégager toutes vos clés et les recréer).

Alterte Ubuntu confirmant qu'elle est également compromise à partir de Feisty (7.04) et jusqu'aux versions récentes d'Intrepid Ibex: http://www.ubuntu.com/usn/usn-612-1

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody

Publicité

Xavier_OM

Monarchiste régicide (fr quoi)

Dans le genre grosse faille, ca se pose (remarque l'exploit du kernel pour usurper les droits root c'était pas mal aussi)

De ce que je comprends, openssl utilise l'état non initialisé de la mémoire (à l'allocation donc) comme source de random.
Mais faire ça lève des warnings dans valgrind (détecteur de fuite mémoire), et donc pour corriger le problème le paquet a été patché, la mémoire initialisée à zéro avant usage. Et du coup une des sources de random n'est pas random du tout
http://www.links.org/?p=327

Un nettoyage de code assez malheureux, mais si on vérifie ici : http://marc.info/?t=114651088900003&r=1&w=2
on voit qu'en gros côté Debian on a vu que cela ferait moins d'entropie et côté openssl on a dit que malgré tout ce n'était pas forcément à jeter si cela aidait au debug.

edit :
plus d'infos http://www.aigarius.com/blog/2008/ [...] different/
plus d'infos http://reddit.com/info/6j7a9/comments/c03zxko

La grande question : le générateur est plus prédictible, mais dans quelle mesure cela rend-il une attaque possible ?
Si c'est juste lié à la clef générée lors de la négociation Diffie-Hellman, elle change à chaque connexion ssh alors...
Ce qui est sûr c'est que le "détecteur" de clefs faibles cité dans la Debian Security Alert détecte très très rapidement si la clef est faible ou pas.

Il faut :
- upgrader openssl
- régénerer ses clefs ssh clients si on fait du ssh, et les déployer partout où elles servent.
- régénerer ses certificats X509 si on fait du https
- régénerer les clefs du server openssh et le redémarrer.

mv /etc/ssh/ssh_host_{dsa,rsa}_key* /some/place/else
dpkg-reconfigure -plow openssh-server

Bref tout ce qui est en relation avec openssl

Pour bien faire les choses il faudrait aussi changer les password qui ont été tapés à un moment dans une session ssh trop faible.

Inconvénient Debian/Ubuntu/dérivés : il y a un manque de contrôle qualité dans les patch appliqués. Si une distribution fait un patch, il faut soit le faire remonter au développeur qui maîtrise le sujet, soit avoir une procédure très stricte de validation. On a besoin d'un système simple pour passer en revue ce genre de trucs, surtout sur les paquets critiques, et surtout si on est une distribution qui patche tout tout le temps (ce qui est le cas de Debian).

Inconvénient du système à plus grande échelle : si les développeurs upstream se plantent (si le nouveau codeur récemment arrivé fait de la merde), on ne le verra pas sans contrôle qualité (revue du code ?)

Avantage du système : la faille est publiée, la correction aussi. C'est toujours mieux que de résoudre le problème discrètement et sans communiquer dessus.

Message édité par Xavier_OM le 14-05-2008 à 09:44:59

---------------
Il y a autant d'atomes d'oxygène dans une molécule d'eau que d'étoiles dans le système solaire.

masklinn

í dag viðrar vel til loftárása

Accessoirement, il est également conseillé de passer l'outil fourni dans le lien initial sur les clés même si ce n'est pas un système basé sur debian: toute clé créée sous debian ou ubuntu et importée est également compromise

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody

Profil supprimé

Adieu, monde cruel [:vyse]

THRAK

- THR4K -

C'est clairement une sacrée merde cette compromission avec OpenSSL. :fou:

Faudra vraiment que les dev communiquent mieux et davantage avec l'upstream à l'avenir, surtout pour les paquets de ce type... le cas présent est une leçon magistrale en la matière. En attendant ça va être un beau bordel dans les jours à venir (niveau re-génération de clés et certifs on va pas être déçus...) ; une histoire qui risque de faire grand bruit dans le milieu...

---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

black_lord

Modérateur
Truth speaks from peacefulness

pour rebondir : http://blog.drinsama.de/erich/en/l [...] l-desaster

La mémoire non initialisée n'est pas forcemment "totallement" initialisée de ce que je comprends... Si le compilo a des options spécifiques alors on peut avoir le même comportement..

Grand bruit je sais pas... parce que c'est surtout une faille "théorique"... qu'il sera difficile (impossible ?) d'exploiter... et regénérer des centaines de clés [:pingouino] je suis carrément pas chaud...

edit : il n'y a que les gens qui ne font rien qui ne se trompent pas... pour le coup je rejoins lucas nussbaum. Les devs d'openssl ont aussi le droit de commenter leur code, surtout aux endroits "litigieux" au niveau sens.

Message cité 2 fois
Message édité par black_lord le 14-05-2008 à 10:14:34

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

sligor

Ca serait intéressant d'avoir plus d'infos sur la diminution de l'entropie du RNG dû à la faille, si on perd quelques bits sur 256b c'est pas trés grave, si on passe de 256 à 32 là c'est plus gênant.

black_lord

Modérateur
Truth speaks from peacefulness

en faisant qq recherches il apparait que les clés peuvent apparemment subir assez rapidement une analyse

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

masklinn

í dag viðrar vel til loftárása

black_lord a écrit :

Ouais enfin d'un autre côté quand on connaît rien en crypto on va pas modifier du code de crypto juste pour faire taire un warning dans valgrind :sweat:

edit: et si on le fait quand même, on upstream le patch afin que les gens qui s'y connaissent puissent le voir et l'analyser avant de l'appliquer sans en parler aux responsables [:pingouino]

Message édité par masklinn le 14-05-2008 à 10:21:22

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody

black_lord

Modérateur
Truth speaks from peacefulness

on est d'accord :jap:

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Publicité

Taz

bisounours-codeur

Moi j'y comprends rien à cette DSA: si le PRNG d'openssl repose uniquement sur de la mémoire pas initialisée plutôt que sur des choses comme /dev/random alors c'est openssl qu'il faut jeter.

Message cité 1 fois

Taz

bisounours-codeur

black_lord a écrit :

pour rebondir : http://blog.drinsama.de/erich/en/l [...] l-desaster

La mémoire non initialisée n'est pas forcemment "totallement" initialisée de ce que je comprends... Si le compilo a des options spécifiques alors on peut avoir le même comportement..

Grand bruit je sais pas... parce que c'est surtout une faille "théorique"... qu'il sera difficile (impossible ?) d'exploiter... et regénérer des centaines de clés [:pingouino] je suis carrément pas chaud...

ouais alors là je suis bien d'accord avec toi. Le non-initialisé, ça peut souvent contenir que du 0 ou un motif, quelque chose de très prévisible justement. Les dev d'openssl a part vaner sur debian ne font pas de véritable analyse du problème. ça sent vraiment mauvais openssl.

black_lord

Modérateur
Truth speaks from peacefulness

Taz a écrit :

Moi j'y comprends rien à cette DSA: si le PRNG d'openssl repose uniquement sur de la mémoire pas initialisée plutôt que sur des choses comme /dev/random alors c'est openssl qu'il faut jeter.

ça c'est un truc que je capte pas : on a des crypto devices, et on ne s'en sert pas...

Message cité 2 fois

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

sligor

black_lord a écrit :

ça c'est un truc que je capte pas : on a des crypto devices, et on ne s'en sert pas...

L'excuse c'est la portabilité j'imagine, utiliser le maximum de code commun sur toutes les plates-formes est censé apporter plus de sécurité.

Message cité 2 fois

Taz

bisounours-codeur

black_lord a écrit :

ça c'est un truc que je capte pas : on a des crypto devices, et on ne s'en sert pas...

je croyais que debian voulait balancer openssl pour des problèmes de licences, il y a peut être pas que ça en fait.
C'est une escroquerie cette alerte: je vois pas en quoi dépatcher le bouzin corrige le problème de sécurité. Bien malheureux ceux qui se croient à l'abri avec du code comme ça.

Je viens de pinger sur http://bugs.debian.org/cgi-bin/bug [...] bug=363516 pour avoir des infos.

Message cité 1 fois
Message édité par Taz le 14-05-2008 à 11:13:17

black_lord

Modérateur
Truth speaks from peacefulness

sligor a écrit :

L'excuse c'est la portabilité j'imagine, utiliser le maximum de code commun sur toutes les plates-formes est censé apporter plus de sécurité.

A d'autres... Tous les unix ont des /dev/*random*...

Message cité 1 fois

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Taz

bisounours-codeur

sligor a écrit :

L'excuse c'est la portabilité j'imagine, utiliser le maximum de code commun sur toutes les plates-formes est censé apporter plus de sécurité.

C'est sinistrement stupide comme approche.

gug42

Salut les gens,

Bon voila, je n'arrive pas à bien estimer le risque ...
Est ce si grave ?
Est ce rapide de compromettre une connexion ssl ? (par exemple https ou ssh via mot de passe) ?

D'après Black lord tout ca est très théorique ?

Car regénérer les clefs de tout les serveurs va me prendre du temps beaucoup de temps (voir trop) :
- sshd (que la connexion soit par mot de passe ou par clef)
- openvpn
- certificats https

Message cité 1 fois
Message édité par gug42 le 14-05-2008 à 11:23:14

Taz

bisounours-codeur

Bah on est comme toi, on ne sait pas quoi penser. La DSA ne donne pas d'indice sur la faisabilité d'une attaque, et surtout quand on voit le correctif/dépatch, on se met à penser que patch ou pas, les clefs/certificats générés avec openssl sont de qualité extrêmement médiocre.

Skateinmars

black_lord a écrit :

A d'autres... Tous les unix ont des /dev/*random*...

Openssl doit être dispo sur windows ?
Enfin ca empêche pas d'utiliser une source en plus la ou elle est disponible...

---------------
Feedback HAV

black_lord

Modérateur
Truth speaks from peacefulness

gug42 a écrit :

Salut les gens,

Bon voila, je n'arrive pas à bien estimer le risque ...
Est ce si grave ?
Est ce rapide de compromettre une connexion ssl ? (par exemple https ou ssh via mot de passe) ?

D'après Black lord tout ca est très théorique ?

Car regénérer les clefs de tout les serveurs va me prendre du temps beaucoup de temps (voir trop) :
- sshd (que la connexion soit par mot de passe ou par clef)
- openvpn
- certificats https

http://wiki.debian.org/SSLkeys

ça ne prends qu'une minute/serveur avec des scripts...

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Le_Tolier

Hello IT ?

je voulais tester mes clefs ...

Citation :

hosttmp# ./dowkd.pl file /home/letolier/.ssh/id_rsa
/home/letolier/.ssh/id_rsa:1: warning: unparsable line
/home/letolier/.ssh/id_rsa:2: warning: unparsable line
/home/letolier/.ssh/id_rsa:3: warning: unparsable line
/home/letolier/.ssh/id_rsa:4: warning: unparsable line
/home/letolier/.ssh/id_rsa:5: warning: unparsable line
/home/letolier/.ssh/id_rsa:6: warning: unparsable line
/home/letolier/.ssh/id_rsa:7: warning: unparsable line
/home/letolier/.ssh/id_rsa:8: warning: unparsable line
/home/letolier/.ssh/id_rsa:9: warning: unparsable line
/home/letolier/.ssh/id_rsa:10: warning: unparsable line
/home/letolier/.ssh/id_rsa:11: warning: unparsable line
/home/letolier/.ssh/id_rsa:12: warning: unparsable line
/home/letolier/.ssh/id_rsa:13: warning: unparsable line
/home/letolier/.ssh/id_rsa:14: warning: unparsable line
/home/letolier/.ssh/id_rsa:15: warning: unparsable line
/home/letolier/.ssh/id_rsa:16: warning: unparsable line
/home/letolier/.ssh/id_rsa:17: warning: unparsable line
/home/letolier/.ssh/id_rsa:18: warning: unparsable line

Message cité 2 fois

---------------
Never f**k with your systems administrator. Why? Because they know what you do with all that free time! |?? | SAVE Jericho !

masklinn

í dag viðrar vel til loftárása

J'ai cherché un peu plus d'infos, et apparement ça vient de ce patch: http://svn.debian.org/viewsvn/pkg- [...] /md_rand.c

Le problème est donc, si j'ai bien compris, dans l'ajout de données au buffer d'entropie utilisé pour seeder le PRNG.

En bas, il y a l'ajout de données non-initialisées pour rendre cette seed un peu plus aléatoire parce que ça ne peut qu'améliorer le truc, mais on remarque qu'il y a un #define autour pour dégager les warnings de Valgrind ou Purify. Plutôt que de setter le flag pour dégager cette partie via le define, la personne qui a créé le patch a tout commenté. Ce bout de code ne sert qu'à rendre le pool un peu plus aléatoire, et dans tous les cas ça ne peut pas le rendre moins aléatoire.

Mais en haut, c'est d'après les explications que j'ai eu un ajout d'un buffer initialisé et essentiel à un seeding correct du PRNG.

http://www.links.org/?p=327:

Citation :

Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it.

Pour le détecteur de clés fuckées, il est dans le premier lien, c'est http://security.debian.org/project [...] owkd.pl.gz

edit: une autre explication assez complète:

Citation :

I've seen a lot of confusion here about what the patch actually did, and what the functions were supposed to do. I am not a cryptographer, or maintainer of OpenSSL, but from inspecting the code, here's what I can determine.

There is a set of functions in OpenSSL for initializing the pseudo-random number generator seed. They all actually end up calling the ssleay_rand_add function (you can find out more about how this is supposed to work using man RAND_add). This takes a seed value, and mixes the entropy from that seed value into its entropy pool. There is also a function for getting random data out of the pseudo-random number generator, ssleay_rand_bytes (man RAND_bytes), which is supposed to return a number of random bytes into a buffer you provide.

Now, ssleay_rand_bytes was actually mixing some entropy from the buffer passed in before generating random data. This isn't particularly harmful, assuming that there's already enough entropy in the pool, but isn't necessarily helpful, either; uninitialized memory won't provide all that much entropy, and there are attacks that can potentially put known data into it. There had been an ifdef to avoid doing this when using tools that detect uses of uninitialized memory, but I guess they were't using that ifdef when running under Valgrind.

So, according to bug #363516, Valgrind was warning about unitialized data in the buffer passed into ssleay_rand_bytes, which was causing all kinds of problems using Valgrind. Now, instead of just fixing that one use, for some reason, the Debian maintainers decided to also comment out the entropy mixed in from the buffer passed into ssleay_rand_add. This is the very data that is supposed to be used to see the random number generator; this is the actual data that is being used to provide real randomness as a seed for the pseudo-random number generator. This means that pretty much all data generated by the random number generator from that point forward is trivially predictable. I have no idea why this line was commented out; perhaps someone, somewhere, was calling it with uninitialized data, though all of the uses I've found were with initialized data taken from an appropriate entropy pool.

So, any data generated by the pseudo-random number generator since this patch should be considered suspect. This includes any private keys generated using OpenSSH on affected Debian systems. It also includes the symmetric keys that are actually used for the bulk of the encryption, which means that any information transmitted over SSH to or from affected boxes, including passwords, should be considered to be potentially compromised.

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody

black_lord

Modérateur
Truth speaks from peacefulness

Le_Tolier a écrit :

je voulais tester mes clefs ...

Citation :

teste plutôt tes hosts

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Taz

bisounours-codeur

http://bugs.debian.org/cgi-bin/bug [...] bug=363516

Je suis désolé, mais je ne vois pas en quoi il y a un problème de sécurité. Soit le rôle de ce buffer pas initialisé est minime et ça n'a pas d'impact qu'il soit utilisé ou pas, ou qu'il ait une valeur fixe et connue, soit son rôle n'est pas minime et là le problème est plus grave.

Le gars de Debian dit que la sécurité d'openssl ne repose pas ce buffer pas initialisé.

Je ne vois pas la logique dans toutes les conclusions "jetez vos clefs". Est-ce que les clefs regénérées seront vraiment meilleures ?

Message cité 1 fois

masklinn

í dag viðrar vel til loftárása

Voir mon post de clarification

Message édité par masklinn le 14-05-2008 à 12:04:41

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody

Xavier_OM

Monarchiste régicide (fr quoi)

Taz a écrit :

http://wiki.debian.org/SSLkeys > How weak?

Message cité 1 fois

---------------
Il y a autant d'atomes d'oxygène dans une molécule d'eau que d'étoiles dans le système solaire.

masklinn

í dag viðrar vel til loftárása

Xavier_OM a écrit :

http://wiki.debian.org/SSLkeys > How weak?

Et pour la première partie du post, tout à la fin, "A bit more detail" (qui dit à peu près la même chose que mon post)

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody

Taz

bisounours-codeur

OK, ça commence à être clair.

En gros, en voulant faire du nettoyage, le développeur debian a:
- supprimé un morceau de code qui utilise un buffer pas initialisé. c'est pas grave puisque ce buffer est un buffer de sortie. ça ne modifie pas sensiblement la quantité d'entropie. Ca se passe dans ssleay_rand_bytes .
- supprimé un morceau de code similaire mais qui se coup si n'est pas un fignolage mais la base d'entropie du PRNG. ça se passe dans ssleay_rand_bytes. Et c'est là le problème de sécurité: le vecteur d'initialisation n'est pas utilisé.

La où est l'erreur, c'est que le bout de code est identique, mais avec un usage radicalement différent.

Message édité par Taz le 14-05-2008 à 12:36:15

Skateinmars

Le_Tolier a écrit :

je voulais tester mes clefs ...

Citation :

hosttmp# ./dowkd.pl file /home/letolier/.ssh/id_rsa
/home/letolier/.ssh/id_rsa:1: warning: unparsable line

C'est le .pub qu'il faut lui donner :jap:

Message cité 1 fois

---------------
Feedback HAV

black_lord

Modérateur
Truth speaks from peacefulness

tous mes serveurs sont à jour, toutes mes clés ont été changées [:jar jar]

Message cité 1 fois
Message édité par black_lord le 14-05-2008 à 13:12:28

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Taz

bisounours-codeur

Vu que personne ne vérifie jamais les fingerprint de ses serveurs, j'imagine le carton possible.

Le_Tolier

Hello IT ?

Skateinmars a écrit :

C'est le .pub qu'il faut lui donner :jap:

Citation :

sd-2245etc/ssh# ./dowkd.pl file ssh_host_dsa_key.pub
sd-2245etc/ssh# ./dowkd.pl file ssh_host_rsa_key.pub
sd-2245etc/ssh#

qu est ce que j ai encore mal fait ?

Message édité par Le_Tolier le 14-05-2008 à 14:04:52

---------------
Never f**k with your systems administrator. Why? Because they know what you do with all that free time! |?? | SAVE Jericho !

black_lord

Modérateur
Truth speaks from peacefulness

tu as mal lu la doc

Message cité 1 fois

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Le_Tolier

Hello IT ?

black_lord a écrit :

tu as mal lu la doc

euh [:sniperlk] cad ?

Citation :

sd-2245etc/ssh# ./dowkd.pl
usage: ./dowkd.pl [OPTIONS...] COMMAND [ARGUMENTS...]

COMMAND is one of:

file: examine files on the command line for weak keys
host: examine the specified hosts for weak SSH keys
user: examine user SSH keys for weakness; examine all users if no
users are given
help: show this help screen

OPTIONS is one pf:

-c FILE: set the database cache file name (default: dowkd.db)

dowkd currently handles OpenSSH host and user keys and OpenVPN shared
secrets, as long as they use default key lengths and have been created
on a little-endian architecture (such as i386 or amd64). Note that
the blacklist by dowkd may be incomplete; it is only intended as a
quick check.

---------------
Never f**k with your systems administrator. Why? Because they know what you do with all that free time! |?? | SAVE Jericho !

black_lord

Modérateur
Truth speaks from peacefulness

http://wiki.debian.org/SSLkeys

Message cité 2 fois

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

masklinn

í dag viðrar vel til loftárása

http://lists.debian.org/debian-sec [...] 00153.html checklist du chemin d'update

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody

e_esprit

black_lord a écrit :

http://wiki.debian.org/SSLkeys

Cette page n'existe pas encore. Vous pouvez créer une nouvelle page blanche ou utiliser un modèle. Avant de créer cette page, merci de vérifier qu'une page similaire n'existe pas déjà.

Tu la crée ou pas ?

[:drapal]

Message cité 1 fois

---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.

black_lord

Modérateur
Truth speaks from peacefulness

chez moi ça marche

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

sligor

e_esprit a écrit :

Cette page n'existe pas encore. Vous pouvez créer une nouvelle page blanche ou utiliser un modèle. Avant de créer cette page, merci de vérifier qu'une page similaire n'existe pas déjà.

Tu la crée ou pas ?

[:drapal]

problème de cache

Publicité

Page : 1 2 3 4

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Linux et OS Alternatifs

réseaux et sécurité

OpenSSL compromis sur Debian(et ubuntu \o/)

Sujets relatifs
Gestion des ventilos sur un portable Toshiba avec Debian	PXE Ubuntu - Debian
Ubuntu Party [Amiens] 24-25 mai	[ubuntu] problème grub error 18
Debian: config Eth pour wifi	Problème d'install debian
[ubuntu]installer les pilotes pour geforce 6600gt	ubuntu ne se lance pas carte ATI radeon 8500 et class Xp
[Résolu] ddclient ubuntu 8.04
Plus de sujets relatifs à : OpenSSL compromis sur Debian(et ubuntu \o/)

Page générée en 0.157 secondes