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

61–70 of 84 posts

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

#61

Post by philipwhiuk »

ummonk wrote: post #28

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

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

#63

Post by ryukoposting »

philipwhiuk wrote: post #61
ummonk wrote: post #28

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

Yeah. I can understand the confusion, though. The title claims the issue was in lower(). Though the problem was actually in encode('idna')'s usage of lower().

The article would probably get far fewer clicks if it were named "when encode('idna') is a security vulnerability"

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

#66

Post by ltpoll »

tialaramex wrote: post #8

This idiocy is a big part of why it was so important to get Python people working on TLS implementations to understand that the defined mechanism for SANs (no the "alternative" in Subject Alternative Name doesn't mean in the sense of more than one, X.509 is originally for the X.500 system and the Internet repurposed X.509 so these are alternative names from the Internet) says that these are DNS names, they specifical…

This sums up the whole Unicode disaster in Python3. People are conditioned to "encode" and "decode".

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

#67

Post by ltpoll »

Python itself should not be used at all to handle any server, or heaven forbid, TLS connections.

The Python core developers barely know anything about SSL apart from aggressively updating openssl versions and making a big show of the "security" implied by the updates.

Naturally the jocks [1] from AlphaOmega sponsor this bottomless pit. They didn't give curl access to Mythos, but if you talk the talk, projects beyond repair get money.

My advice to college students: Create a completely broken project with a big foundation and many president and director titles. Talk and network at conferences until you get money to perpetually fix the mess.

[1] A look at their website should disabuse dreamers of the recent notion that nerds and "weird" people will be in charge in the future.

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

#68

Post by schluss-s »

zrm wrote: post #52
inigyou wrote: post #39

Earlier quoted context omitted.

Solution: customer emails you to request a name

How does the customer service rep tell that a name with some Unicode gubbins is an attack rather than a customer from Juárez or 서울? Having a busy hand copy and paste the attacker-provided string into the system doesn't get you out of it.

"Juárez" can be done with ASCII tho

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

#69

Post by cobbzilla »

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.

IDN is a security flaw masquerading as a standard.
Post reply on HN