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

Serious Chrome zero-day

nakedsecurity.sophos.com

Post reply on HN
Print view View original

331–340 of 377 posts

Re: Serious Chrome zero-day

#331

Post by pjmlp »

sureaboutthis wrote: post #293
pjmlp wrote: post #290

Earlier quoted context omitted.

Let stop hand waving C security exploits caused by top developers, in spite of best practices. C only got outside UNIX in the mid-90's. Its ubiquity is an historical accident, by no means permanent, and thankfully some vendors are finally walking away from it, as proven by Microsoft security advisor for future Windows development best practices.

I'm pretty sure C was pretty well thought out and wasn't used by accident in any way. After almost 50 years of usage, I'm not sure we can say it's "by no means permanent" either.

C only got where it is thanks to Bell Labs not being allowed to sell it commercially, thus giving it away for a symbolic price to universities alongside source code.

Those university students went out to found startups that created the UNIX workstation market, like Sun.

Had Bell Labs been allowed to sell UNIX, C would have been a footnote in systems programming languages.

Instead gratis won and we got the JavaScript of systems programming.

EDIT: This is how well C was thought out.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

Re: Serious Chrome zero-day

#332

Post by steveklabnik »

zrm wrote: post #320
steveklabnik wrote: post #312

Earlier quoted context omitted.

It's sorta kinda both. The original implementation was in OCaml, and many of the early developers were big ML fans. But we also tried to keep syntax more C-like, overall. "It's a C-like OCaml" was how Rust was originally described to me, when I first heard of it.

Moreover, it doesn't matter what it is based on, it matters what it is trying to displace. I am not really even criticizing Rust. Let it be what it is. Python isn't C++ either. All I'm saying is that if the goal is to increase the number of people using memory safe languages, adding a borrow checker to C++ would serve that goal. (Also, I would really like to have a language with both a borrower checker and actual C++…

What do you prefer about templates?

(And yes, I fully support making C++ safer too; the GSL is as close as we're going to get, probably.)

Re: Serious Chrome zero-day

#333

Post by kllrnohj »

naikrovek wrote: post #316
kllrnohj wrote: post #136

Earlier quoted context omitted.

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.

Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe. When Go 1.8 released, it measured I don't believe that "it uses garbage collection" is a valid complaint against Go anymore, except in a real-time application, and I don't know of any real-time applications written in Go. I'm sure there are some, I just don't know of them.

A fast GC doesn't mean the code wouldn't have been faster without a GC.

GC's prevent you from doing a huge range of techniques to improve cache locality or reduce allocation/free churn.

A simple example would be games will do things like have just a big allocation for all a frame's temporary data, and they just bump-pointer allocate from it. Then when the frame is over, they reset back to zero. It is already The Perfect GC. Bump pointer allocation, zero pause time, and perfectly consistent memory usage. No matter how good Go's GC gets it will always be slower than that.

At the other end of things you have things like LLVM's PointerUnion, where alignment requirements are (abused) to cram a type id into the lower bits of the pointer itself. Type-safe variant in the size of a void*.

Re: Serious Chrome zero-day

#334

Post by [deleted] »

pjmlp wrote: post #255
kllrnohj wrote: post #136

Earlier quoted context omitted.

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.

Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. Android team also makes use of Go for their OpenGL/Vulkan debugger. Now, lack of generics is really a big pain point.

[deleted]

Re: Serious Chrome zero-day

#335

Post by kllrnohj »

pjmlp wrote: post #255
kllrnohj wrote: post #136

Earlier quoted context omitted.

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.

Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. Android team also makes use of Go for their OpenGL/Vulkan debugger. Now, lack of generics is really a big pain point.

> Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. > Android team also makes use of Go for their OpenGL/Vulkan debugger.

Neither of those examples disagree with what I said. Fuschia's usage is the perfect example of agreement - Go specializes in IO (server workloads) and is then being used to do IO. That's a great usage of Go's particular blend of capabilities.

The use of GO in GAPID would be more interesting if it had any meaningful constraints on it, but it doesn't. It's an offline debugger for something that ran on a device with a fraction of the speed.

RenderDoc would be the meatier Vulkan debugger, and it's C++.

Re: Serious Chrome zero-day

#336

Post by jrochkind1 »

jrochkind1 wrote: post #301
paulpauper wrote: post #37

This write-up is not helpful and says nothing about how one would be infected. it just says it can do code execution but no evidence anyone has been infected in any way or how would would be infected. The worst 0day possible is un-sandboxed code execution that is activated by merely visiting a webpage or clickinig.

This article has a bit more information, including suggestions by some that there are indeed exploits active in the wild. https://www.forbes.com/sites/daveywinder/2019/03/07/google-c... > Although information regarding CVE-2019-5786 remains scarce currently, Satnam Narang, a senior research engineer at Tenable, says it is a "Use-After-Free (UAF) vulnerability in FileReader, an application programming interface (API)…

ya don't gotta downvote me for reposting media coverage! I didn't write the article, if it's wrong, thanks for pointing that out. Just trying to see what there is about it to figure out what's going on, and help people reading skip a step, if you wanna tell us it's wrong, great!

Re: Serious Chrome zero-day

#337

Post by staticassertion »

blub wrote: post #326
staticassertion wrote: post #324

Earlier quoted context omitted.

You've missed my point entirely. This is not a plea to Chrome to rewrite their browser. My post has nothing to do with browsers. My claim is that Chrome is an interesting case study in the most hardened user-facing C++ codebase in the world being hacked because of memory unsafety. I also think that the strawman argument you've made is extremely weak for other reasons. This whole "insecure by design" thing is nonsense…

The culmination of your message was "Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex.", that's your point. It's probably correct, but also meaningless as I mentioned, because: a) most codebases aren't even nearly this complex b) no one will likely write such a codebase again So the entire "point" is just trivia. It can't be used to decide whether to program something in…

You're attempting to derive meaning from my post, which in your mind is that browsers should not use C++, where there is no such meaning.

That you have failed to do so is not my issue. Don't blame me for having an upvoted post.

Re: Serious Chrome zero-day

#338

Post by zrm »

steveklabnik wrote: post #332
zrm wrote: post #320

Earlier quoted context omitted.

Moreover, it doesn't matter what it is based on, it matters what it is trying to displace. I am not really even criticizing Rust. Let it be what it is. Python isn't C++ either. All I'm saying is that if the goal is to increase the number of people using memory safe languages, adding a borrow checker to C++ would serve that goal. (Also, I would really like to have a language with both a borrower checker and actual C++…

What do you prefer about templates? (And yes, I fully support making C++ safer too; the GSL is as close as we're going to get, probably.)

Template metaprogramming, variadic templates, integers as template parameters, etc. Even better would be constexpr user types as template parameters.

How about a language that embraces Turing-complete template metaprogramming as a thing to design in on purpose rather than something discovered after the fact to be more useful than anticipated. Have the utility without the ugly.

Re: Serious Chrome zero-day

#339

Post by aboodman »

nneonneo wrote: post #244
zetafunction wrote: post #234

Earlier quoted context omitted.

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.

So what happened here? There's an in-the-wild exploit that's bypassing sandboxing - so there must be at least two bugs, or the sandbox isn't tight enough (which, for Chrome, would surprise the hell out of me).

I used to work on Chrome. There have been periodic sandbox escapes, and chained exploits that escape to userland are routinely performed at pwn2own. This is just notable because there is a live exploit in the wild.

Re: Serious Chrome zero-day

#340

Post by pjmlp »

kllrnohj wrote: post #335
pjmlp wrote: post #255

Earlier quoted context omitted.

Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. Android team also makes use of Go for their OpenGL/Vulkan debugger. Now, lack of generics is really a big pain point.

> Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. > Android team also makes use of Go for their OpenGL/Vulkan debugger. Neither of those examples disagree with what I said. Fuschia's usage is the perfect example of agreement - Go specializes in IO (server workloads) and is then being used to do IO. That's a great usage of Go's particular blend of…

GAPID is an online debugger and a TCP/IP stack needs to be really fast.

As early C++ adopter I always find ironic how people give examples of C++'s code generation performance.

Back in the old days, tying to use C++ would generate exactly the same kind of performance bashing.

Post reply on HN