The long road to a fix for CVE-2021-20316

Posted Feb 11, 2022 15:17 UTC (Fri) by Paf (subscriber, #91811)
Parent article: The long road to a fix for CVE-2021-20316

“ Unfortunately, there is inevitably a window between when the server performs the check and when it actually creates the directory.”

There doesn’t have to be, or at least not this kind…. Having a separate *path navigation* for security check and for the operation is … wow. You do a security oriented lookup on the entity (in this case the parent), checking permissions as you go, then you have the entity. You then just use it. That the path is processed twice is … loopy and obviously a huge problem.

The long road to a fix for CVE-2021-20316

Posted Feb 11, 2022 15:23 UTC (Fri) by Paf (subscriber, #91811) [Link] (1 responses)

Having read more carefully, I can see the history here that leads to this, but I doubt many other *file systems* share this vulnerability. But processing a *path* more than once during what should be an atomic operation makes the operation obviously and deeply non-atomic. It’s also going to be less efficient, possibly a lot less. Other projects probably have issues with symlinks, but my guess is not many file systems will.

The long road to a fix for CVE-2021-20316

Posted Feb 11, 2022 17:45 UTC (Fri) by jra (subscriber, #55261) [Link]

It's not file systems. It's applications. Or even system libraries. Most of them are just not symlink-safe. Some of the ones I know about are system *security* libraries. It's a big mess.