linux-kernel - Re: [PATCH] n_tty: Remove LINEMODE support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54BD3E2A.9040401@hurleysoftware.com>
Date:	Mon, 19 Jan 2015 12:26:02 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Theodore Ts'o <tytso@....edu>, Howard Chu <hyc@...as.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Slaby <jslaby@...e.cz>,
	Linux Kernel Mailing List <Linux-Kernel@...r.Kernel.ORG>,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH] n_tty: Remove LINEMODE support

On 01/19/2015 11:37 AM, Theodore Ts'o wrote:
> On Mon, Jan 19, 2015 at 09:57:23AM -0500, Peter Hurley wrote:
>>
>> This reader set EOL2 to DISABLED_CHAR earlier, and left EOL unchanged.
>> I have seen userspace code that expects a line to be no longer than 4096 chars.
> 
> Userspace code that does this is going to be very fragile.  Input from
> the tty really should be considered completely untrustworthy.

Should and do are different modal verbs.

> For example, what if, while the tty is in canonical (ICANON) mode, an
> attacker sets PARMRK and clears IGNPAR, IGNBRK, and BRKINT on the tty
> and then proceeds to send a large number of breaks or parity errors
> down the tty?

The input path limits _all_ canonical lines to 4096 chars. Input beyond that
is discarded until a newline is received. I know this because I broke it
and just recently fixed it.

> That will certainly cause a buffer overflow of said
> userspace process.  So if there is *any* setuid program which isn't
> defensively checking for buffer overruns it's kind of screwed anyway.
> 
>>>> 4. ioctl(TIOCSIG) can send _any_ signal to a different process without
>>>>     permission checks. That's not good.
>>>
>>> It can only send to the pty slave. Permissions were already checked when the pty master was opened.
>>
>> Still not ok.
> 
> Interestingly, TIOCSIG is supported by FreeBSD *and* OpenBSD, and
> without any kind of checks.  That being said, I can certainly think of
> potential security threats that could happen if a malicious program
> were to run a setuid program (say, /bin/passwd) under a pty, and then
> proceeded to send it a one or more of non-trappable signals -- for
> example, either SIGKILL or SIGSTOP -- to either widen the window for a
> race condition, or to kill a setuid program at a particularly
> inconvenient time.

I hadn't considered that possibility.

> It might be interesting to see if someone could figure out an attack
> that utilized this ioctl, and then demonstrated it on OpenBSD.  :-)

I don't need that reputation :)

>>> What further checks do you think are needed? You think it should
>>> be limited to tty-specific signals: INT, QUIT, CONT, TSTP, TTIN,
>>> TTOU, WINCH?
> 
> Definitely, and we should do this sooner rather than later IMHO.
> Preferably before someone figures out whether or not it's possible to
> attack OpenBSD and FreeBSD using this ioctl, and requests a CVE.  :-)

I'm on it.

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/