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

RCE Vulnerability in React and Next.js

github.com

Post reply on HN
Print view View original

261–270 of 276 posts

Re: RCE Vulnerability in React and Next.js

#261

Post by steve_adams_86 »

ashishb wrote: post #250
steve_adams_86 wrote: post #248

Earlier quoted context omitted.

If you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits. Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use. Bun also allows for this but it fe…

> If you use deno you can consume dependencies much more securely How would Deno have prevented the RCE issue with React+Next.js?

It wouldn't. I was responding to your concerns about the TypeScript ecosystem more generally.

You avoid the RCE by recognizing that React—and more recently Vercel's—management is a bit of a tire fire, and you should choose better tools with more responsible maintainers.

Part of what bothers me about this situation is that React appears to be a view library, and to many people using it that is what it functions as... But it's now a framework which extends well beyond the browser and entails all kinds of security risks that aren't intuitive at a glance, at all. A lot of people using Next probably have no idea about the security implications of the framework or how React fits into them. It's a mess.

Deno definitely can't fix that.

Re: RCE Vulnerability in React and Next.js

#263

Post by testjag »

coffeecoders wrote: post #35

This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…

How do hackers exploit it? Can I test it on my site?

Re: RCE Vulnerability in React and Next.js

#264

Post by samdoesnothing »

zbentley wrote: post #257
samdoesnothing wrote: post #64

This is genuinely embarrassing for the Next.js and React teams. They were warned for years that their approach to server-client communication had risks, derided and ignored everyone who didn't provide unconditional praise, and now this. I think their time as Javascript thought leaders is past due.

Curious, not critical: got links to the warnings that were given about this approach over the years? I’m interested in learning more about the history here.

Not really, I didn't keep receipts. This stuff was discussed heavily on X a couple years ago when they were first launched and a lot of people questioned the wisdom of implicit RPC and blurring the lines between client/server, and the increasing complexity of React. I'm sure there were some articles written as well.

I believe one of the React email services got pwned because they leaked sensitive info via RSC, and there was a whole fiasco around Next.js encrypting server secrets and sending them to the client.

Lo and behold just a couple years later, a lvl 10 RCE because of the complexity of their RPC approach coupled with the blurring of the lines between client/server...it's not like it's surprising to us. A repro of the vulnerability is on X & Github if you want to search for it, it's a classic deserialization bug that only exists because their format is so complex (and powerful).

Remember a lot of us use React as a UI library and to see it causing our servers to get pwned is what people were uneasy about when they announced RSC.

Unfortunately much of this discussion is on X which makes it hard to find, especially because I think Dan Abromov deleted his X account.

Re: RCE Vulnerability in React and Next.js

#265

Post by bfelbo »

vanwal_j wrote: post #245
Rauchg wrote: post #27

Earlier quoted context omitted.

We collaborated with many industry partners to proactively deploy mitigations due to the severity of the issue. We still strongly recommend everyone to upgrade their Next, React, and other React meta-frameworks (peer)dependencies immediately.

Does this include any provider that does not fall under USA CLOUD Act? This vulnerability disclosure timeline is a nightmare for us Europeans, it was fully disclosed yesterday late afternoon for us and I can trace back attack logs that happend during the night. I expect some downfalls from this. I genuinely believe Next.JS is a great framework, but as an European developer working on software that should not touch an…

It’s infuriating how US-centric some OSS maintainers can be. Really sad if the OOS ecosystem also have to fragment into pieces like much of the internet is starting to.

Re: RCE Vulnerability in React and Next.js

#266

Post by halflife »

azangru wrote: post #244
pas wrote: post #205

Earlier quoted context omitted.

No one forced you to migrate immediately. (Also, non-value-adding work? You don't think the rewrite to TS did not bring any value? And thanks to that rewrite that app can be upgraded even today to Angular v21. And likely it'll be the case for many years.) React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects. Eco…

> Google throws products under the bus, but not so much OSS projects. It abandoned the Material Design web components project, which, I think, attracted some Polymer people. Speaking of Polymer, it has evolved into Lit; but I understand there is no more support for that project from Google. Lit has joined the OpenJS foundation to stay afloat. The Googlers that used to work on Lit, and on Material Design web component…

The angular material design library is so much better than the react one. And it is supported by google. The material CDK is amazing to create custom components easily

Re: RCE Vulnerability in React and Next.js

#267

Post by amluto »

koakuma-chan wrote: post #234
lionkor wrote: post #219

Earlier quoted context omitted.

This is only really fine as long as you have extremely clearly, well defined actions. You need to verify that the request is sane, well-formed, and makes sense for the current context, at the very least.

You would probably need to do the same if you were writing back-end in Go or something. I don't see how that is conceptually different.

As I understand it, RSC is locating the code to run by name, where the name is supplied by the client.

JS/Node can do this via import() or require().

C, C++, Go, etc can dynamically load plugins, and I would hope that people are careful when doing this when client-supplied data. There is a long history of vulnerabilities when dlopen and dlfcn are used unwisely, and Windows’s LoadLibrary has historical design errors that made it almost impossible to use safely.

Java finds code by name when deserializing objects, and Android has been pwned over and over as a result. Apple did the same thing in ObjC with similar results.

The moral is simple: NEVER use a language’s native module loader to load a module or call a function when the module name or function name comes from an untrusted source, regardless of how well you think you’ve sanitized it. ALWAYS use an explicit configuration that maps client inputs to code that it is permissible to load and call. The actual thing that is dynamically loaded should be a string literal or similar.

I have a boring Python server I’ve maintained for years. It routes requests to modules, and the core is an extremely boring map from route name to the module that gets loaded and the function that gets called.

Re: RCE Vulnerability in React and Next.js

#268

Post by ectospheno »

int_19h wrote: post #172
harrall wrote: post #103

Earlier quoted context omitted.

I see this type of vulnerability all the time. Seen it in Java, Lua, JavaScript, Python and so on. I think deserialization that relying on blacklists of properties is a dangerous game. I think rolling your own object deserialization in a library that isn’t fully dedicated to deserialization is about as dangerous as writing your own encryption code.

Only if you're deserializing into objects with behavior.

What does data in a program do apart from eventually modify behavior?
Post reply on HN