Thread by @ErrataRob

So Exim has another RCE vuln. I'm reading the code right now. It's awful. It's everything wrong with early Internet code. A guide on how-not-to-code would use Exim as the example.

The bug is in the SSL "server_name" or "SNI" field, in which the connecting side tells the server which name they are connecting to. This way, when you connect to "example.com" hosted by GMail, you can get the SSL certificate for Example and not GMail.

The bug is that if the SNI string ends with "$\", then bad things happen. Okay, that's a simple bug, and we shouldn't blame people for simple bugs. However, the entire stack leading to that bug is what we should blame them for.

For one thing, the bug is in "pointer arithmetic". As I've blogged and tweeted about before, "pointer arithmetic" is bad, and you need to stop doing it. Had this code not used pointer arithmetic, this bug wouldn't have happened.

Pointer-arithmetic is expressions like "*(++p)" in the above code. It's not valid for other languages, which would need to do something like "p[++offset]" instead. It encourages you that check whether "offset < length" all the time, which makes such bugs less likely.

"Pointer-arithmetic" is considered "idiomatic C", and you are encouraged to write idiomatic code. But the reality is that "pointer-arithmetic" is idiotic C. It has none of the advantages you think, and you need to stop using it. Refactoring code getting rid of it is important.

But this is only the start of the problems in the code. @sergeybratus is going to be mad at me if I don't mention this: "The input language is undefined". In other words, what's the allowable format for the SNI field? The answer is that this is undefined, nobody really knows.

@sergeybratus You think it should be a DNS name. If Exim code where well-written, thats exactly the check it would apply to the code, at the first opportunity. An incoming SNI name that wasn't a valid DNS name would be immediately rejected.

@sergeybratus Instead, the code passes the binary characters through the system. What this means is that input has a "language", it will drive computation in the code, it's just that nobody knows precisely what that "language" is, least of all the programmer.

@sergeybratus So how did Exim fix the bug? By sanitizing input? No. By fixing a bug buried within this "language" of theirs in how they interpret escape characters.

@sergeybratus Because SNI server names aren't sanitized on input, they touch a vast amount of code. It's essentially a Turing-complete input field when it should be simply a DNS hostname.

@sergeybratus The fact that input strings are passed into this Turing-complete Exim language has been the source of other bugs as well, such as CVE-2019-10149, where simply the Recipient's name in an email can lead to code execution.

@sergeybratus I may not have been clear about the Turing-complete language that Exim applies to the SNI field (and all these other fields). You can find the documentation here. TRIGGER WARNING: you may run from your computer in terror.
exim.org/exim-html-curr…

@sergeybratus This tweet defending pointer-arithmetic is a great demonstration of why I'm right: "pointer-arithmetic is fine if you don't make the same mistake people usually make with it".

https://twitter.com/sxpert1/status/1170243886356279302

@sergeybratus Pointer-arithmetic is inherently more dangerous than the alternative. Our fight is against dangerous coding practices, encouraging programmers to choose safer paradigms.