Robert David Graham (robert_david_graham.delete@this.yahoo.com) on July 13, 2020 8:36 pm wrote:
> anon2 (anon.delete@this.anon.com) on July 13, 2020 5:07 pm wrote:
> >
> > 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.
>
> Well, as I said, the history of input validation vulnerabilities is not a history of failure to
> understand input validation, but a failure of understanding what's "untrusted". All the Internet
> worms, especially RPC worms in Linux and Windows, comes from much the same discussion: programmers
> made assumptions about the other side being trustworthy that later proved not to be true.

So what exact parts of a complex library that you don't trust would you use, and what would you validate?

https://www.openssl.org/news/vulnerabilities.html

I understand the need for validation, I understand the concept of trusting different compoenents, and defense in depth. And the blanket statement that you don't trust libraries or that you have to validate them again is simply wrong.

I definitely don't argue against doing assertions and debug checks on inputs and outputs to check your invariants and catch misuses of interfaces and things. But there's situations where it doesn't make sense to blanket not trust. Not just for libraries but even for IPC, disk, network.

>
> DMA is a great demonstration of this principle. By definition, the CPU isn't involved.
> And yet, we still have numerous DMA vulnerabilities, which is why Intel's next USB
> 4 spec demands that VT-d be a part of it, to address DMA vulnerabilities.

What is it demonstrating?

>
>
> > 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.
>
> But they did handle hostnames exactly as they promised, which is to say, they promised
> the contents of the SNI field. The problem was the users of the SSL libraries who
> made assumptions that the contents of this field would be a valid hostname.

Buffer overflow caused by mis-using the API.

You can point to any particular example of a bug post facto and say if only they should have been checking for such things. There is no logical pathway from there to a conclusion that therefore nobody should trust anythingand should always check everything, or even that they should have employed a methodology that would have been checking for such things.

The end result is more people writing more duplicate code that they are not expert in. And quite likely more bugs.

If this was a particularly difficult API to use, or the spec was very difficult to understand, I could easily see it being good practice to have added more checking to make sure they got things right and the caller did what was expected.

But from there to not trusting openssl at all? No. Again you didn't address my question, if you don't trust it, you certainly aren't going to give it your keys or private data, right? So roll your own crypto?

>
> Sure, you can blame the programmers for misinterpretting the spec,

That or just forgetting about some case where it might write more than they thought, yes. I do.

> but then, that's the issue with most specs,

I'm not sure you can quanitify that, or even point to the spec as the problem in this particular case, do you know it was poorly written? How many other apps which link SSL libraries have similar vulnerability from not reading that part of the spec?

> which leads back to my point, you'll have to end up validating input whenever the spec is incomplete.

That was not your point though, your point was something very different.

>
>
> > "Trust nobody" will _never_ lead to zero bugs, I can assure
> > you of that. Or even fewer bugs, for that matter.
>
> I'm not saying "trust nobody", which is why my post said "good advice". My point is simply that you have
> to distrust far more than you think. Validating UTF8 needs to happen far more than people realize.

It doesn't if you aren't using it as UTF8 though, which I think is Linus's point. You don't need to worry about trust or no trust at all because you don't care that it's valid or not while you're piping it through your data structures and transport protocols and things. Because it's also just a string of bytes, so you use that (and obviously check that is correct and doesn't overflow things when you copy it etc).