Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 31 Jan 2017 16:56:09 +0100
From: Sebastian Krahmer <>
Subject: Re: Re: OpenSSH: CVE-2015-6565 (pty issue in 6.8-6.9)
 can lead to local privesc on Linux


On Thu, Jan 26, 2017 at 06:35:12PM +0100, Noryungi wrote:
> Does not work on centos 7.1 (unpatched) running stock openssh.
> TTY capture works, /tmp/sh is created but user is unprivileged.

I can confirm that the exploit is working on a vanilla 4.1.6 kernel
with openssh 6.8. I was a bit puzzled because wrong modes on ttys by itself
should no longer be exploitable on Linux.

Here are my 2ct:

1) Exploit evades the controlling-tty entry-check inside kernels tiocsti()
   that was introduced to cope with hijacking of tty's based on wrong
   modes. Obviously that 'hardening' failed here. Why?
2) Because of glibc's openpty() as called by openssh opens
   the slave device with O_NOCTTY (it has to do so). This leaves
   tiocsti() with pants down, since there is no "controlling owner"
   for this tty yet and the attacker is free to catch on it.
3) The wrong mode (0622) is set, and later openssh calls ioctl(TIOCSCTTY)
   to claim it as the controlling tty for the shell.
   -> The race happens in between them and its just a few syscalls

So the race that needs to be won is actually against the kernels
tiocsti() check, as the wrong mode stays much longer. If the race is
lost, its likely that the open still succeeds, but the injection of
commands is no longer possible. That might explain why the bug was
flagged as "local DoS".

If the race fails, the exploit loop could be tightened to close any fd's in the child,
so the open() automatically gets it as controlling tty and the race
is easier to win.

Kudos to the exploit dev who has PoC||GTFO'ed us.


> On Jan 26, 2017 5:52 PM, <> wrote:
> > Hi list,
> >
> > I know I'm late to the party, but I was bored, so I decided to write an
> > exploit for CVE-2015-6565 which affects OpenSSH 6.8-6.9
> > It is mostly considered to be a "DoS", even though Jann Horn publicly told
> > how it could be exploited for local privilege escalation, but I guess its
> > either PoC||GTFO for users to update.
> >
> > From
> >
> > "sshd in OpenSSH 6.8 and 6.9 uses world-writable permissions for TTY
> > devices, which allows local users to cause a denial of service (terminal
> > disruption) or possibly have unspecified other impact by writing to a
> > device, as demonstrated by writing an escape sequence."
> >
> > I think the description should be updated.
> >
> > $ gcc not_an_sshnuke.c -o not_an_sshnuke
> > $ ./not_an_sshnuke /dev/pts/3
> > [*] Waiting for slave device /dev/pts/3
> > [+] Got PTY slave /dev/pts/3
> > [+] Making PTY slave the controlling terminal
> > [+] SUID shell at /tmp/sh
> > $ /tmp/sh --norc --noprofile -p
> > # id
> > euid=0(root) groups=0(root)
> >
> > Thanks,
> > Federico Bento.
> >
> >
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >


~ perl
~ $_='print"\$_=\47$_\47;eval"';eval
~ - SuSE Security Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.