Heren, fyi:
Er is een OpenSSH remote root-exploit out in the wild gesignaleerd.
Wanneer een systeem EXACT vurnerable is, is nog niet 100% duidelijk, maar er zijn geruchten van opengebroken OpenBSD, FreeBSD, en GNU/Linux systemen met OpenSSH v3.6 en lager met PRIVSEP en SSHV2ONLY enabled (en met PERMITROOTLOGIN uit).
sshd.config (
Protocol 2
UsePrivilegeSeperation yes
PermitRootLogin no
)
De OpenSSH 3.7p1 release van vandaag zou het probleem moeten patchen.
Zie ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/
Naast patchen stel ik voor om (voor diegene die dat nog niet gedaan hebben) de SSH-service alleen toegangkelijk te maken vanaf de IP-adressen van de mensen die shells MOETEN hebben.
Dit kan met behulp van iptables:
Voor mensen met Debian is er een update beschikbaar, meer hierover hier:Code:iptables -A INPUT -i eth0 -p tcp -s <admin2 ip> --dport ssh -j ACCEPT iptables -A INPUT -i eth0 -p tcp -s <admin2 ip> --dport ssh -j ACCEPT iptables -A INPUT --protocol tcp --dport ssh -j DROP
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211205
Full-disclosure mailing list:
http://lists.netsys.com/pipermail/fu...er/010103.html
Slashd
http://slashdot.org/articles/03/09/1...id=126&tid=172
http://slashdot.org/comments.pl?sid=78703&cid=6976178
The bug must center around this line:
/* Increase the size of the buffer and retry. */
buffer->alloc += len + 32768;
It looks like the problem here is that buffer->alloc (which presumably stores the size of the buffer) grows on every try, while the actual size of the buffer grows only on successful tries. So you could have a situation where, after a couple of tries, the buffer is 65536, but buffer->alloc is 98304. This could potentially cause another part of the program to run past the actual end of the buffer.
The patch addresses this by only updating buffer->alloc after the new memory has been successfully allocated.

Likes:
![[WAARSCHUWING] OpenSSH remote root-exploit](https://www.webhostingtalk.nl/images/WHT_rd/misc/dT.png)

