Un patch est dispo ou vous pouvez passer en 2.9.9.
Toutefois ce bug n'est pas encore dans le bug report de openssh.
Note du modérateur: Ce bug n'affecte que la version 2 d'OpenSSH, la distribution Debian n'est pas affectée par ce problème (version 1.2.3).
Aller plus loin
- La news sur securitywatch (3 clics)
- Bug report OpenSSH (2 clics)
- OpenSSH (2 clics)
# Debian Sid
Posté par Aurélien Beaujean (site web personnel) . Évalué à 10.
Attention tout de même car il y a des packages ssh2 dans la sid. Je dis ça car je sais qui y a un grand nombre de personnes qui l'utilise ici (à la fois la sid et ssh2 :)
[^] # Re: Debian Sid
Posté par Manuel Menal . Évalué à 6.
Les paquets de SSH2 sont donc dans non-free, et de ce fait on ne peut pas dire qu'ils fassent partie de Debian... Souvenez-vous de la longue flamewar sur la suppression du répertoire non-free: non-free ne fait _pas_ partie de Debian, ce sont un ensemble de paquets généreusement hébergés par Debian (et généreusement maintenus par des développeurs Debian (ou par qa comme SSH2, bien sûr:)).
Bon, ok, j'avoue, c'est un peu du chipotage, mais bon, faut bien s'occuper quand on est malade :-)
Toujours est-il que ça montre encore une fois que les logiciels libres ne sont pas plus sujets aux alertes de sécurité, au contraire :-]
[^] # Re: Debian Sid
Posté par syntaxerror . Évalué à 10.
alors que le nom du paquet SSH est ssh-nonfree. Ouf!
Stable/potato n'est pas touchée (ssh 1.2.3 seulement).
En revanche woody/testing (2.5.2p2) et sid/unstable (2.9p2) ont le problème.
Qui n'est tout de même pas d'une gravité extrême...
[^] # Re: Debian Sid
Posté par Manuel Menal . Évalué à 1.
Le commentaire du dessus portait à confusion, SSH2 != OpenSSH2 dans mon esprit, donc bon...
Reste que de fait SSH2 n'est pas dans Debian :-)
# arg!
Posté par nicotine . Évalué à 0.
[^] # Re: arg!
Posté par Aurélien Beaujean (site web personnel) . Évalué à 7.
http://cert.uni-stuttgart.de/archive/bugtraq/2001/09/msg00259.html(...)
D'ailleurs quand on regarde le diff ça fait peur.
[^] # Re: arg!
Posté par Miod in the middle . Évalué à 2.
http://www.openssh.com/ftp.html(...)
ou
http://www.openssh.com/portable.html(...)
# Y'a aussi un autre trou
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
ssh dispose d'un système de restriction de commandes (par exemple on peut limiter un utilisateur à faire un "ssh user@host ls"), mais lorsque la machine dispose d'un serveur sftp, cette restriction peut etre bypassée.
Donc méfiance pour ceux qui utilisent sftp...
[^] # Re: Y'a aussi un autre trou
Posté par Paul . Évalué à 1.
suffit d'utiliser MC aka MidnightCommander...
il permet de browser des repertoires avec ssh 1....
en gros ... exit ssh 2....
# 4 years...
Posté par Henri . Évalué à 3.
[^] # Re: 4 years...
Posté par Annah C. Hue (site web personnel) . Évalué à 8.
[^] # Re: 4 years...
Posté par Lagaffe Gaston . Évalué à 0.
[^] # Re: 4 years...
Posté par Miod in the middle . Évalué à 2.
Donc, toujours 4 ans sans vulnerabilite exploitable a distance dans l'installation par defaut...
[^] # le retour de l'errata ....
Posté par Anonyme . Évalué à -4.
je sais, je suis lourd avec l'orthographe, pardon -> -1 et anonyme
[^] # Re: le retour de l'errata ....
Posté par Miod in the middle . Évalué à -1.
En guise d'excuse, je dirai que ma langue maternelle ne derive pas du latin (-,
[^] # Re: 4 years...
Posté par Gaël Le Mignot . Évalué à 3.
# il faut avoir une IP autorisée et une clé privée quand meme
Posté par Anonyme . Évalué à 10.
http://cert.uni-stuttgart.de/archive/bugtraq/2001/09/msg00259.html(...)
on voit que les utilisateurs sont en principe
identifiables par leur clé publique asymétrique
ET par leur IP
ici le controle d'IP d'une clé s'applique à celui d'une autre clé
moralité: il faut quand meme avoir une ip autorisée
pour une autre clé, at avoir la bonne clé privée
pour rentrer
bref, seul un de vos "amis" peut se faire passer pour un autre de vos amis, s'il a la clé privé de l'autre (peu probable)
[^] # Re: il faut avoir une IP autorisée et une clé privée quand meme
Posté par PLuG . Évalué à 10.
Enfin, ce bug est bloquant puisque le champ "from:" de la dernière clef est utilisé pour toutes les clefs. Difficile de ne pas le remarquer (les premières clefs ne fonctionnant pas si elles viennent de l'@IP normale).
En clair, si ce bug n'a pas été vu avant c'est parce que la fenetre d'activation est tres petite, si petite que personne ne s'y était heurté (sinon il l'aurait vu tout de suite).
Conclusion: c'est un BUG oui, mais pas vraiment un problème de sécurité. (c'est quand même un bug con !!)
# Debian-à foutre...
Posté par Anonyme . Évalué à -7.
C'est sympa de prévenir les gens que la Debian n'est pas affectée, mais y'a pas que la Debian sur cette planète. Y'a quand même d'autres distribs qui sont utilisées, en principe, par plus de gens que la Debian.
En gros, je trouve que cette "Note du modérateur" n'a rien à voir ici avec cette news. Ca fait genre:
Voila, c'était mon (petit) coup de gueule du jour.
[^] # Re: Debian-à foutre...
Posté par nicolas garnier . Évalué à 4.
Rien qu'utiliser le protocole 1.5 de ssh est une faute de sécurité évidente.
[^] # Re: Debian-à foutre mais Backporte !
Posté par Anonyme . Évalué à -2.
ils ont que ça à foutre !
sérieusement un utilisateur de debian stable (potato)
a le choix entre upgrader ses paquets en mettant un peu de
testing (très peu risqué) ou de unstable (peu risqué) dans son apt
ou bien encore de mettre à jour
UNIQUEMENT les bugs de sécurités en mettant security.debian.org dans son apt (les corrections de sécurité des nouvelles versions sont backportées vers les anciennes versions considérées comme plus stables)
c'est ça le choix selon debian !
qui n'a jamais eu une partie de son systeme broken
à cause d'une nouvelle version incompatible d'un logiciel ?
on peut donc choisir d'avoir à la fois la sécurité ET la stabilité.
[^] # Re: Debian-à foutre mais Backporte !
Posté par Anonyme . Évalué à -3.
<troll>oui en utilisant OpenBSD</troll>
[^] # Re: Debian-à foutre mais Backporte !
Posté par nicolas garnier . Évalué à -2.
[^] # Re: Debian-à foutre mais Backporte !
Posté par 36 75 . Évalué à -3.
> Reading Package Lists... Done
> Building Dependency Tree... Done
> E: Couldn't find package openbsd
ben non, ça marche pas ton truc :(((
[^] # Re: Debian-à foutre mais Backporte !
Posté par Anonyme . Évalué à -1.
[^] # Re: Debian-à foutre...
Posté par Anonyme . Évalué à -6.
Petit mais ridicule quand meme.
[^] # Re: Debian-à foutre...
Posté par analogue o/ (site web personnel) . Évalué à -1.
il precise juste quels SSH n'ont pas ce probleme...
[^] # Re: Debian-à foutre...
Posté par Nico . Évalué à -2.
C'est plus simple que de dire "Redhat 7.0/7.1, Mandrake truc, Suse budule, etc.." sont affectées par le probleme, nan ?
Quant à ta comparaison avec la voiture du grand pere, j'aurais plustot ecris :
Renault rappelle au garage ces voitures suite à des problèmes rencontrés sur les ordinateurs de bord.
Note du modérateur: Toutes sauf les Avantime qui ne sont pas affectées.
On a pas dit que la version de untel n'etait pas affectée, on a donné une série...
enfin bon... chacun son interpretation de ce que le modero pense...
Nico
[^] # Re: Debian-à foutre...
Posté par Anonyme . Évalué à -2.
# debian, ssh et les socks...
Posté par Paul . Évalué à 0.
Dans la liste des packages on trouve un ssh-socks qui permet l'utilisation d'un proxy sock (4 ou 5) pour établir une connection.
Ca peut être bin pratik toudmeme mais bon c evidemment OpenSSH et pas ssh not bon ami...
Au début, j'ai été désapointé mais en cherchant bien, le paquet ssh 1.... permet tres bien tout seul de se servir de ce genre de feature.
Voilou c'était juste une tite info au passage...
[^] # Re: debian, ssh et les socks...
Posté par bmc . Évalué à -1.
pourrais
pas
écrire
plus
espacé ?
[^] # Re: debian, ssh et les socks...
Posté par Anonyme . Évalué à -2.
clavier
qui
fait
des
retours
chariot
tout
seul.
[^] # Re: debian, ssh et les socks...
Posté par Paul . Évalué à -2.
juste une question de browser..... de la m$*ù£ê je tedis......
j'en profitais pour faire un tit test...
[^] # Re: debian, ssh et les socks...
Posté par Nico . Évalué à -1.
[^] # Re: debian, ssh et les socks...
Posté par syntaxerror . Évalué à 3.
La solution libre pur jus, c'est dante + ssh. dante est un "wrapper",
qui "socksifie" à la volée (socksify ssh).
Autre possibilité, tsocks.
[^] # Re: debian, ssh et les socks...
Posté par Gaël Le Mignot . Évalué à 2.
Pour changer cette option: dpkg-reconfigure ssh
Autre solution: utiliser "socksify nc" comme ProxyCommand, cela permet en plus d'avoir automatiquement le support du socks pour les machines externes et pas pour les machines internes. Il faut pour cela rajouter ces lignes dans le fichier de conf de ssh (et installer netcat):
Host *.sf.net *.sourceforge.net
ProxyCommand socksify nc %h %p
# Concernant le bug report...
Posté par _PinG _ . Évalué à 5.
C'est le cas pour de nombreux bugs (parfois minuscules) trouvés dans OpenSSH par un utilisateur ou un codeur qui feuillette les sources. Le plus connu etant quand même un problème vraiement connu, qui fait pourtant parti des bases de la crypto, mais qui n'est toujours pas résollu. Il est très bien expliqué dans un article sur Linux Mag HS spécial securité... Il s'aggit d'utiliser un canal pour diffuser des infos et autres... Je ne rentrerais pas dans les détails techniques, mais vous trouverez tout ce dont vous aurez besoin sur le net ou dans linux-mag.
Mais bon, vu que le bug de cette news commence à faire parler de lui, il vas peut-être quand même apparaitre dans le bug report.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.