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

Why did the OpenSSL punycode vulnerability happen?

words.filippo.io

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Why did the OpenSSL punycode vulnerability happen?

#81

Post by pjmlp »

wahern wrote: post #49
tptacek wrote: post #42

Earlier quoted context omitted.

Even in C, you can write an abstraction for a growable buffer. The problem is, you have to make all the rest of the code work with it, rather than a char* or whatnot.

BoringSSL and libressl added CBS (bytestring) and CBB (bytebuilder) interfaces in 2015. Converting everything over is a chore, but that's exactly what those projects have been methodically doing over the years. Unfortunately, I don't see those interfaces in OpenSSL 3.0, though maybe (hopefully) they're working toward something similar.

How many projects have to keep re-inventing those kind of data structures until WG14 takes security seriously?

Re: Why did the OpenSSL punycode vulnerability happen?

#82

Post by pjmlp »

tester756 wrote: post #26
insanitybit wrote: post #23

Earlier quoted context omitted.

> In what kind of software bounds check have this significant perf. penalty? All kinds. But a lot of it is just that parsers are extremely easy to benchmark and benchmarks promote optimization. > Cannot C have some wrapper over those poor strings Sure, but there's nothing native.

>Sure, but there's nothing native. But why? strings are used by all programmers everyday I struggle to understand why you wouldn't want to make them state of the art, or decent at least.

Because WG14 doesn't care about security, for them C is basically a portable macro assembler with added conveniences.

Re: Why did the OpenSSL punycode vulnerability happen?

#83

Post by ahoog42 »

cesarb wrote: post #77
ahoog42 wrote: post #72

I decided to review SBOMs from about 3,800 popular mobile apps to see if any included vulnerable versions of OpenSSL v3.0.x. No mobile apps did (not surprised) but what did surprise me was 98% of the OpenSSL versions included in these apps were vulnerable to older CVEs. About 16% of the apps included OpenSSL, mostly as a transitive dependency. I posted additional details in this blog+video: https://www.andrewhoog.com…

> No mobile apps did (not surprised) but what did surprise me was 98% of the OpenSSL versions included in these apps were vulnerable to older CVEs. Just the openssl version is not enough, since it could be patched to fix vulnerabilities without increasing the version (this is very common on Linux distributions, which often apply security patches instead of migrating to a new version; for instance, Fedora released a p…

Great points.

Static binary analysis looks for the version string but doesn’t currently do deeper analysis of reversed code to see if it’s patched. Could go either way.

And determining if the code is triggered and exploitable is quite challenging. Dynamic analysis can help here, provided you have the coverage.

More generally tho, istm that there will be instances when the version is unpatched and there is some exploitable vector (even if it’s just crashing the app). My hope is to raise awareness for developers (and security) about 1) transitive dependencies and 2) some really old OpenSSL versions in very popular mobile apps. I don’t believe most folks think about this and awareness can lead to shipping safer apps.

Re: Why did the OpenSSL punycode vulnerability happen?

#84

Post by tialaramex »

FiloSottile wrote: post #32
AceJohnny2 wrote: post #28

> As curl author Daniel Stenberg said, "I've never even considered to decode punycode. Why does something like OpenSSL need to decode this?" > [...] > Internationalization is not the issue, internationalization is the job. I want to cheer at this. Internationalization is hard , really hard, especially in a computing world so defined by its english-language dominance. The little amount of effort demonstrated in defini…

Oh I don't think Daniel was asking why we're doing i18n. My remark was not at him, at all. I was just pre-empting a possible made up objection. He's in fact correct to wonder why punycode decoding ended up in OpenSSL , as the rest of that section explores. The point being that OpenSSL could do its job and still support i18n domains and emails without having to ever decode punycode if only the spec had made different…

Exactly this. I had the very image of this discussion with Python folks for DNSname SANs back when Python was learning not to just rely on CN.

Python folks felt like the correct thing was: 1) Implement a Punycode decoder. 2) Decode hostnames and certificate information to get Unicode 3) Compare the Unicode Strings. They were fretting about how complicated it would be to arrange all this, the months of work needed and the need to bring in teams who understood about i18n issues...

And I was like No, don't do any of that, take the bytes and compare the bytes. If the bytes aren't identical that's not a match, you are done. It seemed to take a while for it to sink in that this is correct and simpler and thus better.

Re: Why did the OpenSSL punycode vulnerability happen?

#85

Post by zaarn »

cesarb wrote: post #78
zaarn wrote: post #65

Earlier quoted context omitted.

It should be noted that you can simply use the fallible API's for slices in Rust, then you don't have a crash but can cleanly abort the operation and return an error.

True, but it doesn't make much sense to use the fallible slice APIs when you know they will never fail (the only way they could fail would be if the code has a bug). It would just complicate not only the code within the function, but also the API to the function, which also becomes a fallible API (and this propagates outward, until it meets a caller which already was fallible for other reasons). And complicating the…

IMO you should use the fallible slice API's in any safety-critical code, such a cryptographic code.

Yes, there is more code, but it does not become a lot more complex, if you need to you can unwrap to explicitly panic. You should still insert asserts to catch issues. But if there is an issue, such as running out of memory or anything else, you can handle it more appropriately than producing a Denial-of-Service issue immediately, which is definitely not good.

Re: Why did the OpenSSL punycode vulnerability happen?

#86

Post by jesprenj »

Why would a TLS library even parse punycode? The sole reason we still use this hack is so that core infrastructure does not have to change when we use internationalized domains.

If TLS libraries, DNS servers, HTTP servers, ... needed to be patched anyways for the use of IDNs, then why did we not do it properly and just use UTF-8?

No matter how many vulnerabilities we've introduced into software, "Š" in my name still cannot be represented in domain names and is instead written with american letters xn--pga.

I'm sorry for poorly articulating my thoughts here.

Re: Why did the OpenSSL punycode vulnerability happen?

#87

Post by zaarn »

zaphar wrote: post #80
cesarb wrote: post #78

Earlier quoted context omitted.

True, but it doesn't make much sense to use the fallible slice APIs when you know they will never fail (the only way they could fail would be if the code has a bug). It would just complicate not only the code within the function, but also the API to the function, which also becomes a fallible API (and this propagates outward, until it meets a caller which already was fallible for other reasons). And complicating the…

It's actually preferrable in many of those "infallible" cases to panic rather than handling the error since it usually indicates that your application is in unknown territory and there is no "safe" way to handle it.

If you're writing cryptographic code, panicking for every issue is not good, that's a DoS vector that could be easily exploited. It's safer to handle the error in-band and let the application higher up decide if it should panic, error or continue.

Re: Why did the OpenSSL punycode vulnerability happen?

#88

Post by boxy_brown »

jesprenj wrote: post #86

Why would a TLS library even parse punycode? The sole reason we still use this hack is so that core infrastructure does not have to change when we use internationalized domains. If TLS libraries, DNS servers, HTTP servers, ... needed to be patched anyways for the use of IDNs, then why did we not do it properly and just use UTF-8? No matter how many vulnerabilities we've introduced into software, "Š" in my name still…

> Why was this code even necessary

> The answer is: an explicit IETF design choice, that made punycode decoding part of X.509 verification, without even a line of acknowledgement in the Security Considerations.

Re: Why did the OpenSSL punycode vulnerability happen?

#90

Post by account42 »

mike_d wrote: post #34
j-bos wrote: post #29

Earlier quoted context omitted.

I am by no means a rust developer and asking in ignorance, would this have been a problem had it been written in rust?

It is an exercise in navel gazing until an organization steps up to fund: 1) a linkable clib harness that exports Rust functions to replace OpenSSL functions. and 2) pays to get the resulting harness and underlying code FIPS certified so people can use it.

Most people have no problem using non-FIPS-certified code so that is not a precondition for the effort being useful.
Post reply on HN