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]

Date:	Sun, 18 Jan 2015 17:22:46 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Howard Chu <hyc@...as.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH] n_tty: Remove LINEMODE support

Hi Howard,

On 01/18/2015 05:09 PM, Howard Chu wrote:
> Peter Hurley wrote:
>> Commit 26df6d13406d1 ("tty: Add EXTPROC support for LINEMODE") added
>> the undocumented EXTPROC input processing mode, which ignores the ICANON
>> setting and forces pty slave input to be processed in non-canonical
>> mode.
>>
>> Although intended to provide a transparent mechanism for local line
>> edit with telnetd (and other remote shell protocols), the transparency
>> is limited.
>>
>> Userspace usage is abandoned; telnetd does not even compile with
>> LINEMODE support. readline/bash and sshd never supported this.
> 
> I object to this. Code for all of the above exists and works. I use this code daily.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585527
> http://lists.gnu.org/archive/html/bug-readline/2011-01/msg00004.html
> https://github.com/hyc/OpenSSH-LINEMODE
> 
> The lack of LINEMODE support in upstream sshd can only be considered a security hole.
> 
> http://www.metzdowd.com/pipermail/cryptography/2015-January/024288.html

These are all bug reports about userspace _not_ supporting this extension.

Where is a working userspace consumer of this interface?

I seriously doubt this works reliably.
What happens when the pty slave reader is in canonical mode and gets unterminated
input because only a portion of the input is available yet? The way this is
coded does _not_ require line termination before returning data to userspace.

Also, ioctl(FIONREAD) doesn't match what read() returns, nor that poll()/select()
indicated input was available.

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/