Why did the OpenSSL punycode vulnerability happen? • Hacker News Board

Re: Why did the OpenSSL punycode vulnerability happen?

#101

Post by cratermoon » Sat, Nov 05, 2022, 12:27 AM UTC

rurban wrote: post #99

midoridensha wrote: post #57

Earlier quoted context omitted.

>Also, as we learned back when Heartbleed was discovered, the OpenSSL code is not in good shape. It "suffers from maintenance", as one clever wag said about legacy code. There's a reason LibreSSL forked the code. More distributions need to switch away from OpenSSL. Anyone who's ever worked with the OpenSSL API or looked at its code can tell you that it's a steaming pile of crap. It's no surprise that this vulnerabili…

I just started making openssl -Werror safe. Oh my, what did I get into. Halfway through it's about 125 changed files, > 1000 changes. look at the WIP commit. The API is insane. 50% of args are unused. All the structs and vtables updates are uninitialized, ie missing methods. https://github.com/rurban/openssl/commits/Werror

One of the (possibly first?) things the LibreSSL people did after forking OpenSSL was to enable -Wall, -Werror, -Wextra, -Wuninitialized on the code[1]. Many years ago we'd look at compiler (and linter) warnings with a skeptical eye, but these days, they really mean something. That alone smoked out a lot of lurking problems.

1 https://en.wikipedia.org/wiki/LibreSSL#Proactive_measures

Re: Why did the OpenSSL punycode vulnerability happen?

#102

Post by fulafel » Sat, Nov 05, 2022, 8:02 AM UTC

tptacek wrote: post #42

mikepavone wrote: post #25

> There is a function, ossl_punycode_decode that decodes Punycode. Punycode is a way to encode Unicode as ASCII, used to represent Unicode strings in the ASCII-only world of DNS. ossl_punycode_decode takes an output buffer, and if the buffer runs out it keeps parsing and verifying the Punycode but discards the rest of the output. > I did not have the heart to figure out why it works like this. Maybe there's a good re…

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.

Or you can use char * and realloc (or a callback) for it to grow, if you're not forced to use caller allocated buffers.

Re: Why did the OpenSSL punycode vulnerability happen?

#103

Post by fulafel » Sat, Nov 05, 2022, 8:15 AM UTC

tester756 wrote: post #7

It feels like issues like those are more common in parsers, this specific kind of software. But why? Why is parsing so hard? or is it just in low lvl languages? or maybe languages with poor string primitives? I've written parsers in high level languages and it didnt felt dangerous or insanely hard

Your questions are less interrelated than you might think.

Why is general parsing hard? It's sense-making from free form input. We have so many different languages and syntaxes and there are different algorithmic approaches needed to parse them depending on the format and language, frequently made as dense as possible for various more or less (usually more) misguided "optimization" reasons.

Why is parsing in low level languages hard? This is more about incidental features of low level languages. C just happens to be exceptionally unsuited and unsafe for the tasks involved in parsing. From a safety and security POV C is chainsaw juggling, but C for parsing untrusted data is chainsaw juggling while running through a mine field.

Re: Why did the OpenSSL punycode vulnerability happen?

#104

Post by alserio » Mon, Nov 07, 2022, 5:04 PM UTC

toast0 wrote: post #31

alserio wrote: post #18

Earlier quoted context omitted.

I'll give you a tautological and useless answer. I hope you don't mind. A parser is a kind of interpreter, where code is executed based on external input. When user input controls how code is executed you have opened the doors of hell: it's hard to guarantee that all of the possible executions are safe.

Here's an even more tautological answer. You can't misparse input unless you're parsing input. That's why parsers have trouble with parsing input.

true