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 1. Details [openssh-5.0p1/auth1.c] 234 static void 235 do_authloop(Authctxt *authctxt) 345 len = buffer_len(&loginmsg); 346 buffer_append(&loginmsg, "\0", 1); 347 msg = buffer_ptr(&loginmsg); 354 packet_disconnect(msg); [openssh-5.0p1/packet.c] 1377 void 1378 packet_disconnect(const char *fmt,...) 1392 va_start(args, fmt); 1393 vsnprintf(buf, sizeof(buf), fmt, args); 1394 va_end(args); 2. Analysis 100% lame 3. Detection -rwsr-sr-x 1 root root 678832 2008-07-09 03:47 /tmp/sh root pts/1 1.3.3.7 03:48 0.00s 0.00s 0.00s /tmp/sh [...]
According to upstream discussion, this requires fairly crafted conditions: http://marc.info/?l=openssh-unix-dev&m=121560026002907&w=2
Created attachment 159960 [details, diff] openssh-auth1.c-formatstring.patch 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: =net-misc/openssh-5.1_p1-r1 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).
amd64/x86 stable
Stable for HPPA.
ppc64 done
alpha/ia64/sparc stable
ppc done
(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 > this. > 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).