Live data from Hacker News

When str.lower() is a security vulnerability in Python

sethmlarson.dev

31–40 of 85 posts

Re: When str.lower() is a security vulnerability in Python

#33
post #4

> 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.

I can see how this would be a vulnerability in the context of a security researcher that wants to exaggerate their findings in order to get paid a bounty.

Re: When str.lower() is a security vulnerability in Python

#35
post #17

I was also startled when python did ß.upper() returns "SS". Which is kind of unsuspected in some cases (if string length changes with an upper call)

That's in the standard. https://www.unicode.org/reports/tr21/tr21-5.html [SpecialCasing] Contains additional case mappings that map to more than one character, such as "ß" to "SS".

5.1 adds uppercase ẞ which can fold to either ss or lowercase ß depending on the chosen algorithm.

Re: When str.lower() is a security vulnerability in Python

#37
post #30

Earlier quoted context omitted.

Author here, that's a good idea. A straightforward way to exploit an implementation differential like this is if you have a software system that contains two different implementations of IDNA 2003 processing user input. One part of the process processes the domain correctly, the other incorrectly, and in this case you can have one part of a system (such as a policy/filter) "see" the data one way and the other part of…

I wouldn't call this a "vulnerability", I'd call it "a thing that can potentially turn into a vulnerability, more often it can turn into an obscure bug, and most often it is just a quirk". In particular, if my corporate security team started just mass-flagging all instances of "str.lower" as "security bugs" I would be having a talk with their manager about their threshold for what constitutes a "security bug". Their…

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 even if it doesn’t make sense in context.

I’m not a fan of this approach, but I can understand why it’s so popular.

Re: When str.lower() is a security vulnerability in Python

#39
post #4

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.

It is situational, but it very much seems like a thing you'd squirrel away and bring out when you find a system where the differential is helpful. DNS names are a thing where Sales is going to tell the Engineer that they can't issue the customers randomized ASCII names like abxuewrf.my-thing.example because real customers want to write our-brand-name.my-thing.example instead - even though you already know bad guys wi…

Solution: customer emails you to request a name

Re: When str.lower() is a security vulnerability in Python

#40
post #15

Earlier quoted context omitted.

It is situational, but it very much seems like a thing you'd squirrel away and bring out when you find a system where the differential is helpful. DNS names are a thing where Sales is going to tell the Engineer that they can't issue the customers randomized ASCII names like abxuewrf.my-thing.example because real customers want to write our-brand-name.my-thing.example instead - even though you already know bad guys wi…

That's why for that type of 'semi-white-label' thing, since the main risk is one of impersonating the platform owner (like the billing.my-thing.example) or possibly lending the credibility of "our" brand to some rando UGC, I always push for the most boring and generic second-level domain, like if it's the travel business, 'travel-systems dot us' or in edtech, mylearningplatform dot net... Then push all customers who…

That's actually to prevent cookie stealing.
Post reply on HN