Live data from Hacker News

Actively exploited sandbox RCE in all Chromium versions

nvd.nist.gov

421–430 of 527 posts

Re: Actively exploited sandbox RCE in all Chromium versions

#421

Earlier quoted context omitted.

I'm willing to believe that stock chrome has a better record than stock Firefox, but > and on top of it you’re recommending an extension as a security measure ... Yes? Why can a browser extension not be a security measure/improvement?

Because extensions especially MV2 ones only increase attack surface.

No, they don't only increase attack surface. In particular, uBo reduces attack surface a lot more than it increases it.

Re: Actively exploited sandbox RCE in all Chromium versions

#422
> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)

What's the difference between "executing arbitrary code inside the sandbox via a crafted HTML page" and running whatever is in the tag?

Re: Actively exploited sandbox RCE in all Chromium versions

#423
post #111

Earlier quoted context omitted.

we really do not want to engineer a system in which using bugs to make money is considered economically legitimate activity. It is still crime. The main reason to report bugs and get the bounties for doing so is still because it makes the world safer and healthier. The money is there to make is to incentivize the work of finding and reporting them -- not to outbid the bad actors.

Companies sometimes reward their employees with important bug fixes. When I worked on a big dev team, we'd even decide what were the most important fixes and give people a special 5k bonus or something. But they weren't security issues necessarily. I never thought about it, fixing a huge performance issue is big. A security fix that gets caught early makes no noise so you just don't know how important it would have b…

> Companies sometimes reward their employees with important bug fixes.

Potentially creates a misaligned incentive to intentionally hide bugs in the code you write so that later you can fix it and get the bounty.

Re: Actively exploited sandbox RCE in all Chromium versions

#424

Earlier quoted context omitted.

Monocultures are great!

There’s a reason I use Firefox (Gecko). Also, Ladybird—another completely different web engine—is really promising. I spent five hours building it from source, having it take about 8 gigabytes of space, and it perfectly renders my own webpages and blogs. I have a feeling someone’s going to make an open source browser using Ladybird’s engine before Ladybird has official binaries.

Is Firefox actually safer than Chromium-based browsers though?

I know this is old: https://madaidans-insecurities.github.io/firefox-chromium.ht...

but has the situation changed substantially in favor of Firefox?

Re: Actively exploited sandbox RCE in all Chromium versions

#425

Earlier quoted context omitted.

Your conflating capitalism with markets. Markets are fundamental things and exist regardless of any kind of moral "should". Otherwise we wouldn't have people buying hard drugs or trafficing women.

If we abandon the moral "should", then the right move is to shake down Google along the lines I already said. Google should, as a rational actor, pay out better for legitimate vulnerabilities that pose actual risk to them to avoid such a situation. My beef here is that morality and ethics are only assigned to the researchers.

So what does that have to do with capitalism?

Re: Actively exploited sandbox RCE in all Chromium versions

#426
post #422

> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) What's the difference between "executing arbitrary code inside the sandbox via a crafted HTML page" and running whatever is in the tag?

In the script tag you only have access to JS. This allows you to escape JS and have native code execution. It is still sandboxed by os-level primitives, but it is an escalation/first step in successful exploitation.

Re: Actively exploited sandbox RCE in all Chromium versions

#427

Sounds wild. (Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)

Which wouldn't have actually done anything about this bug fwiw since this wasn't a memory safety issue with any C/C++ code itself

Re: Actively exploited sandbox RCE in all Chromium versions

#428
What do CVEs like this one mean for the likes of fly.io and cloudflare who use V8 for sandboxing 3p workloads? I guess they have some degree of KYC and some hardening outside the sandbox, but chaining this with a container escape running under a free tier account could pwn the host.

Re: Actively exploited sandbox RCE in all Chromium versions

#429

Earlier quoted context omitted.

We have them, and have had them for a long time. Nobody wants to use them.

> Nobody wants to use them. Wikipedia is basically the most popular application of all time and it doesn't rely on javascript. People just generally don't give a shit about where their money goes.

I don’t think the parent comment was talking about html, css, and https. Rather something like Gemini.

Re: Actively exploited sandbox RCE in all Chromium versions

#430
post #310

Earlier quoted context omitted.

> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page. I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalcula…

OP here. The steel-man argument for React is not that it is faster at rendering. It cannot be , because it ultimately relies on the same DOM that everyone else does to do the job, and it has to set up a massive JS data structure to do what it does, which uses a lot of memory and has big GC costs. Arguments that assert that the React virtual DOM are faster than the native/shadow DOM are simply wrong [1]. Even the Reac…

>But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.

The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?

Post reply on HN