> 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;
}
Maybe Matching 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]]