> This bug can be exploited locally by an authenticated user > logging into a vulnerable OpenSSH server or by a malicious > SSH server attacking a vulnerable OpenSSH client.OK, I must really be missing something. Doesn't OpenSSH drop all privs long before either side gets the option to open a corrupted channel? If so, where's the route to sshd for a buffer overflow to exploit? The closest I can come up with is in a setuid ssh client being poked, X-Forwarding style, by a corrupted server...in which case, that's another reason why ssh shouldn't be setuid by default. Incidentally, *someone* has actually seen a working attack, right? --Dan
1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol <joost at pine.nl> Appendix: Index: channels.c ==================================================================RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; }
Possibly Parallel Threads
- OpenSSH Security Advisory (adv.channelalloc)
- FW: Unable to compile latest release on Linux
- Unable to compile latest release on Linux
- OpenSSH Security Advisory (adv.channelalloc) (fwd)
- [alambert@quickfire.org: Heads up -- potential problems in 3.7, too? [Fwd: OpenSSH Security Advisory: buffer.adv]]