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

21–30 of 85 posts

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

#21

Post by cwillu »

chuckadams wrote: post #16
xp84 wrote: post #15

Earlier quoted context omitted.

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.

Yes, but github.cc or whatever would have sufficed for that; there's a reason the string they chose to register for prominent public use contains “usercontent”

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

#25

Post by smallerize »

K0IN wrote: 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".

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

#27

Post by gcr »

SethMLarson wrote: post #3
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.

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…

That would be a vulnerability in the IDNA filter that they’re responsible for fixing.

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

#28

Post by ummonk »

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

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

#30

Post by jerf »

SethMLarson wrote: post #3
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.

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 job is arguably to be more sensitive to that than most engineers, but not that sensitive. It would be like flagging all instances of string concatenation as a vulnerability... and I say that as the guy who would like to eliminate simple string concatenation from programming languages, already a very extreme position on that operation, because of it being at the root cause of so many vulnerabilities... but simply flagging every use as a "vulnerability" is way too sensitive. A demonstration of the ability to use it to bypass some sort of security barrier is necessary to call any specific instance a "vulnerability".

And string concatenation has caused orders of magnitude more actual, verified vulnerabilities than incorrect case folding has.

Post reply on HN