When URL parsers disagree (CVE-2023-38633)
(www.canva.dev)
from snaggen@programming.dev to rust@programming.dev on 08 Sep 2023 05:09
https://programming.dev/post/2715636
from snaggen@programming.dev to rust@programming.dev on 08 Sep 2023 05:09
https://programming.dev/post/2715636
threaded - newest
@snaggen I think the better lesson than "don't mix URI parses" here is "don't LBYL, rely on EAFP". Many "Look before you leap" (LBYL) schemes are subject to variations of time-of-check/time-of-use errors. It's preferable to not sanitize input, but tell the processor what the policy on processing is; when it comes to a violation, it's easier to ask forgiving (i.e. report the error) than permission (EAFP).
No. It’s “don’t mix URI parses”.
Or if you want to be more specific, it’s “make sure security-sensitive paths are maximally specified, safely constructed, and maximally typed all the way”.
A combination of
file://URLs being under-specified, and a C library (and not any C library, butglib, a special level of shit) predictably offering crap interface and contract guarantees (and hidden bugs to boot, yay).This reaching attempt for some shallow generic common wisdom explanation actually reminds me of my first ever Lemmy discussion, where URLs were also incidentally involved.
The very same type of mistakes happens in file systems even without URIs being involved. Directory traversal checks look simple but sooner or later need hard-to-understand symlink following rules. Enforcing processor policy has terrible portability there (it even only became practical on Linux with landlock), but nonetheless I think it's preferable.
Not mixing URI parsers is a good advice for when processor policies are unavailable – but let's try to make them available more often.