HEAD's UP: possible 0day SSH exploit in the wild
As usual, you may want to either raise shields (i.e. disable/restrict access to the ssh service), or pay extra attention to what is happening on your SSH inbound gateways... http://lwn.net/Articles/340360/ http://isc.sans.org/diary.html?storyid=6742 http://secer.org/hacktools/0day-openssh-remote-exploit.html Yes, it could be a hoax, and I sure hope that's all it is... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Hi all, This is a serious security threat if it is not some sort of a duck (as we call it in our country). I have firewalled some servers already. Do you think tcpwrapping ssh service is enough, or should i use iptables instead? Thanks in advance, Regards -- Ramūnas Čereškevičius Tel.: +370 600 48 371 El.p.: ramu...@techsupport.lt * UNIX/Linux serveriai * Kompiuterių tinklai * Internetinių svetainių kūrimas * Konsultacijos www.techsupport.lt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Hi, thanks for this information! I just hope that this is a hoax. What would you suggest for securing a server running openSSH? How can I notice such an attack in my log files? Cheers Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Henrique de Moraes Holschuh h...@debian.org As usual, you may want to either raise shields (i.e. disable/restrict access to the ssh service), or pay extra attention to what is happening on your SSH inbound gateways... http://lwn.net/Articles/340360/ http://isc.sans.org/diary.html?storyid=6742 http://secer.org/hacktools/0day-openssh-remote-exploit.html Yes, it could be a hoax, and I sure hope that's all it is... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Is there Information on what Versions are affected by this exploit? I read something of Version 3.2 and 4.3 in one of the blog entrys (http://secer.org/hacktools/0day-openssh-remote-exploit.html), maybe someone else could clarify this? Would you recommend stopping ssh completely and switching to remote control? Regards, Justus -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Hi, a good practice, at least for me, is put openssh to listen in a different port than the default. I know, it's not the perfect solution. Regards.
Re: HEAD's UP: possible 0day SSH exploit in the wild
As i have read on this page : http://secer.org/hacktools/0day-openssh-remote-exploit.htmlhttp://secer.org/hacktools/0day-openssh-remote-exploit.htmlit say's that the attack is againt OpenSSH version 4.3. So the best thing that you can do is update OpenSSH to a newer version. But again it are still rumors and i don't know if a version higher then 4.3 is also attackable by the exploit 2009/7/7 Ramunas / techsupport.lt ramu...@techsupport.lt Hi all, This is a serious security threat if it is not some sort of a duck (as we call it in our country). I have firewalled some servers already. Do you think tcpwrapping ssh service is enough, or should i use iptables instead? Thanks in advance, Regards -- Ramūnas Čereškevičius Tel.: +370 600 48 371 El.p.: ramu...@techsupport.lt * UNIX/Linux serveriai * Kompiuterių tinklai * Internetinių svetainių kūrimas * Konsultacijos www.techsupport.lt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
It's helpfull indeed but withe a portscan they can easly find the other port of openssh.If have shutdown the openssh service untill i know wich version is attackable by this exploit or when they have a solution for it. Regards, Jeroen 2009/7/7 Leandro Minatel leandromina...@gmail.com Hi, a good practice, at least for me, is put openssh to listen in a different port than the default. I know, it's not the perfect solution. Regards.
Re: HEAD's UP: possible 0day SSH exploit in the wild
Hi, this is standard for me. I always change the port of the openSSH-server. My (current) solution is: Portsentry listens on port 22, while openSSH-server has another port. Every port scan attempt will result in a ban via iptables and every connection to port 22 will also result in a ban via iptables. Regards Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Clemens Pfaffinger clpfaffin...@gmail.com Hi, this is standard for me. I always change the port of the openSSH-server. My (current) solution is: Portsentry listens on port 22, while openSSH-server has another port. Every port scan attempt will result in a ban via iptables and every connection to port 22 will also result in a ban via iptables. Regards Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Leandro Minatel leandromina...@gmail.com Hi, a good practice, at least for me, is put openssh to listen in a different port than the default. I know, it's not the perfect solution. Regards.
Re: Linux kernel vulnerabilities in unstable
On Tue, 7 Jul 2009 19:51:16 +0200, Francesco Poli wrote: Well, if I see correctly, by plenty you mean 5: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux-2.6archive=nopend-exc=pending-fixedpend-exc=fixedpend-exc=donesev-inc=criticalsev-inc=gravesev-inc=seriousrepeatmerged=no Moreover, please note that all of these bugs are already present in testing, as far as the BTS version tracking knows (unless I am misinterpreting the BTS HTML output): as a consequence, none of them should block the migration to testing. by all means, go ahead and file the bugs; just make sure that the consequences are serious or greater before filing as RC. there is some new relevant discussion on -devel [1] indicating intent get the unstable kernel moving into testing soon (primarily to move d-i development forward). mike [1] http://lists.debian.org/debian-devel/2009/07/msg00196.html -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Linux kernel vulnerabilities in unstable
On Tue, 7 Jul 2009 15:44:23 -0400 Michael S. Gilbert wrote: [...] by all means, go ahead and file the bugs; Bugs filed: #536147 and #536148 just make sure that the consequences are serious or greater before filing as RC. I think that *introducing* (that is to say, as a regression) a security hole that allows a denial of service attack (crash) and/or a privilege escalation attack *does* have serious consequences. there is some new relevant discussion on -devel [1] indicating intent get the unstable kernel moving into testing soon (primarily to move d-i development forward). I was kinda suspecting that this was the case... Call it intuition, call it sixth sense, call it as you like... ;-) -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpQmnLqg2COR.pgp Description: PGP signature
