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

71–80 of 85 posts

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

#71

Post by MattSteelblade »

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…

But it's not literally byte comparison; it's case-insensitive ASCII comparison.

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

#72

Post by shakna »

dmurray wrote: post #49
rcxdude wrote: post #19

Earlier quoted context omitted.

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.

It's not particularly unusual in Python , because it's normal that important functionality is implemented in other languages by a diverse set of third parties. That said, this isn't a security vulnerability, it's just a bug. To meet a reasonable threshold for being a security issue, you need to show a real system that has an issue caused by this, and then the vulnerability is in that system, rather than in Python. I'…

It's not unusual for this sort of string confusion to turn into an SSRF CVE [0].

[0] https://nvd.nist.gov/vuln/detail/CVE-2026-16221

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

#73

Post by tialaramex »

schluss-s wrote: post #68
zrm wrote: post #52

Earlier quoted context omitted.

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

> "Juárez" can be done with ASCII tho

No it can't? Are you thinking of ISO-8859-1 or Windows codepage 1252 maybe?

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

#74

Post by inigyou »

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.

Do you sell to Korea? If so, ask the Korea team. If not, don't allow it.

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

#77

Post by akoboldfrying »

ghusbands wrote: post #57

So someone used lower() from an unspecified version of Unicode when the standard was very specific about which to use. And they say "There's also a database of Unicode 3.2.0 data available on every version of Python (unicodedata.ucd_3_2_0) specifically for the StringPrep and IDNA algorithms", so the right version is available. And then the fix is to hardcode a bunch of special cases which again depend on exactly whic…

I'd assumed that the updating of the B3 dict takes place at runtime, either during module initialisation or lazily at the first call (that is, roughly as late as possible -- certainly, well after the wheel was built), just as a perf optimisation.

But then I realised the code does (and must do) a lookup in the B3 table for each character anyway, so there doesn't seem to be any point. I suppose it means they can load the full 3.2.0 table once, use it to discover the exceptions and then immediately evict it from memory, keeping only the presumably smaller and faster-to-query B3 table of exceptions, but this seems pretty marginal...

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

#79

Post by belorn »

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.

Not all Unicode characters are permitted in DNS, so the parser differential need to exist within the allowed set of Unicode characters. For example, a parser differential on a "space" unicode character won't impact a list of trusted hostnames, since space are not allowed in the first place.

Looking at examples where it could matter, German Sharp S (ß) is allowed in domain names and so a list of trusted hostnames could be fooled if one hostname had a double ss idn-encoded name and the attacker registered a second domain with ß, but there is a caveat here. Looking at how .eu registry handle it, they will not allow two domains to only have the difference between ss and ß, unless they are the same registrant and explicitly request to have both variants (https://eurid.eu/en/knowledge-centre/domain-names-with-speci...). Thus the attack vector will depend on if the registry has protection against it or not.

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

#80

Post by wildzzz »

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.

Simple but less culturally sensitive solution: English is the linga franca so tell them to either romanize their company name or come up with a brand name using latin characters.

삼성전자 can be written as Samseong jeonja in latin characters and translated literally as Tristar Electronics but they do business as samsung.com

I think it's cool that we figured out a way to encode CJK and other foreign script into ASCII-only domain names but if there's a serious concern about opening yourself to domain spoofing because someone picked the wrong encoding, just use ASCII characters.

Post reply on HN