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
