Robert David Graham (robert_david_graham.delete@this.yahoo.com) on July 13, 2020 2:36 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 13, 2020 11:06 am wrote:
> > If you have to normalize, do it only at literal "untrusted user entry". In that graphical
> > UI box that the user actually types in. Or that network input side processing that
> > expects a character string. Do the normalization there, and do it before you start
> > parsing anything. If you do it any later, you're screwed and did it wrong.
> >
>
> Good advice, but also wrong.
>
> Almost every boundary between two pieces of software is "untrusted user entry", either two things
> communicating across a network, or something calling into library.

Disagree. Calling a library that has entire or almost entire access to your address space, to do work on something where you don't trust its result? Insane. If you don't trust your library, then you can't use it. Simple.

And network communication varies completely. You absolutely can "trust" your network data at one level if trust and integrity are established at other levels. Often network data is checked a bit more even in that case because its easy and possible at the performance scales you're dealing with. But not always. Clustered storage or RDMA or very high speed cluster? Network over the local host or via shared memory, data coming from your local NVMe drives? Threads of the same process? It's perfectly fine to take an appropriate level of trust at any and all of those cases and check what makes sense and trust what makes sense.

> Our long history of input security
> vulnerabilities comes from failing to treat data at such boundaries as "untrusted" .
>
> A good example is a recent Exim vulnerability. It checked "hostnames" when they came from DNS
> and config files, but trusted that hostnames it got from the OpenSSL library were validated.
> But they weren't, so a corrupted SNI field could hack the email server. This vuln worked with
> not only OpenSSL, but also GnuTLS (as Exim support many different SSL libraries).

All software has bugs. Some subset of bugs will be security issues. That's how it goes.

>
> The underlying problem was that it's not clear what the SNI field is supposed to contain.
> Should SSL libraries treat it as a blob and simply pass it on through? Or should they validate
> that it conforms to hostname rules? Should Unicode names be allowed? Or should only the DNS
> punycode names be allowed? It's not clearly specified, so the SSL libraries treated it as
> a blob and passed it on through. And Exim didn't validate it either, so bug.

Right, but the bug is not in trusting the SSL library. If you don't trust it to handle domain names properly, then you certainly don't trust with your data or keys! Your solution would be for everyone to implement their own crypto.

The reality is there was a bug in the spec or one or other project's reading of the spec, and that should be fixed accordingly.

"Trust nobody" will _never_ lead to zero bugs, I can assure you of that. Or even fewer bugs, for that matter.

>
> Thus, everybody that writes libraries or uses libraries needs to
> be concerned with validating UTF8 strings. Which is everybody.

They need to be concerned with it as far as being aware of how they handle strings and how their libraries handle strings. They don't need to validate the damn thing everywhere between calling library functions or getting strings back from a library.