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:	Fri, 1 Feb 2013 12:59:37 -0500
From:	Josh Boyer <jwboyer@...il.com>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	gregkh@...uxfoundation.org, alan@...ux.intel.com,
	jirislaby@...il.com, linux-kernel@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Bryan Mason <bmason@...hat.com>
Subject: Re: [PATCH] TTY: do not reset master's packet mode

On Tue, Jan 15, 2013 at 5:26 PM, Jiri Slaby <jslaby@...e.cz> wrote:
> Now that login from util-linux is forced to drop all references to a
> TTY which it wants to hangup (to reach reference count 1) we are
> seeing issues with telnet. When login closes its last reference to the
> slave PTY, it also resets packet mode on the *master* side. And we
> have a race here.
>
> What telnet does is fork+exec of `login'. Then there are two
> scenarios:
> * `login' closes the slave TTY and resets thus master's packet mode,
>   but even now telnet properly sets the mode, or
> * `telnetd' sets packet mode on the master, `login' closes the slave
>   TTY and resets master's packet mode.
>
> The former case is OK. However the latter happens in much more cases,
> by the order of magnitude to be precise. So when one tries to login to
> such a messed telnet setup, they see the following:
> inux login:
>             ogin incorrect
>
> Note the missing first letters -- telnet thinks it is still in the
> packet mode, so when it receives "linux login" from `login', it
> considers "l" as the type of the packet and strips it.
>
> SuS does not mention how the implementation should behave. Both BSDs I
> checked (Free and Net) do not reset the flag upon the last close.
>
> By this I am resurrecting an old bug, see References. We are hitting
> it regularly now, i.e. with updated util-linux, ergo login.
>
> Here, I am changing a behavior introduced back in 2.1 times. It would
> better have a long time testing before goes upstream.
>
> Signed-off-by: Jiri Slaby <jslaby@...e.cz>
> Cc: Mauro Carvalho Chehab <mchehab@...hat.com>
> Cc: Bryan Mason <bmason@...hat.com>
> References: https://lkml.org/lkml/2009/11/11/223
> References: https://bugzilla.redhat.com/show_bug.cgi?id=504703
> References: https://bugzilla.novell.com/show_bug.cgi?id=797042

Shouldn't this be CC'd to stable?

josh
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ