News for hackers. Stuff that matters.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by masklinn on Wednesday January 24, 2024 @11:35AM (#39119335)
The Fedora mailing list message actually lists 3 different CVE: https://lists.fedoraproject.org/archives/list/package-announ...

- a type confusion

- an out of bounds read

- an out of bounds write

All three are in V8, so node might also be affected?

Re:Out of bounds memory access in V8 in Google Chrome prior ... by mccr8 on Wednesday January 24, 2024 @11:38AM (#39119375)
If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by NotSammyHagar on Wednesday January 24, 2024 @12:00PM (#39119656)
What does trusted really mean? If you use node (or other JS packaging systems), you are running code that someone else wrote, that almost certainly you didn’t review as it’s huge, changing, etc. How about companies that use v8 to run JavaScript extensions to their app that their customers wrote. This is many apps. Are you saying they are all vulnerable?

The answer is they are all vulnerable, just because of problems like this. Any user code (js in this case) is untrustworthy, and everything has js extensions. What’s the safe way to run user JS? Running v8 in its own somehow separately limited process maybe is what I think people do.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by Dalewyn on Wednesday January 24, 2024 @12:14PM (#39119828)
>What does trusted really mean?

I agree; "trusting" third-party/remote code or not frankly went out the window with the bathwater including baby when we moved on to Web "JavaShit" 2.0, or was it 3.0.

Feels like we're in a worse security hellhole than we ever were with Flash or ActiveX back in the day, frankly.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by refulgentis on Wednesday January 24, 2024 @12:21PM (#39119902)
For context, assuming by JavaShit Web 3.0 you meant JavaScript:

Flash and ActiveX were proprietary technologies that often required users to install plugins or additional software on their devices. These plugins operated with high levels of access to the system, which made them a significant security risk. They were notorious for being frequently exploited by attackers as a way to run malicious code on users' machines.

In contrast, JavaScript is a core part of the web and is executed within the browser in a sandboxed environment. This means that JavaScript operates with limited access to the system's resources, reducing the risk of system-level security breaches.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by Amigo5862 on Wednesday January 24, 2024 @01:20PM (#39120739)
> In contrast, JavaScript is a core part of the web and is executed within the browser in a sandboxed environment. This means that JavaScript operates with limited access to the system's resources, reducing the risk of system-level security breaches.

Flash (and probably ActiveX) were also executed in a "sandboxed environment", including "limited access to the system's resources". All 3 have (or well, had, in the case of Flash and ActiveX) regular vulnerabilities - including JavaScript. JavaScript is not any better than Flash or ActiveX and I really don't understand why people pretend it is.

BTW, Flash was definitely a core part of the web in its heyday, too.

ETA: Oh, and Java was also executed in a sandbox (and a virtual machine!) and had plenty of vulnerabilities back when applets were a thing.

At least with Flash, ActiveX, and Java you could choose not to install them and most sites would continue working. For JavaScript you have to install (and trust) some third party extension to block it and then no sites work...

Re:Out of bounds memory access in V8 in Google Chrome prior ... by cesarb on Wednesday January 24, 2024 @02:05PM (#39121350)
> Flash (and probably ActiveX) were also executed in a "sandboxed environment", including "limited access to the system's resources".

IIRC, the main issue with ActiveX was that it did not execute in a sandboxed environment, unlike Flash and Java. With ActiveX, all you had was a cryptographic signature saying it came from a trusted publisher; past that, the full Win32 API was available, with complete access to the operating system.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by Amigo5862 on Wednesday January 24, 2024 @02:32PM (#39121634)
That wouldn't particularly surprise me. I never used ActiveX, so I can't really speak to that one. But then, there also weren't many (public) websites that I ever ran into that wanted to use it.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by technion on Wednesday January 24, 2024 @05:08PM (#39123236)
As someone who still has to support users of several ActiveX apps, turning off the "block unsigned ActiveX" setting goes with the territory of using it.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by josephg on Wednesday January 24, 2024 @05:39PM (#39123559)
> But then, there also weren't many (public) websites that I ever ran into that wanted to use it.

As I understand it there were weird pockets where organisations went hard in to activeX. IIRC it was used heavily by the South Korean government, and a lot of internal corporate intranet projects for all sorts of things.

That obviously caused massive problems a few years later when Microsoft tried to discontinue activex and make IE/Edge a normal web browser.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by acdha on Wednesday January 24, 2024 @02:27PM (#39121594)
Flash was never a core part of the web. That was the problem: it was loosely bolted onto browsers but the company behind it didn’t understand or care about the web, spent their time inventing random new things for demos trying to get you to build on top of their platform INSTEAD of the web, and was never willing to spend time on support.

> JavaScript is not any better than Flash or ActiveX and I really don't understand why people pretend it is.

Because it is. Both of those were hard to use without crashing the browser - the primary selling point for Chrome originally was that it used process sandboxing and so when Flash crashed you wouldn’t lose every open window - whereas what we’re seeing now are complex attacks requiring considerable investment finding ways to get around the layers of precautions. It’s like saying that there’s no difference between leaving your money under the mattress and putting it in the bank because banks still get robbed.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by Amigo5862 on Wednesday January 24, 2024 @02:35PM (#39121673)
> Flash was never a core part of the web

LOL.

> That was the problem: it was loosely bolted onto browsers but the company behind it didn’t understand or care about the web

Ah, right, that's why they made this thing for the web and supported it for a couples of decades: they didn't care about it.

> spent their time inventing random new things for demos trying to get you to build on top of their platform INSTEAD of the web, and was never willing to spend time on support.

Oh, so exactly like the current biggest browser (i.e. JavaScript) vendor in the world, you mean?

> Because it is

LOL

> Both of those were hard to use without crashing the browser

I, quite literally, never experienced that. Are you actually old enough to have ever used Flash? Because it doesn't seem like it.

> the primary selling point for Chrome originally was that it used process sandboxing and so when Flash crashed you wouldn’t lose every open window

That was most definitely not the primary selling point of Chrome. The process sandboxing was definitely nice, but because Chrome crashed (and crashes) with or without Flash.

> whereas what we’re seeing now are complex attacks requiring considerable investment finding ways to get around the layers of precautions

So you mean, like with Flash.

> It’s like saying that there’s no difference between leaving your money under the mattress and putting it in the bank because banks still get robbed

No, it's really not like saying that at all.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by acdha on Wednesday January 24, 2024 @02:55PM (#39121864)
> That was most definitely not the primary selling point of Chrome.

It was very popular, especially for people who did support or were the “tech guy” for their friends & family. Chrome had multiple nice features but the one which most frequently got people to switch permanently was not losing all of your work when Flash crashed. Not having to tell people that the big comment they’d been working on for an hour was permanently gone because some ad in a different windows crashed Flash lead to a lot of installs.

This was especially bad for anyone developing in Flash because Adobe was motivated to sell licenses and only cared about reliability to the extent that it impacted sales. Their vision was that instead of using web technologies you’d target Flash and run things maybe on the web, desktops, mobile, or set top boxes but always Flash. The problem with that was that they mostly focused on shiny new things which demoed well but didn’t spend money on QA or support. I shipped a couple of Flash apps in the 2000s where we hit basic bugs in their library code, and the support process was basically that you filed a bug report with a ton of details, didn’t hear anything back until the next major release, and then the issue would be automatically closed with a generic suggestion that you try buying the new version and reporting if it wasn’t fixed. $800 later, you could repeat the process as they never once fixed a bug even with a simple reproducible test case.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by bsimpson on Wednesday January 24, 2024 @04:24PM (#39122823)
An important point that you're both missing:

Flash did things "web technologies" didn't. There was no module system, no React, no custom elements. JavaScript was a bit like bash: usable for simple things, but only masochists would use it for anything complex.

The early Google web properties - Maps and Gmail - were the vanguard of the web as an interactive platform. As I recall, they were actually written in Java and translated to JavaScript (by GWT) in part because of how limited JS was as a platform at the time.

To this day, there are things that's were easy in Flash that are borderline impossible on the web. The dual paradigm of drawing when drawing is easiest and coding when it isn't was really powerful, and the modern web still misses that.

I was thinking the other day of making a button that transitions into a throbber when you click it. Would have been a fun afternoon project in Flash. Would be a couple weeks of math homework in JS.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by throwitaway1123 on Wednesday January 24, 2024 @08:30PM (#39125092)
> Flash did things "web technologies" didn't.

This is true. Especially before HTML5's canvas, video, and audio elements were standardized. Things have gotten so much better now with the advent of the Web Animation API also.

As powerful as Flash was though, sometimes that power was misused. I remember websites with slow intro animations that you had to wait to load before using the website. Flash also powered some of the most annoying advertisements I've ever had the displeasure of viewing.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by josephg on Wednesday January 24, 2024 @05:34PM (#39123514)
> As I recall, they were actually written in Java and translated to JavaScript (by GWT) in part because of how limited JS was as a platform at the time.

GWT - at least the opensource version - came a few years after Gmail launched. I’m pretty sure gmail and other Google products of that era were written using the Google Closure compiler. Not GWT. (Not to be confused with closure the language).

The closure compiler was written in Java, but it was a JS-to-JS compiler similar to a js bundler, minifier and the typescript compiler all rolled into one. Its input was (is) a semi-typed JavaScript dialect where types were put in special comments. It has a lot of code analysis & optimisation tricks that I think still aren’t present anywhere else in the JavaScript ecosystem. And it came with a batteries-included standard library that was really needed at the time, to both pave over browser differences and provide a lot of missing functionality. (Js was a scrapyard back then).

I’m surprised the closure compiler never saw much use outside of Google. It was a lovely piece of software for its time. It’s opensource - but nobody seems to know about it.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by vacuity on Wednesday January 24, 2024 @05:27PM (#39123440)
> To this day, there are things that's were easy in Flash that are borderline impossible on the web...

My only experience with Flash is playing Flash games, heh. What would you say made Flash so powerful to achieve such things?

Re:Out of bounds memory access in V8 in Google Chrome prior ... by bsimpson on Wednesday January 24, 2024 @06:31PM (#39124104)
That's a longer answer than I have scope to type right now…

The short version is the seamless interplay between drawn and coded objects. The viewport was called a Stage (Illustrator's equivalent is the Artboard). The Flash tool had all the vector drawing goodies you'd expect. Everything you drew on the Stage was a DisplayObject. Everything you coded was also a DisplayObject. Things that were easier to draw than code, you would create in the Flash app. Things that were parametric (e.g. you want 200 of them, or you want to explain in code how a thing moves), you'd code. You could easily import drawn assets into code, or drag visual containers for coded assets onto the Stage.

Modern JavaScript does an okay job at the coded aspect of it, but first class support for hand-drawn assets is totally missing. SVG (Adobe's attempt to compete with Flash before they bought it) can handle still images, but nothing is seamlessly multi-modal like Flash was.

The other thing Flash had going for it that nothing else does is animation. Even today, motion designers are stuck using After Effects (a tool designed for movie titles and broadcast news graphics). We still don't have a good tool for making interfaces that move, which means our ability to make properly interactive interfaces was severely knee-capped when Flash was removed.

So Flash let you draw and animate at whatever level of fidelity you wanted - draw an arm, animate a progress indicator - and use those assets seamlessly in code. Or code the parts that are painful to draw and lay everything out visually. It really let you use the best tool for the job, and it provided some best-in-class tools for those parts of the job that still aren't matched today.

PS: One of the coolest parts of Flash that nobody talks about was its ability to treat vectors like clay. Illustrator and the tools it inspired make you compose a vector out of points and bezier handles. Vector creation in those tools requires deft use of barely-abstracted math - it's a craft that's hard to master.

In Flash, on the other hand, you could just push and pull on the edge of a shape until it looked how you wanted. It abstracted the bezier into a more humane form, and that's just one of countless microtools that we lost when we lost Flash.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by throwitaway1123 on Wednesday January 24, 2024 @08:47PM (#39125241)
> The other thing Flash had going for it that nothing else does is animation. Even today, motion designers are stuck using After Effects (a tool designed for movie titles and broadcast news graphics). We still don't have a good tool for making interfaces that move, which means our ability to make properly interactive interfaces was severely knee-capped when Flash was removed.

We definitely need an easy to use GUI for building complex animations. Exporting animations from After Effects via Lottie is not an ideal solution. Maybe Rive or some other startup will fully supplant this workflow at some point.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by acdha on Wednesday January 24, 2024 @06:16PM (#39123952)
Oh, sure, I wasn’t saying that Flash was entirely without value - we all used it for a reason - but simply that it wasn’t a web native technology. That proved to be its downfall: the entire ecosystem depended on the whims of a company which just isn’t interested in supporting platforms, and that proved to be fatal in the end.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by Amigo5862 on Tuesday January 30, 2024 @01:02PM (#39193404)
very popular != primary selling point
Re:Out of bounds memory access in V8 in Google Chrome prior ... by refulgentis on Wednesday January 24, 2024 @02:46PM (#39121783)
Way too condescending and hyperbolic in turn, the general excuse being you believe the other post was hyperbolic. Even if the every assertion was 100% correct...D-. Revise and edit and please come see me after class.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by Amigo5862 on Tuesday January 30, 2024 @01:04PM (#39193427)
No, actually I just don't have time for idiots who make unfalsifiable statements when they've been shown they're wrong.

(BTW, uncrashable Chrome just "crashed" for me: all windows, across two profiles, stopped accepting input properly. But hey, Flash bad!)

Re:Out of bounds memory access in V8 in Google Chrome prior ... by rezonant on Wednesday January 24, 2024 @05:23PM (#39123394)
Take it down a notch. Please try to adhere to the Hacker News guidelines when posting[1]

[1] https://news.ycombinator.com/newsguidelines.html

Re:Out of bounds memory access in V8 in Google Chrome prior ... by Amigo5862 on Tuesday January 30, 2024 @01:03PM (#39193419)
LOL.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by bee_rider on Wednesday January 24, 2024 @12:42PM (#39120197)
Either “sandbox” was the funniest and most appropriate name ever chosen in tech, or the person who came up with it has never actually seen a sandbox.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by Spivak on Wednesday January 24, 2024 @12:17PM (#39119856)
Whether or not you review your deps code is on you, it doesn't make it untrusted. You're trusting them whether you do the due diligence to see if that trust is warranted or not. Untrusted means code that comes from outside your system, like 3rd party extensions to your app and is presumed to be completely broken and actively malicious and nonetheless shouldn't crash your own program or reveal sensitive data.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by rezonant on Wednesday January 24, 2024 @05:29PM (#39123460)
There is a massive difference between the supply chain risks of open source packages and actively fetching and executing remote code provided as user input like the browser inherently does.

The case of user provided extensions definitely falls a lot closer to the supply chain threat model.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by christophilus on Wednesday January 24, 2024 @11:55AM (#39119601)
Everyone who runs Node runs untrusted code (depending on your definition of untrusted). No one I’ve ever worked with made an effort to review the source of the thousands of dependencies they were slinging around.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by GabrielTFS on Wednesday January 24, 2024 @12:41PM (#39120187)
I would expect "untrusted code" to mean "code in a sandbox" or "code I'm not gonna run at all anytime soon", so running code from thousands of dependencies in node is effectively trusting all of that code, unless it is your direct expectation that it is malicious (and even then, aren't you trusting it to be malicious ?).

The trust we give to random dependencies like that is quite arguably unwarranted to a large degree, but it doesn't mean the code isn't trusted.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by bee_rider on Wednesday January 24, 2024 @01:06PM (#39120581)
I’m pretty sure untrusted code means code you can’t trust, which includes any code that you haven’t either analyzed yourself or put through some sort of institutional review with auditable sign-offs.

It is how these conversations always go:

There’s a hole in the sandbox.

If you were trusting the sandbox, you were already doomed.

Nobody validates their code well enough to trust it. (we are here)

The ecosystem and industry is just irreparably damaged.

What am I supposed to do about that?

Non-solutions, because it is an impossible problem to actually fix

Re:Out of bounds memory access in V8 in Google Chrome prior ... by graemep on Wednesday January 24, 2024 @01:22PM (#39120774)
Web browsers rely on the sandbox. Almost everyone runs untrusted code single day. There are very few people who do not trust the sandbox.

It does not directly affect servers if one rejects your rather broad definition of untrusted, but does indirectly.

> I’m pretty sure untrusted code means code you can’t trust, which includes any code that you haven’t either analyzed yourself or put through some sort of institutional review with auditable sign-offs.

That is so broad that very people are running trusted code. You would need to ensure your entire stack down to the firmware it runs on had been analysed.

Re:Out of bounds memory access in V8 in Google Chrome prior ... by bee_rider on Wednesday January 24, 2024 @01:24PM (#39120811)
Sounds like the ecosystem and industry is just irreparably damaged.
Re:Out of bounds memory access in V8 in Google Chrome prior ... by lq9AJ8yrfs on Wednesday January 24, 2024 @01:38PM (#39121001)
Serverless and CDN style edge compute are two scenarios that this may be relevant to, where untrusted or semi-trusted code may run in some construction on top of V8. Especially providers of those services are probably tuned in right now or ought to be.