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: <2034358.szW3sdo6f8@archbook>
Date: Wed, 11 Dec 2024 16:51:53 +0100
From: Nicolas Frattaroli <frattaroli.nicolas@...il.com>
To: linux-fsdevel@...r.kernel.org, Matthew Garrett <mjg59@...f.ucam.org>
Cc: linux-kernel@...r.kernel.org, Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [RFC] Add a prctl to disable ".." traversal in path resolution

On Mittwoch, 11. Dezember 2024 15:29:29 Mitteleuropäische Normalzeit Matthew Garrett 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.

Hi Matthew,

I get the motivation here, but I think you've just turned "educate about
handling .. properly" into "educate about this specific mitigation".

Linux already offers a multitude of ways in which people who deploy
potentially buggy applications can restrict which files these applications
have access to, from old fashioned UNIX permissions over SELinux and other
LSMs to namespaces. (Some software, like postfix, even thinks chroots are
appropriate for this, but I think modern understanding of security would
disagree with that.)

People who fall victim to path traversal vulnerabilities in actual
deployments will not have deployed any of those mitigations, and therefore
I don't see why they would deploy this one.

As sad as it is to see that supposed enterprise security network appliances
still fall victim to the same mistakes people's CGI perl scripts did in
the 90s, I don't think the ones who would opt into this mechanism are the
ones getting got through path traversal.

> The majority of internet-facing applications are unlikely to require the
> ability to handle ".." in a path after startup, and many are unlikely to
> require it at all.

I would like to see some evidence of that. Do webservers already realname
the path when a client asks for example.com/foo/../css/bar.css? If so,
there's no path traversal vulnerability, if not, then they do require it.

Cheers,
Nicolas Frattaroli