Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This shouldn't have happened: A vulnerability postmortem

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

91–100 of 499 posts

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

#91

Post by throwaway894345 »

rfoo wrote: post #66
throwaway894345 wrote: post #61

Earlier quoted context omitted.

Also, far, far easier to build than all of these C programs with their own bespoke build systems and implicit dependency management. The more of the software stack that can be built by mere mortals, the better.

> far, far easier to build than all of these C programs One of my friends who work on AIX machines without direct Internet access does not share the same view, though.

Why is indirect Internet access less of a problem for C than Rust/Go/etc? Seems like for modern systems, you just run a pre-populated caching proxy on your target and `cargo install` like you normally would. In C, you're manually checking versions and putting files in the right spot on disk for every stage of the build (this can be alleviated a bit if you can find pre-built binaries and so on, but even in the best case it's far behind "advanced" systems).

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

#92

Post by openasocket »

xiphias2 wrote: post #59
slownews45 wrote: post #39

Earlier quoted context omitted.

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…

Memory safe language that can compete with C/C++ in performance and resource usage is a new concept. AFAIK ADA guarantees memory safety only if you statically allocate memory, and other languages have GC overhead. Rust is really something new.

There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert if your language had a native array type. Pascal and its descendants have been doing that for decades.

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

#93

Post by Twisol »

fleventynine wrote: post #85
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…

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.

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

#94

Post by axelf4 »

zionic wrote: post #51
kwertyoowiyop wrote: post #27

Earlier quoted context omitted.

C/C++ will be around for at least a hundred years. Our descendants will be writing C/C++ code on Mars.

I don’t know about that, I can see Rust having a certain aesthetic appeal to martians.

Nah, they definitely use Zig.

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

#95

Post by nickelpro »

zionic wrote: post #22
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…

C/C++ don’t really have “benefits”, they have inertia. In a hypothetical world where both came into being at the same time as modern languages no one would use them. Sadly, I’m to the point that I think a lot of people are going to have to die off before C/C++ are fully replaced if ever. It’s just too ingrained in the current status quo, and we all have to suffer for it.

On any given platform, C tends to have the only lingua franka ABI. For that reason it will be around until the sun burns out.

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

#96

Post by lucb1e »

fleventynine wrote: post #85
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…

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 software like Wordpress beautifully demonstrates, you can have the simplest program (from a user's perspective) in the fastest language but by using a billion function calls for the default page in a default installation, you can make anything slow. Using a slow language for large software, if that's what you meant to avoid then I agree.

And as another note, point number 2 basically excludes all meaningful software. Not that I necessarily disagree, but it's a bit on the heavy-handed side.

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

#97

Post by ziddoap »

zelon88 wrote: post #87
ziddoap wrote: post #60

Earlier quoted context omitted.

> This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage. Yep, definitely sounds like Project Zero is trashing Mozilla in this blog post.

They checked for process failure didn't they? Nobody will remember that line. Everyone is going to remember the title.

The title doesn't name a vendor... So you'd have to read the article to see the vendor, where you would presumably read the line where they say they have a "world-class security team" among other praise.

I don't like Google one bit, but my god these are some extraordinary hoops people are jumping through just so they can yell "Google's evil!".

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

#98

Post by bluejekyll »

rfoo wrote: post #65
lucb1e wrote: post #8

A title that actually describes the post, mostly paraphrasing the first paragraph: Reasons why this buffer overflow wasn't caught earlier despite doing all the right things And then to give those reasons: - "each component is fuzzed independently" ... "This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could ne…

What's special here is the bug is a memory corruption, and memory corruption bugs in such libraries are usually instantly security bugs. Otherwise, the same story could be told as a generic software testing joke: "unit-tests are short-sighted and coverage lies", i.e. an "extremely well-maintained codebase, with extensive unittest, >98% test coverage and constantly scanned by all-static-analyzers-you-may-come-up" can…

Ah, brings to mind one of my favorite Dijsktra quotes, "Program testing can be used to show the presence of bugs, but never to show their absence!"

I've never understood that to mean that he wasn't in favor of automated testing, only that it's got its limits. In this case, they now know a test case that was missing.

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

#99

Post by jrockway »

jtchang wrote: post #75
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…

I'd like to write go or rust but embedded constraints are tough. I tried and the binaries are just too big!

How big is too big? I haven't run into any size issues writing very unoptimized Go targeting STM32F4 and RP2040 microcontrollers, but they do have a ton of flash. And for that, you use tinygo and not regular go, which is technically a slightly different language. (For some perspective, I wanted to make some aspect of the display better, and the strconv was the easiest way to do it. That is like 6k of flash! An unabashed luxury. But still totally fine, I have megabytes of flash. I also have the time zone database in there, for time.Format(time.RFC3339). Again, nobody does that shit on microcontrollers, except for me. And I'm loving it!)

Full disclosure, Python also runs fine on these microcontrollers, but I have pretty easily run out of RAM on every complicated Python project I've done targeting a microcontroller. It's nice to see if some sensor works or whatever, but for production, Go is a nice sweet spot.

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

#100

Post by lucb1e »

throwaway894345 wrote: post #61
_wldu wrote: post #46

The sooner we can rewrite our programs in Go and Rust, the more secure we will be. Our shells, coreutils, mail readers and web browsers have to be written in safer languages.

Also, far, far easier to build than all of these C programs with their own bespoke build systems and implicit dependency management. The more of the software stack that can be built by mere mortals, the better.

Honestly I don't like the build process of most go/rust/javascript software any better than C++.

It's harder to find the dependencies for building the latter, but the former has its own version of dependency hell. I have real trouble building both types of projects, though admittedly (especially when the building instructions don't work when followed to the letter) C++ a bit more than the strategy of "everything is just pulled from github, you only have to make sure you've got gigabytes of free space in ~/.cache/, a build environment that was released in the past four to nine days, and have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system".

On a rare occasion, I will find a nice and small program using only standard libraries that compiles simply with `cc my.c && ./a.out` or runs simply with `python3 my.py`, demonstrating it doesn't depend on the language to have an easy time building it, but in both categories it's the exception for some reason. I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something.

Post reply on HN