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

71–80 of 104 posts

Re: Why did the OpenSSL punycode vulnerability happen?

#71

Post by bombolo »

Elinvynia wrote: post #66
vore wrote: post #33

Earlier quoted context omitted.

Rust would take the growable container approach here, so it wouldn't be vulnerable in the same way. There's nothing in C that prevents you from doing this either, but as the parent post mentions it's common style to do this (see also things like snprintf).

> There's nothing in C that prevents you from doing this either Yet these errors consistently happen in C projects of various sizes.

Because all the important and used stuff that gets looked at is written in C.

At the moment rust is used for some very marginal and unimportant leaf projects.

Re: Why did the OpenSSL punycode vulnerability happen?

#72

Post by ahoog42 »

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/post/how-to-detect-openssl-v3-and...

Re: Why did the OpenSSL punycode vulnerability happen?

#74

Post by bombolo »

tester756 wrote: post #21
0xbadcafebee wrote: post #12

Earlier quoted context omitted.

The first level of complexity comes from the format. A bit array is super easy to parse (in C, and assuming you take care of endianness). JSON is more complicated; YAML is more complicated than JSON; XML is more complicated than YAML; X.509 is more complicated than XML (I think, anyway). The more complex the data format, the more complex the parsing; the more complex; the more opportunity for bugs. The second level o…

>"Why does it seem easier in high-level languages?" High-level languages have slowly had their bugs stripped out, and give you features that are rarer in low-level languages. You literally aren't writing the same routines in high-level languages because you don't need to. If you had to do all the same things, you'd have the same bugs. And a lot of newbies simply are lucky and don't personally run into the bugs that a…

> Why in lower level languages people cannot write some handy abstractions which will result in better security and dev. experience?

Because those programs are sloooooooooooooooooooooooooooooow

Re: Why did the OpenSSL punycode vulnerability happen?

#75

Post by int_19h »

insanitybit wrote: post #27
tester756 wrote: post #26

Earlier quoted context omitted.

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

C is an extremely conservative language. You don't even get booleans unless you're in C99 and import it.

You do get them without #include , you'll just have to contend with ugly spellings like _Bool and _True.

Re: Why did the OpenSSL punycode vulnerability happen?

#76

Post by anjbe »

int_19h wrote: post #75
insanitybit wrote: post #27

Earlier quoted context omitted.

C is an extremely conservative language. You don't even get booleans unless you're in C99 and import it.

You do get them without #include , you'll just have to contend with ugly spellings like _Bool and _True.

bool, true, and false as native keywords are on track to show up in C23. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2393.pdf

Re: Why did the OpenSSL punycode vulnerability happen?

#77

Post by cesarb »

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 patched 3.0.5 instead of going to 3.0.7).

And using an older openssl version does not necessarily mean it's using vulnerable code; according to your blog post, the most common use is SQLCipher, which from a quick look at its README.md seems to use openssl only for the encryption algorithms. Unless the vulnerability was on the basic algorithms used (AES, HMAC, etc), it won't affect this usage.

Re: Why did the OpenSSL punycode vulnerability happen?

#78

Post by cesarb »

zaarn wrote: post #65
cesarb wrote: post #52

Earlier quoted context omitted.

> would this have been a problem had it been written in rust? The answer would be "it depends on whether you consider denial-of-service a problem". The key detail which makes all the difference is that, unless you're playing with raw pointers (which can only be dereferenced in "unsafe" blocks), the pointer to a buffer slice is always kept together with its length (in a "fat pointer"). Attempting to write through it p…

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 code unnecessarily increases the chance of logic bugs.

Re: Why did the OpenSSL punycode vulnerability happen?

#79

Post by Joker_vD »

Sankozi wrote: post #69
kevin_thibedeau wrote: post #54

Earlier quoted context omitted.

Then you have the new problem of restricting its growth and that adds a new failure mode to deal with. The C idiom works fine if you don't have implementation bugs.

Null terminated string is probably the worst data structure that was invented. It is has caused numerous security problems. It takes worst performance characteristics from array and linked lists (slow resizing, slow indexing). It definitely does not work fine.

Resizing arrays is such an annoying problem... because memory address space is flat. If only we had some sort of resizeable, non-overlapping by design segments, kind of like we have virtual memory mappings... but that'd completely kill address arithmetic. Oh well.

Re: Why did the OpenSSL punycode vulnerability happen?

#80

Post by zaphar »

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…

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.
Post reply on HN