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

191–200 of 499 posts

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

#191

Post by cutemonster »

IshKebab wrote: post #160
hwbehrens wrote: post #28

Earlier quoted context omitted.

> It is also hard to convince people to do a ground up rewrite of code that is seemingly working fine. I think this is an understatement, considering that it's a core cryptographic library. It appears to have gone through at least five audits (though none since 2010), and includes integration with hardware cryptographic accelerators. Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concer…

To be fair you don't need to rewrite the whole thing at once. And clearly the audits are not perfect, so I don't think it's insane to want to write it in a safer language. It may be too much work to be worth the time, but that's an entirely different matter.

> may be too much work

I wonder, how many work years could be too much

(What would you or sbd else guess)

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

#192

Post by syntheticcorp »

fleventynine wrote: post #172
throwaway894345 wrote: post #158

Earlier quoted context omitted.

If your "deterministic amount of time" can tolerate single-digit microsecond pauses, then Go's GC is just fine. If you're building hard real time systems then you probably want to steer clear of GCs. Also, "developer velocity" is an important criteria for a lot of shops, and in my opinion that rules out Rust, C, C++, and every dynamically typed language I've ever used (of course, this is all relative, but in my exper…

If it can really guarantee single-digit microsecond pauses in my realtime thread no matter what happens in other threads of my application, that is indeed a game changer. But I'll believe it when I see it with my own eyes. I've never even used a garbage collector that can guarantee single-digit millisecond pauses.

I believe Java’s ZGC has max pause times of a few milliseconds

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

#193

Post by jstimpfle »

pornel wrote: post #157
nickelpro wrote: post #95

Earlier quoted context omitted.

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.

The C ABI will outlive C, like the term "lingua franca" outlived the Franks. Pretty much every other language has support for the C ABI.

One complication is that it's not just about ABIs but at least as much about APIs. And C headers often make some use of the preprocessor. Usage of the preprocessor often even is part of the API, i.e. APIs expose preprocessor macros for the API consumer.

Zig has a built-in C compiler and supposedly you can just "include " from within a Zig source file. Rust has a tool called bindgen. There are other tools, I haven't tried either of them, but the fact alone that I'm somewhat familiar with the Windows (and some other platforms') headers makes me not look forward to the friction of interfacing with some tried and true software platforms and libraries from within a different language.

I know there has been some work going on at Windows on porting their APIs to a meta-language. Does anyone know how much progress was made on that front?

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

#194

Post by josephg »

hwbehrens wrote: post #28
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.

> It is also hard to convince people to do a ground up rewrite of code that is seemingly working fine. I think this is an understatement, considering that it's a core cryptographic library. It appears to have gone through at least five audits (though none since 2010), and includes integration with hardware cryptographic accelerators. Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concer…

> Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concern for your mental well-being, than by incredulity or skepticism.

In my experience, porting code more or less directly from one language to another is faster and easier than people assume. Its certainly way faster than I assumed. I hand ported chipmunk2d to javascript a few years ago. Its ~30k LOC and it took me about a month to get my JS port working correctly & cleaned up. I spend up throughout the process. By the end I had a bunch of little regexes and things which took care of most of the grunt work.

If we assume that rate (about 1kloc / person-day) then porting boringssl (at 356kloc[1]) to rust would take about one man-year (though maybe much less). This is probably well worth doing. If we removed one heartbleed-style bug from the source code on net as a result, it would be a massive boon.

(But it would probably be much more expensive than that because the new code would need to be re-audited.)

[1] https://www.openhub.net/p/boringssl/analyses/latest/language...

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

#195

Post by Eduard »

How realistic is it that this vulnerability can be exploited for $BAD_THINGS?

https://www.mozilla.org/en-US/security/advisories/mfsa2021-5... notes "This vulnerability does NOT impact Mozilla Firefox. However, email clients and PDF viewers that use NSS for signature verification, such as Thunderbird, LibreOffice, Evolution and Evince are believed to be impacted.".

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

#196

Post by staticassertion »

hwbehrens wrote: post #28
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.

> It is also hard to convince people to do a ground up rewrite of code that is seemingly working fine. I think this is an understatement, considering that it's a core cryptographic library. It appears to have gone through at least five audits (though none since 2010), and includes integration with hardware cryptographic accelerators. Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concer…

> Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concern for your mental well-being, than by incredulity or skepticism.

Why? I don't get it. Maintenance of NSS has to be seriously expensive.

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

#197

Post by staticassertion »

jmull wrote: post #190
Gigachad wrote: post #168

Earlier quoted context omitted.

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.

It's more of whether Rust fits into every workflow, project, team, build chain, executable environment, etc., that C does. Does rust run everywhere C runs? Does rust build everywhere C builds? Can rust fit into every workflow C does? Are there rust programmers with all the same domain expertise as for C programmers? (Not to mention, the question here isn't whether to write in rust or write in C. It's whether to leave…

It only matters if rust runs everywhere that Firefox runs, which it does.

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

#198

Post by smolder »

duped wrote: post #137
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…

> Or are C/C++ benefits just too high to ever give up? FFI is inherently memory-unsafe. You get to rewrite security critical things from scratch, or accept some potentially memory-unsafe surface area for your security critical things for the benefit that the implementation behind it is sound. This is true even for memory-safe languages like Rust. The way around this is through process isolation and serializing/deseri…

> FFI is inherently memory-unsafe

Maybe this specific problem needs attention. I wonder, is there a way we can make FFI safer while minimizing overhead? It'd be nice if an OS or userspace program could somehow verify or guarantee the soundness of function calls without doing it every time.

If we moved to a model where everything was compiled AOT or JIT locally, couldn't that local system determine soundness from the code, provided we use things like Rust or languages with automatic memory management?

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

#199

Post by ziddoap »

zelon88 wrote: post #156
ziddoap wrote: post #97

Earlier quoted context omitted.

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!".

I mean Google has this blog specifically to report on security vulnerabilities. That is literally like Volvo running a YT channel where they crash test cars from other companies and assess the damage to the dummy. "In the name of safety." I'm not the one stretching here.

Google's security team is doing exactly what everyone in the security industry considers a best practice: publicly disclosing vulnerabilities. However, since you're putting quotes around 'safety', I'll assume you must not be familiar with the fact that it is widely regarded as a best practice, and suggest you start with [0]. Out of curiosity, would you feel safer if the vulnerabilities Project Zero found were never found or fixed? Would you feel safer if they were found, but kept hidden so that other similar programs/libraries were unaware of the potential vulnerabilities?

The only people that seem to be upset about this are those on HN and Reddit who use every excuse to get angry at Google, context be damned.

Your analogy completely falls apart when you consider that Project Zero reports on their own products (by blog posts - Google: 24, Apple: 28, MS: 36). Make sure to consider the security footprint of the products offered between the three, as more footprint results in more bugs, and you'll see they (comparatively to the footprint) report on Google owned products quite frequently.

A more apt analogy would be if crash safety experts at Volvo spun off their own crash test centre, loosely under the umbrella of Volvo, and tested all (including many Volvo made) available cars for safety then publicly reported the results, data, and methodology. Then they offer suggestions for all car manufacturers, including Volvo, on how to make their cars safer for use.

Personally, I'd be just fine with that, too.

[0] https://www.schneier.com/essays/archives/2007/01/schneier_fu...

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

#200

Post by ummonk »

openasocket wrote: post #92
xiphias2 wrote: post #59

Earlier quoted context omitted.

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…

As far as I know, nothing in the C/C++ standard precludes fat pointers with bounds checking. Trying to access outside the bounds of an array is merely undefined behavior, so it would conform to the spec to simply throw an error in such situations.
Post reply on HN