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: <ca2a101ccf5ae790dd2cac58ff832922@finder.org>
Date: Fri, 13 Dec 2024 21:13:54 -0800
From: Jared Finder <jared@...der.org>
To: Günther Noack <gnoack@...gle.com>
Cc: Jann Horn <jannh@...gle.com>, Hanno Böck
 <hanno@...eck.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri
 Slaby <jirislaby@...nel.org>, linux-hardening@...r.kernel.org,
 regressions@...ts.linux.dev, kernel list <linux-kernel@...r.kernel.org>
Subject: Re: GPM & Emacs broken in Linux 6.7 -- ok to relax check?

On 2024-12-03 06:07, Günther Noack wrote:
> On Tue, Dec 03, 2024 at 02:53:27PM +0100, Günther Noack wrote:
>> Hanno, you are the original author of this patch and you have done a 
>> more
>> detailed analysis on the TIOCLINUX problems than me -- do you agree 
>> that this
>> weakened check would still be sufficient to protect against the 
>> TIOCLINUX
>> problems?  (Or in other words, if we permitted TIOCL_SELPOINTER, 
>> TIOCL_SELCLEAR
>> and TIOCL_SELMOUSEREPORT for non-CAP_SYS_ADMIN processes, would you 
>> still see a
>> way to misuse that functionality?)
> 
> P.S.: For reference, some more detailed reasoning why I think that that 
> proposal
> would be OK:
> 
> It would protect at least against the "minittyjack.c" example that was 
> attached
> to https://www.openwall.com/lists/oss-security/2023/03/14/3
> 
> The trick used there was:
> 
> * ioctl() with TIOCLINUX with TIOCL_SETSEL with TIOCL_SELLINE,
>   to make a selection (a.k.a. changing the contents of vc_sel)
> * ioctl() with TIOCLINUX and TIOCL_PASTESEL to paste the selection.
>   (The implementation for that is in selection.c/paste_selection()
>   and is just copying from vc_sel.)
> 
> So as long as we are protecting the change to vc_sel, that should be OK 
> in my
> mind.

It's been silent for about a week and a half here. How long do we wait 
before creating a patch here? This is a regression so I'm assuming we 
shouldn't wait too long.

I'm happy to create the patch if that's helpful. I'd need help with 
process for submitting it for inclusion in the latest kernel as well as 
backports to earlier impacted versions. I've never submitted code to 
Linux before.

   -- MJF

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ