6 ms·

If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.

by mccr8 3y ago

christophilus 3y ago
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.
- GabrielTFS 3y ago
  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.
- bee_rider 3y ago
  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
  - graemep 3y ago
    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.
    - bee_rider 3y ago
      Sounds like the ecosystem and industry is just irreparably damaged.
NotSammyHagar 3y ago
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.
- Spivak 3y ago
  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.
- Dalewyn 3y ago
  >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.
  - refulgentis 3y ago
    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.
lq9AJ8yrfs 3y ago
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.

If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.

by mccr8 3y ago

If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.

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.

GabrielTFS 3y ago
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.
bee_rider 3y ago
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
- graemep 3y ago
  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.
  - bee_rider 3y ago
    Sounds like the ecosystem and industry is just irreparably damaged.

NotSammyHagar 3y ago

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.

Spivak 3y ago
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.
Dalewyn 3y ago
>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.
- refulgentis 3y ago
  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.

lq9AJ8yrfs 3y ago

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.