quick copy and paste before I forget...
bannedit pointed us to the following post on f-d:
Mrdkaaa Security Advisory 080709-001
Package : OpenSSH
Date : July 09, 2008
234 static void
235 do_authloop(Authctxt *authctxt)
345 len = buffer_len(&loginmsg);
346 buffer_append(&loginmsg, "\0", 1);
347 msg = buffer_ptr(&loginmsg);
1378 packet_disconnect(const char *fmt,...)
1392 va_start(args, fmt);
1393 vsnprintf(buf, sizeof(buf), fmt, args);
-rwsr-sr-x 1 root root 678832 2008-07-09 03:47 /tmp/sh
root pts/1 18.104.22.168 03:48 0.00s 0.00s 0.00s /tmp/sh
According to upstream discussion, this requires fairly crafted conditions:
Created attachment 159960 [details, diff]
djm committed this patch upstream.
We have "UsePrivilegeSeparation" default to "yes" by default, and I do not know all our PAM modules, and if any of them would allow output of attacker-controlled data.
What's the status here? Which version includes the patch? If we have a stable version in the tree, I'd be in favor of bypassing the policy and closing this one without GLSA, due to the extremely unlikely conditions required to exploit this.
openssh-5.1_p1 has the fix already ... i'm not aware of any regressions specific to that version, so stabilizing it should be OK ...
Thanks. So, let's get this stable.
Arches, please test and stabilize:
Target keywords: alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86
I'm assuming that vapier is OK with -r1 being stabled, according to ChangeLog it's just a fix for a build-time warning though (bug 235594).
Stable for HPPA.
(In reply to comment #3)
> What's the status here? Which version includes the patch? If we have a stable
> version in the tree, I'd be in favor of bypassing the policy and closing this
> one without GLSA, due to the extremely unlikely conditions required to exploit
Actually I'd still like to send a GLSA. Request filed, I'll draft it then.
This issue was resolved and addressed in
GLSA 201405-06 at http://security.gentoo.org/glsa/glsa-201405-06.xml
by GLSA coordinator Mikle Kolyada (Zlogene).