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

141–150 of 499 posts

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

#141

Post by ebruchez »

sophacles wrote: post #119
criddell wrote: post #31

Earlier quoted context omitted.

Rust has been around for more than a decade now and is still very niche. Evidently, it isn't a good enough argument.

I don't understand your argument. In 1982 C was a decade old and still very niche. In 1992 C++ was a decade old and still very niche. In 2002 Python were both about a decade old and very niche. In 2005 Javascript was a decade old and still very niche (only used on some webpages, the web was usable without javascript for the most part). I think it's safe to say that all of them went on to enjoy quite a bit of success/…

> Some languages take off really fast and disappear just as fast (scala, clojure).

I don't know about Clojure but I don't think that Scala has "disappeared". The hype has subsided, certainly. I for one certainly hope that one of the best programming languages in existence doesn't disappear.

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

#142

Post by 2OEH8eoCRo0 »

Veserv wrote: post #72

This absolutely should have happened. "Mature, world-class security teams" are, as a general rule, objectively terrible at creating products that meet any meaningful, objective definition of security. Remember a few years ago when Apple, the world's most valuable company, released a version of macOS that not only let you log into root with no password(!), but actually helpfully created a root account with the passwor…

I mostly agree with you. I think it's going to take some rough years or decades before we re-architect all the things we have grown accustomed to.

https://dwheeler.com/essays/apple-goto-fail.html

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

#143

Post by dmz73 »

throwaway894345 wrote: post #113
lucb1e wrote: post #100

Earlier quoted context omitted.

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 j…

> 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 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?

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

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. They are good for scripting but people keep pumping out full applications and to be honest there is not much difference between giant Python application, giant maze of Excel VBA and giant Node.js heap of code. Of those, Excel VBA is most likely to work for 5 years and across 5 versions of the product yet it is also the most likely one to receive the most negative comments.

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

#144

Post by dagmx »

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…

AFAIK the issue with messaging isn't that the core app itself is written in an unsafe language , but that many components it interacts with are unsafe. E.g file format parsers using standard libraries to do it.

Granted those should also be rewritten in safer languages but often they're massive undertakings

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

#145

Post by criddell »

sophacles wrote: post #119
criddell wrote: post #31

Earlier quoted context omitted.

Rust has been around for more than a decade now and is still very niche. Evidently, it isn't a good enough argument.

I don't understand your argument. In 1982 C was a decade old and still very niche. In 1992 C++ was a decade old and still very niche. In 2002 Python were both about a decade old and very niche. In 2005 Javascript was a decade old and still very niche (only used on some webpages, the web was usable without javascript for the most part). I think it's safe to say that all of them went on to enjoy quite a bit of success/…

Languages take off broadly because there's something compelling about them (and it isn't necessarily a technical reason). One of most compelling reasons for adopting Rust is memory safety and that may not be terribly compelling.

The comment about it being over a decade old was mostly that it wasn't some new thing that people are unsure about where it can be used. It's mature and has been successful in some niches (and keep in mind that niches can be large).

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

#146

Post by senderista »

cjbprime wrote: post #122
slownews45 wrote: post #47

Earlier quoted context omitted.

What's the exploit path assuming no use of unsafe? I can see situations where I could probably get go to crash, but not sure how I get go to act badly. Note: Not a go / Haskell / C# expert so understanding is light here.

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.

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

#147

Post by rurban »

Now take a deep look at the POSIX C standard, Annex K. The bounds checked extensions. Using these would have definitely avoided the problem. memcpy_s requires the size of dest to be defined. The applause goes to the glibc maintainers, who still think they are above that.

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

#148

Post by criddell »

Arnavion wrote: post #129
criddell wrote: post #107

Earlier quoted context omitted.

Yeah, that could be. I was speaking about the wider development ecosystem. Rust is doing well in a few places and that's enough for it to survive and exist long term, or at least as long as Mozilla is relevant.

Mozilla's relevance hasn't mattered to Rust for a while.

So if Mozilla decided to step back from Rust it wouldn't be a major blow to Rust? I was under the impression that they were still important.

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

#149

Post by albntomat0 »

Since this comes up whenever there is a Project Zero article, here is a summary I made in summer 2020 on the distribution of the bugs they find/report:

Since this always comes up, here's an overview I made several weeks ago about where Project Zero focuses their efforts: All counts are rough numbers. Project zero posts:

Google: 24

Apple: 28

Microsoft: 36

I was curious, so I poked around the project zero bug tracker to try to find ground truth about their bug reporting: https://bugs.chromium.org/p/project-zero/issues/list For all issues, including closed:

product=Android returns 81 results

product=iOS returns 58

vendor=Apple returns 380

vendor=Google returns 145 (bugs in Samsung's Android kernel,etc. are tracked separately)

vendor=Linux return 54

To be fair, a huge number of things make this not an even comparison, including the underlying bug rate, different products and downstream Android vendors being tracked separately. Also, # bugs found != which ones they choose to write about.

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

#150

Post by jcranmer »

Veserv wrote: post #102
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…

How do you know that it was actually "extremely well-maintained"? Everybody thought OpenSSL was well-maintained since it was used as critical infrastructure by multi-billion dollar megacorporations, but it was actually maintained by two full-time employees and a few part-time volunteers with maybe a quick once-over before a commit if they were lucky. How about sudo, a blindly trusted extremely sensitive program [1],…

OpenSSL is a project which is treated as a "somebody else's problem" dependency by everybody, and the extent to which everybody cares about TLS support, it's basically an "open up a TLS socket and what do you mean it's more complicated than that" situation.

By contrast, NSS is maintained by Mozilla as part of Firefox, and, furthermore, its level of concern is deep into the "we don't want to enable certain cipher suites, and we have very exacting certificate validation policies that we are part of the effort in defining"--that is to say, NSS isn't a "somebody else's problem" dependency for Mozilla but a very "Mozilla's problem" dependency.

That said, this is CERT_VerifyCertificate, not mozilla::pkix, and since this is not used in Firefox's implementation of certificate validation, I would expect that this particular code in the library would be less well-maintained than other parts. But the whole library itself wouldn't be in the same camp as OpenSSL.

Post reply on HN