81–85 of 85 posts
If this is a vulnerability every bug in every API is a vulnerability. This is very spacebar-heating. It's not a vulnerability, it's a bug. A system that used this bug in a way that relied on it to perform a security task would have a vulnerability. We need to stop seeing library functions that are not themselves security systems as having vulnerabilities.
> The fix was to create new exceptions so that str.lower() would behave as if it was using Unicode 3.2.0 for only particular function. So, we go through each Unicode codepoint and record when the behavior of str.lower() is different when comparing the Unicode version shipped with Python and Unicode 3.2.0 This sounds like a really hacky solution compared to implementing a separate frozen Unicode 3.2.0 lower.
To be clear (because the snippet is non-explanatory). For encode("idna") what they did is use lower() except where it would produce a result different to 3.2.0 and then instead use the result from 3.2.0 instead. Essentially they've frozen the IDNA encoding to be based on 3.2.0 by overriding any changes.
Unless they have unit testing on the entire Unicode code space to ensure what they're doing is always identical to 3.2.0.
Earlier quoted context omitted.
What’s a way to flag to an engineering team that they should do a thorough review of their usage of a particular API because it has footguns in it? This is a rhetorical question because there isn’t a generally accepted way of doing so. Automatically patch everything is a silly way to do vulnerability management but software is cheap to change, so it’s often easier at scale to just force engineering teams to patch eve…
You could have a CO which emits overridable warnings or requires additional / specific reviewers. Of course that can then lead to warnings fatigue so it’s not necessarily a big improvement, or an improvement at all, in the long run, depends a lot on the org philosophy and habits.
> This is why calling str.lower() represents a difference in the implementation and the specification, and therefore a vulnerability: I wish there was some explanation how this is a vulnerability and not just a bug generating erroneous data. Vulnerability for me sounds like there’s a reasonable way to create an exploit from the bug, and I don’t see one here as someone who’s not very familiar with the topic.
It creates a parser differential; two different components of the system can treat the same string as different hostnames. Things that have trusted hostnames, or privileged/admin hostnames that are screened out, or SSRF filters all depend on accurately comparing presented hostnames. This is pretty situational, though, isn't it? You still have to be dealing with IDN names.
Earlier quoted context omitted.
It creates a parser differential; two different components of the system can treat the same string as different hostnames. Things that have trusted hostnames, or privileged/admin hostnames that are screened out, or SSRF filters all depend on accurately comparing presented hostnames. This is pretty situational, though, isn't it? You still have to be dealing with IDN names.
IDN is a security flaw masquerading as a standard.