linux-kernel - Re: [RFC] Add a prctl to disable ".." traversal in path resolution

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: <20241213-raupen-jodhaltig-15b59bde264b@brauner>
Date: Fri, 13 Dec 2024 13:55:07 +0100
From: Christian Brauner <brauner@...nel.org>
To: Aleksa Sarai <cyphar@...har.com>
Cc: Matthew Garrett <mjg59@...f.ucam.org>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Add a prctl to disable ".." traversal in path resolution

On Thu, Dec 12, 2024 at 02:56:59AM +1100, Aleksa Sarai wrote:
> On 2024-12-11, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> > Path traversal attacks remain a common security vulnerability
> > (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22path+traversal%22)
> > and many are due to either failing to filter out ".." when validating a
> > path or incorrectly collapsing other sequences of "."s into ".." .
> > Evidence suggests that improving education isn't fixing the problem.
> 
> I was thinking about adding a RESOLVE_NO_DOTDOT which would do something
> like this but on a per-openat2-call basis.

That's what I was thinking a while ago. I discussed that with Linus
in connection to a change by Jann for looking up module paths.

https://lore.kernel.org/r/CAADWXX_zpqzYdCpmQGF3JgsN4+wk3AsuQLCKREkDC1ScxSfDjQ@mail.gmail.com

> 
> The main problem with making this global for the entire process is that
> most tools would not be able to practically enable this for themselves
> as it would require auditing the entire execution environment as well as
> all dependencies that might dare to use ".." in a path anywhere in their
> codebase.

I agree.