Google looks at bypass in Chromium's ASLR security defense, throws hands up, won't patch garbage issue

In early November, a developer contributing to Google's open-source Chromium project reported a problem with Oilpan, the garbage collector for the browser's Blink rendering engine: it can be used to break a memory defense known as address space layout randomization (ASLR). About two weeks later, Google software security …

[Brewster's Angle Grinder]

"Coincidentally, the WontFix bug also turns out to be a WontPay bug: Google's Vulnerability Reward Program reviewed it and decided not to offer any reward."

That's just stingy, isn't it? Fair enough, going forward, once you've made it policy not to pay for ASLR escapes, but it's as mean as HP to refuse to cough up because you're retrospectively marking a mechanism as defunct.

[Blazde]

"Thanks for the report anyway."

Every time a bug bounty decision maker types these words God kills a hundred freelance vulnerability researchers.

[IGotOut]

To be fair, they only have a few hundred billion $'s kicking around.

[DS999]

So if you find a bug so bad

That they can't fix it, it doesn't warrant payment? I would think that's exactly the kind of bug you would want to pay for, to keep whoever found it from turning around and selling it to blackhats - an unfixable bug is their dream scenario!

[needmorehare]

That and what about other architectures?

Seriously, just because x86 processors are boned doesn’t mean they all are. I would try and fix this on principle, especially since WebAssembly is slowly turning Chrome into an all-in-one virtual machine for running apps...

Now who fancies a nice cup of Java?

[foxyshadis]

Re: So if you find a bug so bad

Anything unfixable isn't a bug, it's a feature.

[Anonymous Coward]

Re: Anything unfixable isn't a bug, it's a feature.

But hasn't ASLR always just been snake oil waiting to be exposed? And therefore whether it's a bug or a feature is a subjective decision.

[richardcox13]

Re: Anything unfixable isn't a bug, it's a feature.

I've never seen anyone claim ASLR is anything more than a road bump: making the attackers job harder, not impossible.

Which makes this decision by Google doubly poor. Making attackers harder is still making attacks harder.

[sev.monster]

Re: Anything unfixable isn't a bug, it's a feature.

Distract them by showing a little skin eh? I like the way you think.

Mine's a bit sticky.

[DS999]

Re: Anything unfixable isn't a bug, it's a feature.

There are techniques to make it more robust. For example, Apple switched how they do their OS level linking so it randomizes on every invocation, rather than once per boot. Not sure if that would be applicable to Chrome.

Not that it matters either way, if it is "doable" but it would require too much rework elsewhere in Chrome's codebase to make it work, it probably gets shitcanned on a cost/benefit basis.

[Anonymous Coward]

The long and the short of it..............

Long, long article in El Reg.

One line summary: "Spectre vulnerability is still around."

Is there anything I missed?

[Throatwarbler Mangrove]

Re: The long and the short of it..............

". . . which leads to the following unanticipated consequences for these reasons."

[brainwrong]

shoddy

"As [Oilpan] can’t distinguish integers from pointers, if an integer points to an allocated object, it just assumes that it’s a valid pointer and marks the object" as in use

How f*cking shoddy is that?

We're building the modern world on computers and that's the best we can do?

[Ken Hagan]

Re: shoddy

It's not the best we can do. Get a Real Programmer to write the code in a language that uses deterministic memory allocation. Problem solved.

[Tomato42]

Re: shoddy

but then you won't get a solution that uses NodeJS, WebAssembly, AI, blockchain or other bullshit du jour for the suits to pad their resume to jump ships before the projects burns down

that's "bad practice"!

[Ken Hagan]

Re: shoddy

That's an extra feature.

[Anonymous Coward]

Re: shoddy

You omitted AgileDevSecOps from your list.

[Warm Braw]

Re: shoddy

We're building the modern world on computers and that's the best we can do?

I was going to suggest we should worry more about Facebook than shoddy garbage collection, but I suppose "shoddy garbage collection" is as good a description of social media as any. As you were...

[eldakka]

Re: shoddy

How f*cking shoddy is that?

We're building the modern world on computers and that's the best we can do?

No matter what university lecturers say (at least mine did 25 years ago), CPU isn't cheap, memory isn't cheap, storeage isn't cheap.

How often do people complain about how much memory, or CPU, or disk (not so much disk in this case) browsers use up? It's always a tradeoff between memory usage and CPU cycles. Sure, they could have mechanisms to identify pointers vs integers, but that'd take more memory to do, a flag/mark isn't magically 0 bytes of data, it'd have to take up some amount of bits/bytes in the data structures, the millions of data structures thus taking up even more RAM in the already bloated RAM usage of browsers. Each flag might be tiny, but even a tiny number multiplied by millions becomes a big aggregate number.

Alternatively (RAM vs CPU tradeoff), they could have more smarts and try to work out dynamically (and transiently, remember, we aren't storing this knowledge in RAM beyond the GC cycle in this case, as opposed to the previous one) at GC time whether it's a pointer or an interger, taking, say, 20 cycles to do it, millions of times over on a GC. And like with the flag in memory, even a tiny number times millions of iterations in a GC will be a big number, being multiple seconds of processing on what people want to be an instantly-responsive system. Thus taking massively more CPU on what people complain are already CPU-hogging processes.

So they chose an RAM/CPU optimsed method, but if you don't do a CPU vs RAM tradeoff, the tradeoff comes from somehwere else. And as a consumer, would you rather your browser hangs continually for GC (excessive CPU), takes significantly more RAM (do you have enough RAM? How many tabs/windows can you now have open? How many other apps can you have running in the background?) or uses what was at the time thought to be a secure alternative method because of ASLR mitigating the issue?

From a developers perspective, this is definitely a damned if you do, damned if you don't scenario.

[Blazde]

Re: shoddy

It is a trade-off yes, but it's a performance vs correctness one because it treats arbitrary data of unknown type as if it might be pointer type, and imposes expectations on how pointer types are represented in memory which could easily be broken by other casually incorrect code.

Knowing how fragile computer code is, even as a coder who works hard to achieve high performance wherever possible, I'm struggling to think of scenarios I'm willing to exercise genuine choice and trade away correctness in production code precisely because of weird unexpected consequences like this vulnerability. It's apparent from the bug thread they did think about what they were doing and recognised the ugliness of it, but they didn't anticipate it breaking ASLR even though it does. That's the evidence you need that these consequences are hard to reason about and it's best staying away from the ugliness in the first place.

[Blazde]

Re: shoddy

"weird unexpected consequences like this vulnerability"

(Just to add) I mean, it's so broken it can't be fixed! Think about that for a moment. How often do you get bugs like this?

[Jon 37]

Re: shoddy

It's not the best we can do - precise garbage collectors exist and work.

However, there are performance vs accuracy/security/whatever tradeoffs, and people choose performance almost every time.

[iron]

Passwords can be cracked so there is no point using anything other than admin/1234.

Doors can be forced so there is no pont locking them.

That is what this shoddy decision amounts to. Yes ASLR can be defeated but that doesn't make it worthless, it will still stop the skiddies who don't know how.

[Scott Broukell]

@Brainwrong

Agreed. "We're building the modern world on computers and that's the best we can do?"

We are indeed rushing headlong into having all the digitized shiny shiny everything which we want right now!, this instant!, with not a jot of consideration or forethought for (Oh too costly) security and all the freakin holes, shonky gapping chasms! that we will leave behind in our wake within the whole kit and kaboodle! Cos we want it now! New and shiny shiny now-ness! Ooh! look at me and my wishy-washy ineffective insecurity ridden mess! Oh! but I mean it looks good tho.

[Claptrap314]

Repeat after me: SPECTRE-class issues cannot be fixed in software

Again, I spent a decade doing microprocessor validation at AMD & IBM centered around 2000--about the time that speculative loads were first being implemented.

The data leakage (which is NOT a bug--the architecture makes no promises about side channels) is core to the way that caches function in the presence of speculative reads & writes. If you wish to be immune to this class of attack, your options are as follows:

1) Follow the original recommendation of the US government, and turn off speculative memory accesses--and take a 10x hit to performance.

2) Ensure that all code running on a system has the same security context. That means renting, or at least time slicing in large chunks for the cloud. For PCs, that means completely upending the user model--and then taking a huge performance it.

3) Move to hardware which is significantly more complicated than current designs--that is, does not yet exist.

I have an idea of how to block SPECTRE-class bugs in hardware. I'm pretty sure it does not cost any time, but it adds significant size to the small caches, as well as a bunch of complexity. Given the bugs that I personally chased involving speculative memory access at the time, I'm not happy about the implications.

[Throatwarbler Mangrove]

Root Cause Analysis

The real problem is not ASLR or SPECTRE or whatever the vulnerability of the week may be. The real problem--stay with me here--is that people are assholes. I spend a quite egregious amount of my professional life worrying about vulnerabilities and exploitable weaknesses, which would be unnecessary if people weren't assholes. The fine and brilliant engineers at AMD and Intel have built amazing technology, and many of those accomplishments now have to be undone and reconsidered not because they weren't excellent ways of addressing difficult performance problems but because people are assholes who will look for any way to subvert the security of a system so that they can perform nefarious acts. If people weren't assholes, engineers could just focus on building technology that works optimally without needing to work out in painstaking detail every conceivable way in which someone now or in the future could be an asshole, and technology could operate much more smoothly and efficiently.

To the assholes of the world, I would beseech you to stop, but I won't, because you won't . . . because you're assholes.

[Throatwarbler Mangrove]

Re: Root Cause Analysis

Oh look, a downvote with no rebuttal. Now, what adjective could possibly describe you? What could it be?

[Robert Carnegie]

Re: Root Cause Analysis

Well, you don't have a solution to the asshole problem.

We wouldn't need any security at all, computer or household, if people weren't anti-social-holic.

"Prohibition" of alcohol would be O.K. if people weren't assholes. Was tried, didn't go good.

[Throatwarbler Mangrove]

Re: Root Cause Analysis

"Prohibition" of alcohol would be O.K.

We will have to respectfully disagree on this point. ;)

[Robert Carnegie]

Re: Root Cause Analysis

If people weren't assholes, would there be a need for alcohol after dealing with them?

[Kevin McMurtrie]

Re: Root Cause Analysis

I would top that list with people who come up with excessively complex and inaccurate designs then refuse to take responsibility or admit any fault for them. That's how systems get exploited.

[heyrick]

Re: Root Cause Analysis

Neither upvoted nor downvoted, but it seems to me that the state that you call "asshole" is just a modern equivalent of long-time practice. Whether it be nations abusing security to spy on each other, or proper dodgy blokes fleecing unsuspecting people, they both have long histories predating electricity, never mind processor cache technology. It's unfortunate that problems in processor design [*] have made this situation possible, but it is what it is.

* - you can have security or you can have speed, pick one.

[Claptrap314]

Re: Root Cause Analysis

First, it's not "people" being "assholes"--it only takes one. You are saying that the problem is human nature. So? So what?

Second, we speculative speculative loads & stores first came out, very senior people attempted--and failed--to realize SPECTRE-class attacks. Side-channel attacks had been well known for decades (look up TEMPEST), so this was not babe in the woods situation. It is telling, however, that just inside the cover of the manual for the parts, there is a page-sized notice that the processor is NOT rated for use with any US government classified material. Which was no big deal before people started living their entire lives online.

[Anonymous Coward]

Why not Firefox?

The article says that Firefox appears to have been spared.

Why? What are they doing differently?

[Blazde]

Re: Why not Firefox?

They're not using a tracing based garbage collector. Chrome & Firebox both use reference counting in the main. However Chromium also implements a second tracing garbage collector inside the rendering engine, apparently to make collection of objects that form cycles more efficient, and that's where the issue lies. Detecting cycles in a browser engine gets especially challenging because they can form across language boundaries.

Firefox's equivalent solution is a 'complex cycle collector' (casual use of either browser shows neither solution works perfectly by the way). Mozilla's new rendering engine Servo was supposedly taking advantage of Rust language features to do object lifetime analysis at compile time and make the cycles easier to track, or less likely to form in the first place(?), and the whole process less bug prone, but I don't know the status of that effort.

[foxyshadis]

Re: Why not Firefox?

Pieces of Servo have been incorporated into the main codebase, but Mozilla has been hamstrung by a funds crunch for years. The project is now unofficially dead, since the whole team was laid off last year, though Linux Foundation has thrown a few people at it since. Unfortunately, due to the Big Ball of Pain that is the whole SpiderMonkey JS engine (and every other JS engine), the Rust-based HolyJIT engine that was meant to replace it never made it to production.