Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sethmlarson.dev

Post reply on HN
Print view View original

11–20 of 85 posts

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

#11

Post by gchamonlive »

AgentOrange1234 wrote: post #9
SethMLarson wrote: post #3

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…

"if you have a software system that contains two different implementations of IDNA 2003 processing user input" Is that a real thing though? Is someone doing that?

It isn't until it is, until during a crunch someone adds a package with that condition and eventually that gets exploited or halts the system. It's never a nitpick to shed your system from undesired state because of how complex systems behave.

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

#12

Post by kccqzy »

AgentOrange1234 wrote: post #9
SethMLarson wrote: post #3

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…

"if you have a software system that contains two different implementations of IDNA 2003 processing user input" Is that a real thing though? Is someone doing that?

It could be an implementation written in the buggy Python and another written in a different language.

For example you might use a ready-made WAF written in a non-Python language in front of a Python app.

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

#13

Post by tialaramex »

tptacek wrote: post #4
echoangle wrote: post #2

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

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 will choose billing.my-thing.example and name-of-bank.my-thing.example and every other unintended bad choice even before we realise about likelihood of these confusion bugs in software like Python.

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

#14

Post by wren6991 »

echoangle wrote: post #2

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

My favourite example of this is the Chromium bug where enabling floating point flush-to-zero for WebAudio was used to cause deliberate heap corruption: https://issues.chromium.org/issues/382005099

> We have a working exploit (OOB access in the V8 heap), our security folks put one together based on the example I posted above (and they're cleaning it up to post it here). In general, we find that correctness issues like this are pretty much always exploitable with a bit of effort (not even that much effort normally, just gluing together a few gadgets), so we treat correctness issues as security issues until they are proven not to be, rather than the other way around.

The floating-point-to-heap-corruption chain here is... uniquely JavaScript, but in general getting two different implementations to disagree is the start of lots of interesting inconsistent behaviour.

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

#15

Post by xp84 »

tialaramex wrote: post #13
tptacek wrote: 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…

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 know what they're doing into 'BYO DNS name' anyway.

I also like how sites like github use githubusercontent.com or something like that when linking to UGC assets directly, to avoid someone direct linking to something with the implication that it's coming from GitHub.

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

#16

Post by chuckadams »

xp84 wrote: post #15
tialaramex wrote: post #13

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…

It's mostly about not sharing a security context with github.com.

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

#19

Post by rcxdude »

AgentOrange1234 wrote: post #9
SethMLarson wrote: post #3

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…

"if you have a software system that contains two different implementations of IDNA 2003 processing user input" Is that a real thing though? Is someone doing that?

With web applications it's not particularly unusual, because the whole system stack can be quite heterogeneous. If one part of the system is doing authentication and the other part is actually doing the action then it can be a real problem when they interpret the input differently. Differences between proxy and web server interpretations of HTTP headers have been a source of multiple vulnerabilities, for example.

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

#20

Post by cwillu »

AgentOrange1234 wrote: post #9
SethMLarson wrote: post #3

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…

"if you have a software system that contains two different implementations of IDNA 2003 processing user input" Is that a real thing though? Is someone doing that?

Consider the case where your system has components in python and another language without the bug, both of which process that input.
Post reply on HN