découvert dans plusieurs versions de OpenSSH qui permet
aux utilisateurs ayant un compte de passer r00t !
L'exploit pour cela n'a pas encore été publié...
Le PINE-CERT recommande une mise à jour rapide et
classe ce risque comme HIGH (le patch est déja disponible et
intégré dans le CVS d'OpenSSH).
Aller plus loin
- Alerte du PINE-CERT (3 clics)
- Patch (2 clics)
# Flippant
Posté par Thomas Poindessous . Évalué à 10.
Sauf que là, c'est vrai.
Si on me dit que la faille vient de auth.c, là je vais vraiment flipper ....
[^] # Ca va mieux :-)
Posté par Thomas Poindessous . Évalué à 10.
C'est moche comme erreur quand même:
- if (id < 0 || id > channels_alloc) {
+ if (id < 0 || id >= channels_alloc) {
C'est pas de bol, en plus on peut passer 20 fois dessus sans s'en rendre compte ...
[^] # Re: Ca va mieux :-)
Posté par kael . Évalué à 10.
les trous de securité c'est parfois absolument deconcertant ...
ceci dit ca fesait longtemps qu'on en avait pas trouvé dans openssh!
[^] # Re: Ca va mieux :-)
Posté par vjm . Évalué à 1.
Je sais pas si c'est le coté super sécurité qui attire les auditeurs, ou juste que c'est codé n'importe comment...
http://openssh.com/security.html(...)
Le problème reste que la seule alternative c'est SSH.com commercial...
[^] # Re: Ca va mieux :-)
Posté par kalahann . Évalué à 10.
Heu... t'es sûr!? bon d'accord y'en a peut-être pas autant que dans IE, mais ça fait beaucoup! En plus à chaque fois, c'est pas vraiment des *petits* bugs. Comme celui où openssh faisait du padding faible des paquets, on pouvait trouver la clé secrète en faisant des calculs sur les paquets qui passaient.
[^] # Re: Ca va mieux :-)
Posté par kael . Évalué à -2.
-1 pour l'oublis...
[^] # Re: Ca va mieux :-)
Posté par Sami Dalouche . Évalué à -6.
Le C++ n'est pas beaucoup mieux (bien qu'un peu plus propre) et le java est trop lent, il n'y a donc pas de solution en attendant les compilateurs Java natifs..
En attendant, on peut quand meme dire que pour le language utilisé, OpenSSH n'a pas trop de bugs, les developpeurs font un boulot remarquable.
[^] # Re: Ca va mieux :-)
Posté par matiasf . Évalué à 4.
Tu crois que coder en VB c'est plus "secure" ?
ssh s'occupe d'une partie importante et le serveur tourne en root. Alors une connerie en C, VB, Java reste un connerie. Et les language de tres, tres haut niveau capable de corriger les erreurs des developpeurs n'existe pas.
[^] # Re: Ca va mieux :-)
Posté par pasBill pasGates . Évalué à -5.
Maintenant ca n'empeche pas les problemes de securite lies a un probleme dans la conception et la logique du code.
[^] # Re: Ca va mieux :-)
Posté par Yann Droneaud (site web personnel) . Évalué à 4.
Le seul langages avec lequel tu es sur de ce que tu fait c'est le binaire (ou l'héxa), mais cela sous entends que tu est programmeur parfait.
Tout les autres langages créent des erreurs
le C++ est tellement compliqué que l'on sait jamais trop comment va etre réalisé ce que tu lui demande
(et ne parlons pas du passage d'un compilateur a l'autre).
Les langages interprétés (Java, Perl, ...) dependent en plus de l'interpreteur.
Des langages a runtime comme Ada et Objective dependent de leur runtime.
Dans tout les cas, cela depend de l'Homme,
car c'est forcement un Homme qui a codé le compilateur, interpreteur, runtime.
Et c'est forcement un Homme qui va l'utiliser.
(remplacer Homme, par humain, penguin, vache ou autre).
Je vous rappelle qu'on est pas des machines ...
[^] # Re: Ca va mieux :-)
Posté par matiasf . Évalué à 6.
Ce n'est pas le language qui s'occupe de la securite.
Si tu prends java, c'est la jvm qui prend en compte la securite (comportement different dans un navigateur).
Dans la majorite des cas c'est le service que tu utilises (apache par exemple) ou le noyau qui s'occupe de securite.
Si le programme login (qui tourne obligeatoirement sous root) que tu utilises a un truc du style
> if (id_user == 0)
> go_superuser() ;
> exit() ;
Le programme dit si id_user=0 , on passe en root, puis on quitte.
Si maintenant :
> if (id_user == 0) ; // ; !
> go_superuser() ;
> exit() ;
Le programme dit si id_user=0, on ne fait rien, puis on passe en root et on quitte.
Au mieux, le compilateur (ou l'interpreteur) peut signaler une instruction sans effet. Mais surement pas que tu donnes acces a root a un utilisateur qui n'a pas les privileges suffisants. Puisque tu fais un programme pour definir les privileges (changement de reel id).
Ce comportement est valable pour pascal, C, C++, java, etc...
Dans tous les cas, le langage doit fait ce que tu dis. Meme si c'est une connerie.
[^] # Re: Ca va mieux :-)
Posté par Yann Droneaud (site web personnel) . Évalué à -2.
Pour l'histoire de la JVM, c'est plus a comparé avec un système d'exploitation
(modele en couche d'abstraction).
Pour le reste oui, d'accord, j'ai rien a dire de plus, ca me parassait evident ...
[^] # Re: Ca va mieux :-)
Posté par Denny MANSART . Évalué à 0.
[^] # Re: Ca va mieux :-)
Posté par Alain Tésio . Évalué à 10.
> account has not been proven but is not
> considered impossible.
Ca risque de remettre le compteur à zéro pour
la fameux slogan d'OpenBSD "4 ans sans faille
exploitable à distance dans l'install par défaut"
Enfin il leur restera toujours l'argument de
l'audit du code. Quoique ...
[^] # Re: Ca va mieux :-)
Posté par bmc . Évalué à 10.
Certes, il faut un compte sur la machine... cela n'enlève de toute façon rien aux 4 ans passés, je trouve ça pas mal une faille tous les 4 ans personnellement.
[^] # Re: Ca va mieux :-)
Posté par Alain Tésio . Évalué à 10.
A propos, il y a un truc qui m'épate: sendmail est le serveur de mail par défaut sur OpenBSD, vu sa réputation il n'y a pas eu de faille exploitable à distance en 4 ans ?
[^] # Re: Ca va mieux :-)
Posté par RB . Évalué à 10.
1_ moins de bugs de sécurités trouvés globalement que dans OpenBSD (même si on pourrait croire le contraire...)
2_ Les machines virtuelles (Jails) qui ajoutent une surcouche de protection excellente (tant que l'on ne trouve pas un moyen de sortir du jail, mais depuis deux ans j'ai rien vu).
Comme quoi OpenBSD ne m'a jamais convaincu...
[^] # Re: Ca va mieux :-)
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Moi j'installe OpenBSD uniquement sur les firewalls filtrants et les passerelles IPSec, et pour le reste (serveurs/proxies) c'est debian, car je maîtrise beaucoup mieux la d3B1An qu'OpenBSD (surtout c'est moins de boulot...).
[^] # FreeBSD
Posté par ours Ours (site web personnel) . Évalué à 7.
Et en plus on peut ajouter une rapidité et une stabilité excellente, et encore un système d'update (les ports) qui mettent cet outil à la portée de tous
Sinon pour la sécurité, le dernier bug sérieux de php n'a pas été exploité sur BSD
[^] # Re: Ca va mieux :-)
Posté par Miod in the middle . Évalué à 4.
C'est drôle, on ne doit pas avoir la même version, alors. L'installation par défaut d'OpenBSD lance quatre daemons : sshd, sendmail (n'acceptant que les connections locales, cependant), portmap et inetd.
[^] # Re: Ca va mieux :-)
Posté par spim . Évalué à 2.
Franchement, moins de bug de securite trouves ca veut pas dire qu'il n'y en a pas.
De plus je pense que l'equipe d'OpenBSD recherche plus activement les trous de secu que FreeBSD.
Des fois l'approche que certains ont de la securite me fait pleurer.
[^] # Re: Ca va mieux :-)
Posté par kalahann . Évalué à 9.
Ben non, vu qu'il te faut un compte sur la machine cible, et que tu sois authentifié en ssh. C'est équivalent à avoir besoin d'un compte en local.
# Nouvelle release 3.1p1 dispo
Posté par bmc . Évalué à 10.
# Pas de panique
Posté par falbala . Évalué à 10.
2. Si on veut pas attendre demain matin, et on a ses sources dans un coin (il faut TOUJOURS avoir les sources), on peut toujours patcher "à la main", ça donne ça sur OpenBSD :
cd /usr/src/usr.bin/ssh
vi channel.c
[... modifier la ligne 147 comme dans un post précédent ...]
cp /usr/bin/ssh /root/ssh.old && chmod 0400 /root/ssh.old
cp /usr/sbin/sshd /root/sshd.old && chmod 0400 /root/sshd.old
make && make install
--- ET VOILA !! ---
Si vous avez peur de patcher une machine à distance et vous ne vouelz pas attendre demain matin :
... loguez-vous sur la machine en question ...
kill -TERM `ps aux | grep sshd | grep -v grep | awk ' { print $2 } '`
... vérifiez que vous ne pouvez plus vous connecter en ssh ... et déconnectez vous !
--
Y'en a marre de passer la soirée à patcher ses machines.
[^] # Re: Pas de panique
Posté par Euclide (site web personnel) . Évalué à -1.
remettre ce bon vieux telnetd dans la conf d'inetd
killall -1 inetd
changer son pass user et root
se connecter en telnet
virer telnetd de inetd
killall -1 inetd
rechanger ses pass
installer le nouvel openssh
tester si tout fonctionne
[^] # Re: Pas de panique
Posté par Gaétan RYCKEBOER . Évalué à 6.
Tu me diras, c'est pas mieux que de passer root et de changer le pass, mais bon..
[^] # Re: Pas de panique
Posté par Jylam / jylam.lnxsce (site web personnel) . Évalué à 4.
Si je ne m'abuse, pour sniffer quoique ce soit, il faut etre sur le reseau de ce quoique ce soit. Cad la, faut etre ou sur le reseau du serveur, ou chez l'isp, tout ca d'une des deux becanes connectée.
Ca limite pas mal ...
[^] # Re: Pas de panique
Posté par Gaétan RYCKEBOER . Évalué à 9.
SVR2..........................^.../----SVR3.......
.|............................|../................
.----ROUTEUR..|-----------ROUTEUR-------------|...
.........|....|.........../...................|...
....LAN.PROVIDER---SVR2../....................|...
...............|......../.....................|...
........<.--ROUTEUR..../...................ROUTEUR--.>
................|...../......................|....
...........LAN.PROVIDER----------------------.....
.......TA.STATION.D'ADMIN
[que le syndicat des dessins ASCII me pardonne cette offense]
Bref. Si ton serveur c'est SVR1, et qu'un type est logué root sur le serveur SVR3.
Il n'est pas impossible qu'il voit passer des paquets vers le SVR1, qaund les paquets passent par chez lui.
[^] # Re: Pas de panique
Posté par Annah C. Hue (site web personnel) . Évalué à 4.
Bref, chiffrez, stéganographiez, paddez, faites chier les grosses oreilles !
[^] # Re: Pas de panique
Posté par Euclide (site web personnel) . Évalué à 3.
On change les pass root et user dans la session SSH, le temps de se loguer par telnet.
donc si qq'un peut sniffer le pass, il aura moins de 5 secondes pour rentrer et se camoufler.
Bref faut que le pirate soit en train de sniffer pile poil au moment ou on se logue en telnet, et ait un script de connexion, rootkitage, effacement des logs sous la main.
Donc le risque est je trouve ultra négligeable, surtout si on fait tourner un tail -f /var/log/syslog pendant la manip.
[^] # Re: Pas de panique
Posté par Étienne . Évalué à -1.
Etienne
[^] # Re: Pas de panique
Posté par Dawood Ibrahim . Évalué à -2.
hahahahahha
# openssh 3.1 est sorti
Posté par Stephane Salettes . Évalué à 10.
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.1p1.t(...)
[^] # Re: openssh 3.1 est sorti
Posté par nicotine . Évalué à 2.
[^] # Re: openssh 3.1 est sorti
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 8.
1. Récuperer ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm/SRPMS/opens(...)
2. l'intaller
3. Changer 2x "0.9.5c" en "0.9.6" dans le .spec (c'est une bourde, openssh-3.1 a besoin de openssl >=0.9.6)
4. rpm -bb xxx.spec
4a. Si erreur [cipher.o], récuperer openssl 0.9.6 et installer
5. installer les RPMS/i386/openssh*
Bon appétit!
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: openssh 3.1 est sorti
Posté par Tony Flow . Évalué à 3.
[^] # Re: openssh 3.1 est sorti
Posté par cyril bosselut (site web personnel) . Évalué à 2.
ftp://ftp.ciril.fr/pub/linux/mandrake/updates/8.1/RPMS(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.