This shouldn't have happened: A vulnerability postmortem • Hacker News Board

Re: This shouldn't have happened: A vulnerability postmortem

#161

Post by nicoburns » Wed, Dec 01, 2021, 10:42 PM UTC

foobiekr wrote: post #43

slownews45 wrote: post #13

Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…

To provide some context for my answer, I’ve seen, first hand, plenty of insecure code written in python, JavaScript and ruby, and a metric ton - measured in low vulnerabilities/M LoC - of secure code written in C for code dating from the 80s to 2021. I personally don’t like the mental burden of dealing with C any more and I did it for 20+ years, but the real problem with vulnerabilities in code once the low hanging f…

C vulnerabilities do have a nasty habit of giving the attacker full code execution though, which doesn’t tend to be nearly so much of a problem in other languages (and would likely be even less so if they weren’t dependant on foundations written in C)

Re: This shouldn't have happened: A vulnerability postmortem

#162

Post by fleventynine » Wed, Dec 01, 2021, 10:44 PM UTC

lucb1e wrote: post #96

fleventynine wrote: post #85

Earlier quoted context omitted.

My language selection checklist: 1. Does the program need to be fast or complicated? If so, don't use a scripting language like Python, Bash, or Javascript. 2. Does the program handle untrusted input data? If so, don't use a memory-unsafe language like C or C++. 3. Does the program need to accomplish a task in a deterministic amount of time or with tight memory requirements? If so, don't use anything with a garbage c…

By 'complicated' in point 1, do you mean 'large'? Because a complex algorithm should be fine -- heck, it should be better in something like Python because it's relatively easy to write, so you have an easier time thinking about what you're doing, avoid making a mistake that would lead to an O(n³) runtime instead of the one you were going for, takes less development time, etc. I assume you meant 'large' because, as so…

By complicated I guess I mean "lots of types". Static typing makes up for its cost once I can't keep all the types in my head at the same time.

Point number 2 excludes pretty much all network-connected software, and that's intentional. I suppose single-player games are ok to write in C or C++.

Re: This shouldn't have happened: A vulnerability postmortem

#163

Post by IshKebab » Wed, Dec 01, 2021, 10:45 PM UTC

slownews45 wrote: post #39

jandrese wrote: post #17

Earlier quoted context omitted.

It's hard to fault a project written in 2003 for not using Go, Rust, Haskell, etc... It is also hard to convince people to do a ground up rewrite of code that is seemingly working fine.

What's somewhat interesting is memory safety is not a totally new concept. I wonder if memory safety had mattered more, whether other languages might have caught on a bit more, developed more etc. Rust is the new kid, but memory safety in a language is not a totally new concept. The iphone has gone down the memory unsafe path including for high sensitivity services like messaging (2007+). They have enough $ to re-wri…

The issue isn't really that there was a shortage of memory safe languages, it's that there was a shortage of memory safe languages that you can easily use from C/C++ programs. Nobody is going to ship a JVM with their project just so they can have the "fun" experience of using Java FFI to do crypto.

Realistically Rust is still the only memory safe language that you could use, so it's not especially surprising that nobody did it 18 years ago.

Re: This shouldn't have happened: A vulnerability postmortem

#164

Post by throwaway894345 » Wed, Dec 01, 2021, 10:47 PM UTC

dmz73 wrote: post #143

throwaway894345 wrote: post #113

Earlier quoted context omitted.

> everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/…

I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies. I don't think anyone can expect that all of these libraries are of good quality but how would one even try to verify that? And you have to verify it every time you update your project. Then there…

> I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies.

But it's also quite a lot easier to audit those dependencies, even automatically (incidentally, GitHub provides dependency scanning for free for many languages).

> Then there is the issue of licencing - how to verify that I am not using some library in violation of its licence and what happens if the licence changes down the road and I don't notice it because I am implicitly using 500 dependencies due to my 3 main libraries?

This is also an automated task. For example, https://github.com/google/go-licenses: "go-licenses analyzes the dependency tree of a Go package/binary. It can output a report on the libraries used and under what license they can be used. It can also collect all of the license documents, copyright notices and source code into a directory in order to comply with license terms on redistribution."

> Rust and Go have solved memory safety compared to C and C++ but have introduced dependency hell of yet unknown proportions.

I mean, it's been a decade and things seem to be going pretty well. Also, I don't think anyone who has actually used these languages seriously has ever characterized their dependency management as "dependency hell"; however, lots of people talk about the "dependency hell" of managing C and C++ dependencies.

> Python and other dynamically typed languages are in a league of their own in that on top of the dependency hell they also do not provide compiler checks that would allow user to see the problem before the exact conditions occur at runtime.

I won't argue with you there.

Re: This shouldn't have happened: A vulnerability postmortem

#165

Post by cjbprime » Wed, Dec 01, 2021, 10:48 PM UTC

senderista wrote: post #146

cjbprime wrote: post #122

Earlier quoted context omitted.

Go is sometimes considered memory unsafe because of the presence of data races. (This is a controversial semantics.)

Then Java is also unsafe by the same standard.

Why do you say that? Go's data races can produce memory corruption through bounds checking failures. I'm not aware of Java having that kind of memory corruption.

Re: This shouldn't have happened: A vulnerability postmortem

#166

Post by IshKebab » Wed, Dec 01, 2021, 10:48 PM UTC

Twisol wrote: post #93

fleventynine wrote: post #85

Earlier quoted context omitted.

My language selection checklist: 1. Does the program need to be fast or complicated? If so, don't use a scripting language like Python, Bash, or Javascript. 2. Does the program handle untrusted input data? If so, don't use a memory-unsafe language like C or C++. 3. Does the program need to accomplish a task in a deterministic amount of time or with tight memory requirements? If so, don't use anything with a garbage c…

I suspect Ada would make the cut, with the number of times it's been referenced in these contexts, but I haven't actually taken the time to learn Ada properly. It seems like a language before its time.

As I understand it it's only memory safe if you never free your allocations, which is better than C but not an especially high bar. Basically the same as GC'd languages but without actually running the GC.

It does have support for formal verification though unlike most languages.

Re: This shouldn't have happened: A vulnerability postmortem

#167

Post by jmull » Wed, Dec 01, 2021, 10:49 PM UTC

rfoo wrote: post #71

oxfeed65261 wrote: post #44

I don’t understand why the “lessons learned” doesn’t recommend always* passing the destination buffer size (using memcpy_s or your own wrapper). It has been a long time since I wrote C++, but when I did this would have been instantly rejected in code review. *…with, I suppose, potential exceptions in performance-critical code when you control and trust the input; I don’t believe that this code qualifies on either cou…

That's because these are "lessons learned" for how to catch these bugs, instead of "how to write more secure code". Because you can't.

You catch the bug by flagging the use of memcpy instead of something that takes the dest buffer size (like memcpy_s or whatever).

It seems to me linters have been flagging this kind of thing since forever. This code is using a wrapper, "PORT_memcpy", so a default ruleset isn't going to flag it.

So here I guess no one noticed PORT_memcpy == memcpy (or maybe noticed but didn't take the initiative to add a lint rule or deprecation entry or just created an issue to at least port existing code).

Re: This shouldn't have happened: A vulnerability postmortem

#168

Post by Gigachad » Wed, Dec 01, 2021, 10:52 PM UTC

jmull wrote: post #159

slownews45 wrote: post #13

Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…

Well, there's no time machine. Also, as far as I know, a full replacement for C doesn't exists yet.

Are you suggesting that this crypto library would not be possible or practical to be built with rust? What features of C enable this library which Rust does not?

There is no time machine to bring rust back to when this was created, but as far as I know, there is no reason it shouldn't be Rust if it was made today.

Re: This shouldn't have happened: A vulnerability postmortem

#169

Post by jcranmer » Wed, Dec 01, 2021, 10:53 PM UTC

dmz73 wrote: post #143

throwaway894345 wrote: post #113

Earlier quoted context omitted.

> everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/…

I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies. I don't think anyone can expect that all of these libraries are of good quality but how would one even try to verify that? And you have to verify it every time you update your project. Then there…

> In Rust every non-trivial library pulls in 10s or even 100s of dependencies.

You're exaggerating here. The most recent project I've been working on pulls in 6 dependencies. The anyhow crate has no dependencies, regex 3 (recursively!), clap and csv each 8. Only handlebars and palette pull in 10s of dependencies, and I can trim a fair few dependencies of palette by opting out of named color support (dropping the phf crate for perfect hash functions).

Re: This shouldn't have happened: A vulnerability postmortem

#170

Post by tialaramex » Wed, Dec 01, 2021, 10:54 PM UTC

Jyaif wrote: post #88

For at least a decade, and in the teams I was in, C"++" written like this would not pass code review precisely because it is incredibly brittle.

Uhuh. On cue a C++ programmer arrives to tell us that a true Scotsman wouldn't have introduced this bug... Where can we see "at least a decade" of this code you and your teams wrote?