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

351–360 of 377 posts

Re: Serious Chrome zero-day

#351

Post by naikrovek »

IX-103 wrote: post #191
naikrovek wrote: post #126

Earlier quoted context omitted.

That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…

Sorry. Until Go gets its head out of its ass and gets proper generics Go will still be painful to use and slow. Not to mention with all the extra code complexity from writing everything with interface{}{} and reflection there are bound to be plenty of exploitable vulnerabilities. I honestly think it is worse than pre-generic Java because switching over the type of the variable is encouraged. Most sane type-checked la…

Generics are slower, that's the trade-off. Developer time vs. execution time.

Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.

Re: Serious Chrome zero-day

#352

Post by ErikCorry »

duneroadrunner wrote: post #348
ErikCorry wrote: post #346

Earlier quoted context omitted.

Not so sure. I haven't worked on this code for a while and have no non-public knowledge of the bug, but ArrayBufferBuilder does not inherit from any of the GCed base classes, and has the USING_FAST_MALLOC macro which is used for non-GC classes. https://chromium.googlesource.com/chromium/src/+/refs/heads/... The ArrayBuffer itself also uses reference counters rather than the GC base classes from Oilpan. https://chromi…

ArrayBufferBuilder isn't, but DOMArrayBuffer seems to be a GC managed type [1], right? And, before the patch, the DOMArrayBuffer held a "refcounting pointer" potentially targeting raw_data_'s reference counted ArrayBuffer, right? I don't see any immediately apparent use-after-free with this, so I assume raw_data_'s ArrayBuffer is being messed with elsewhere? As someone who worked on the code, do you have an idea/hunc…

Yes, DOMArrayBuffer inherits via ScriptWrappable from GarbageCollectedFinalized so it's on the GCed heap. I don't understand the UAF yet, I'm hoping someone will write a blog post on it later :-).

Re: Serious Chrome zero-day

#353

Post by pjmlp »

littlestymaar wrote: post #268
kllrnohj wrote: post #156

Earlier quoted context omitted.

> Java deserialization RCEs, while pernicious, are nowhere near as common as use-after-free and related bugs in C++ code. Can you justify that? Actual exploits from Java deserialization RCEs are well known & published, but by contrast searching the CVE database reveals a rather small number for C++ or CPP. Use-after-free gets a large list, but the majority seem to be in C code not C++ code.

UAF are the most common, and the most commonly exploited kind of security bugs in Microsoft products for the last decade [1]. And Microsoft products are way more C++ than C. [1] https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Which is why their security team is now pushing for C#, Rust and constrained C++ for new developments.

https://github.com/Microsoft/MSRC-Security-Research/tree/mas...

Re: Serious Chrome zero-day

#354

Post by pjmlp »

kllrnohj wrote: post #333
naikrovek wrote: post #316

Earlier quoted context omitted.

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

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

This is only true in languages which don't provide other means of memory allocation.

D, Modula-3, Mesa/Cedar, Oberon variants, Eiffel, .NET all provide features for such techniques.

Re: Serious Chrome zero-day

#355

Post by Ygg2 »

htfy96 wrote: post #176
bauerd wrote: post #87

Earlier quoted context omitted.

Use-after-free is ruled out by e.g. Rust's type system

Nope. It's only true when all your code use safe subset/built upon a perfectly correct unsafe base (which is inevitable in a project like Chromium) with correct usage. Otherwise a single misused external call with unsanitized value can ruin all of your security guarantee.

Not really. It's been proved that if your unsafe foundations are correct and don't break the rules (i.e. their precondition is correct), then anything safe built on top of that is also correct.

Sure you could rely on a C/C++ library that causes problems, but then again you can either:

A) fix that library

B) replace that part with Rust or even stricter language.

Re: Serious Chrome zero-day

#356

Post by gpderetta »

mike_hearn wrote: post #273
pcwalton wrote: post #199

Earlier quoted context omitted.

> Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Not necessarily. If the language provides a way to ensure memory management of DOM objects is correct across language boundaries, it would provide an effective defense against these issues. Safe memory management across a combination of managed and unmanaged code is a tough problem, and Rust (and perhaps Swift…

GraalVM also has a way to do this - the 'unmanaged' C/C++ is upgraded to be automatically memory managed on the fly by compiling pointers into (gc'd reference, integer field offset) and then redirecting allocations to GCd heaps. There's more to it than that of course, but it means traditional C/C++ using new/delete and GCd languages can interop and coexist in the same process and heaps, and memory management errors i…

If you want GC there are available GCs for C++.

Re: Serious Chrome zero-day

#357

Post by gpderetta »

platinumrad wrote: post #219
pcwalton wrote: post #210

Earlier quoted context omitted.

Interface in Go can actually violate memory safety because of object slicing when racing on a variable concurrently from multiple goroutines (unless things have changed lately). It's two words (data and vtable) and so there is a tiny window in which one goroutine could change the data pointer while another goroutine is reading the two words, and so have a type mismatch that could probably cause arbitrary code executi…

Unless I'm misunderstanding you, you're just talking about a garden variety data race on any interface value in shared memory right? If that's the case, I don't see what it has to do with interface{} in particular (or interfaces at all) as any multiword value in shared memory is susceptible to this, which is the unfortunate price you pay when your language supports shared memory concurrency but doesn't have any allow…

Some languages guarantee memory safety even in the presence of data races (for example Java), while others simply prevent data races in their safe subset (rust). Go is normally memory safe but data races on some critical objects can compromise it.

Re: Serious Chrome zero-day

#358

Post by fredmorcos »

naikrovek wrote: post #351
IX-103 wrote: post #191

Earlier quoted context omitted.

Sorry. Until Go gets its head out of its ass and gets proper generics Go will still be painful to use and slow. Not to mention with all the extra code complexity from writing everything with interface{}{} and reflection there are bound to be plenty of exploitable vulnerabilities. I honestly think it is worse than pre-generic Java because switching over the type of the variable is encouraged. Most sane type-checked la…

Generics are slower, that's the trade-off. Developer time vs. execution time. Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.

> Generics are slower, that's the trade-off. Developer time vs. execution time.

You have no idea what you're talking about.

> Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.

No it's not disrespectful, it is entirely true. Do consider the origins of Go, where it all started as an experiment in combining bad decisions into a single programming language to see what would happen. What those very people didn't realize upon releasing it to the world is the sheer amount of people who fell for it, it was supposed to be a joke, with a stupid looking mascot and all... Now they have to take it seriously - and Google has to choose between keeping it alive or getting a forever bad rep for killing it - because too many companies rely on it, and they are forced to retrofit useful features on top of the giant pile of garbage they've created.

Re: Serious Chrome zero-day

#359

Post by johntyree »

fredmorcos wrote: post #358
naikrovek wrote: post #351

Earlier quoted context omitted.

Generics are slower, that's the trade-off. Developer time vs. execution time. Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.

> Generics are slower, that's the trade-off. Developer time vs. execution time. You have no idea what you're talking about. > Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that. No it's not disrespectful, it is entirely true. Do consider the origins of Go, where it all started as an exp…

I don't know about the origin story, although frankly I hope it's true.

Personally, I think Go is terrible. However, I can't imagine Google is even remotely considering scrapping Go. It is massively popular. It is used all over the place both externally and internally. It's a huge branding asset, community outreach tool, recruiting tool and provides leverage in the form of first party libraries over the direction that software development as a whole is going.

Re: Serious Chrome zero-day

#360

Post by GenericsMotors »

naikrovek wrote: post #351
IX-103 wrote: post #191

Earlier quoted context omitted.

Sorry. Until Go gets its head out of its ass and gets proper generics Go will still be painful to use and slow. Not to mention with all the extra code complexity from writing everything with interface{}{} and reflection there are bound to be plenty of exploitable vulnerabilities. I honestly think it is worse than pre-generic Java because switching over the type of the variable is encouraged. Most sane type-checked la…

Generics are slower, that's the trade-off. Developer time vs. execution time. Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.

You lost all credibility when you wrote that first sentence.

But you carry on using empty interface with runtime type assertions and reflection if you think that's faster.

Post reply on HN