6 ms·

> Some have argued that the ill health of the npm registry is a social, rather than a technical problem In some cases it is, yes, for packages that require so

> Some have argued that the ill health of the npm registry is a social, rather than a technical problem In some cases it is, yes, for packages that require so many access privileges that they can subvert the entire system they run on. But this is not the case for (I'd estimate) the majority of libraries, because they are purely computational, they only transform data and do not need access rights to any external interfaces (filesystem, network, user input, displays, ...). Malicious data generated by sandboxed programs is still a problem, still the problem would be localized. There are efforts underway that would allow Javascript programs to effectively and economically sandbox each other and grant only the minimum number of privileges they need to perform their tasks: https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... Avoiding global mutable state and https://en.wikipedia.org/wiki/Ambient_authority https://en.wikipedia.org/wiki/Ambient_authority, being able to grant rights in an opt-in fashion and to transfer them in a way that is robust in multi-party settings in accordance with https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security This is the https://en.wikipedia.org/wiki/Principle_of_least_privilege https://en.wikipedia.org/wiki/Principle_of_least_privilege and I encourage every language, virtual machine and operating system designer to understand it and implement it in their systems. Then, the social attack surface can be technically minimized.

slaymaker1907 6y ago
More languages should really be doing this and encouraging it. The JVM can sandbox pretty well using a security manager, but most people don't use the sandbox.
- 7373737373 6y ago
  Only very few language also provide the type of security the JVM (partially) protects against: resource exhaustion attacks. Being able to prevent time (e.g. infinite loops) and space (memory allocation) exhaustion by being able to specify absolute or relative limits on these. Stackless Python is able to limit the number of instruction steps that are run in a tasklet: https://stackless.readthedocs.io/en/latest/library/stackless/pickling.html https://stackless.readthedocs.io/en/latest/library/stackless... With some ugly hacks, Lua can do it too. But no language I know of can do all these things, I tried to build one once: https://esolangs.org/wiki/RarVM https://esolangs.org/wiki/RarVM
RL_Quine 6y ago
I don't think that the same community producing huge quantities of single use libraries for the sake of padding their resumes will get involved with sandboxing. I recently installed a relatively simply piece of software using NPM and was stunned when it downloaded hundreds dependencies from god knows where, there's simply no ability for anybody to ever evaluate the security risk of NodeJS applications. https://npm.anvaka.com/#/view/2d/zigbee2mqtt https://npm.anvaka.com/#/view/2d/zigbee2mqtt
- 7373737373 6y ago
  Then perhaps single use libraries should be limited to 'computation only' by default :)
- Chyzwar 6y ago
  This module use widely used packages in node. In any non-trivial node project you would already have these. Whole point of small single use packages is to prevent from re-inventing a wheel. People are bashing node community without understanding. Typical you would have people publish hundreds similar packages to solve a specific problem. Over time, best maintained, feature complete would "win" and become a standard, at this point other packages would converge and use these 1/2 top solutions. This process allow exploring large space of possible solutions and prevent app developers from NIH. There is more churn, but also more innovation and productivity. See for example css-in-js evolution story. https://www.youtube.com/watch?v=75kmPj_iUOA https://www.youtube.com/watch?v=75kmPj_iUOA
- cxr 6y ago
  > there's simply no ability for anybody to ever evaluate the security risk of NodeJS applications So don't. Tell people that you're not going to run their NodeJS crud and let them know it would be better to write their scripts wherever possible to be able to run on the sandboxed JS runtime that everyone already happens to have installed: the browser. https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646
  - IggleSniggle 6y ago
geofft 6y ago
The principle of least privilege/authority has been around for a while, and the reason we don't see much adoption of it in real-world systems is not because it's unknown. The first question is overhead: it's true that the majority of libraries are purely computational, but that means that there's frequent interaction between code written by the end developer and code from the library. If every call to, say, lodash's _.filter goes through a process to marshal the programmer's list, send it to a separate execution environment, and then marshal it right back in the other direction to call the predicate, people would choose not to use it. I do agree that the proposal in the post you link to seems to be on the right track - directly run the code in the current execution environment if it can be statically demonstrated that the code has no access to dangerous capabilities. The second question is making the policy decision about whether to grant privileges. You might be familiar with this from your mobile phone: the security architecture is miles better than that of your desktop OS, but still, most people do say "yes" when asked to let Facebook, Twitter, Slack, etc. access their photos and their camera and their microphone, because they intentionally want those apps to have some access. What do you do in the above model when, say, the "request" library wants access to the network? Now it can exfiltrate all of your data. (The capability-based model is that you pass into the library a capability to access the specific host it should talk to, instead of giving it direct access, but again, if it did this, people would choose not to use it - the whole point of these libraries is to make writing code more convenient.) The other problem, and perhaps the most important, is that purely-computational libraries can still be dangerous. Yes, _.filter (and perhaps all of lodash) is purely computational, but if you're using it to, say, restrict which user records are visible on a website, and someone malicious takes over lodash, they can edit the filter function to say, "if the username is me, don't filter anything at all." Or if you had a capability-based HTTP client that only talked to a single server, the library could still lie about the results that it got from the server. I think the way to think about it is that the principle of least privilege is a mitigation strategy, like ASLR or filtering out things that look like SQL statements from web requests. ASLR mitigates not being able to guarantee that your code is memory-safe; if you could, you wouldn't need it. SQL filtering mitigates making mistakes with string interpolation (but it comes with a significant cost, so you really want to avoid it if you can). Least privilege mitigates the reality that you cannot code-review all of your code and its dependencies to ensure that it's free of bugs. But, on the other hand, a mitigation is not a license to stop doing the thing you can't do perfectly - it's just a safety measure. You can still have serious security bugs from buffer overflows even with ASLR; you just have fewer. You should not use ASLR as an excuse to write memory-unsafe code. You can still have SQL injection attacks from people being clever about smuggling strings. You should not use a WAF as an excuse to not use parametrization in SQL queries. And you can still have malicious dependencies cause problems even in a least-privilege situation, because they still have some privilege. You should not use it as a reason to run dependencies you don't trust.
sergeykish 6y ago
Reminds of Gilad Bracha Newspeak.
- 7373737373 6y ago
  While most Smalltalk-like languages are good candidates for such security mechanisms, they have never been integrated, perhaps because the mostly academic environment in which they are developed is more cooperative than malicious.
inopinatus 6y ago
So basically, rely on about 5% of JavaScript (my copy of JavaScript: The Good Parts is looking slimmer every day) and hope that everything you’re either directly or transitively exposed to has exactly the same standards you do and will continue to do so in perpetuity, and/or build tons of additional scaffolding to try to sandbox violators, because that has always been such a sure fire path to secure code. The language, and it’s ecosystem, is a baroque Gormenghast of curiosities built on an ancient sewer where nightmare beasts still roam, and you’ll never stop it stinking just by holing up in the throne room and hoping a few trusted paladins will decontaminate the rest.
- cgh 6y ago
  An excellent comment that merits upvotes based on the Gormenghast reference alone.
- markholmes 6y ago
  So what’s the best way out?
  - inopinatus 6y ago
    New languages, new paradigms at the foundations. We keep throwing new shit at the wall, eventually something sticks. To a whole generation of developers it might like like JavaScript is the One True Web Programming Language but anyone whose lived through a few transitions knows that we replace entrenched technologies on the scale of decades, it has come and it will go like everything else, sic transit gloria lingua. The usual (but not universal) trigger is a technological arms race between three or more competing firms attached to a compelling new idea.
    - alquemist 6y ago
      Not sure how a new language can help with an ecosystem problem. In the old days, people write your own code and relied on a vendor provided standard lib, for example C++ stdlib, Java platform or Python's batteries included. Since software is expensive, to save time and money people started to rely on 3rd party libraries, conveniently delivered by package repositories, for example CPAN, PyPI or npm. A new language will be subject to the exact same cost and delivery deadline pressures. If anything, newer languages tend to have ecosystems even more dependent of 3rd party modules. The PL problem is largely solved, the ecosystem problem is not.
stefan_ 6y ago
Trying to solve the halting problem are we. Remember that one of the most dangerous JavaScript APIs turned out to be a sub-millisecond monotonically increasing time source.
- samatman 6y ago
  Solving the halting problem is quite tractable. You can do it the right way, by using total functional programming. Or you can do it the wrong way, by providing a time budget or "gas", and yanking the process if and when it's exceeded. No, this is more of a Rice's Theorem kind of situation...
  - 7373737373 6y ago
    Why do you think using 'gas' is the wrong way? Not only does it solve this problem, it solves it in a deterministic way, which has many applications, for example deterministic debugging and replicable computation!
    - samatman 6y ago
      I don't, actually. What I really meant was that total functional programming is the MIT way to do it, and gas caps or supervisors are the New Jersey way to do it.
- matheusmoreira 6y ago
  > one of the most dangerous JavaScript APIs turned out to be a sub-millisecond monotonically increasing time source Details?
  - acemarke 6y ago
    Pretty sure that's a reference to the Spectre CPU timing attacks and JS's SharedArrayBuffer type being used to construct timers as an attack vector: https://v8.dev/blog/spectre https://v8.dev/blog/spectre

slaymaker1907 6y ago

More languages should really be doing this and encouraging it. The JVM can sandbox pretty well using a security manager, but most people don't use the sandbox.

7373737373 6y ago
Only very few language also provide the type of security the JVM (partially) protects against: resource exhaustion attacks. Being able to prevent time (e.g. infinite loops) and space (memory allocation) exhaustion by being able to specify absolute or relative limits on these. Stackless Python is able to limit the number of instruction steps that are run in a tasklet: https://stackless.readthedocs.io/en/latest/library/stackless/pickling.html https://stackless.readthedocs.io/en/latest/library/stackless... With some ugly hacks, Lua can do it too. But no language I know of can do all these things, I tried to build one once: https://esolangs.org/wiki/RarVM https://esolangs.org/wiki/RarVM

RL_Quine 6y ago

I don't think that the same community producing huge quantities of single use libraries for the sake of padding their resumes will get involved with sandboxing. I recently installed a relatively simply piece of software using NPM and was stunned when it downloaded hundreds dependencies from god knows where, there's simply no ability for anybody to ever evaluate the security risk of NodeJS applications. https://npm.anvaka.com/#/view/2d/zigbee2mqtt https://npm.anvaka.com/#/view/2d/zigbee2mqtt

7373737373 6y ago
Then perhaps single use libraries should be limited to 'computation only' by default :)
Chyzwar 6y ago
This module use widely used packages in node. In any non-trivial node project you would already have these. Whole point of small single use packages is to prevent from re-inventing a wheel. People are bashing node community without understanding. Typical you would have people publish hundreds similar packages to solve a specific problem. Over time, best maintained, feature complete would "win" and become a standard, at this point other packages would converge and use these 1/2 top solutions. This process allow exploring large space of possible solutions and prevent app developers from NIH. There is more churn, but also more innovation and productivity. See for example css-in-js evolution story. https://www.youtube.com/watch?v=75kmPj_iUOA https://www.youtube.com/watch?v=75kmPj_iUOA
cxr 6y ago
> there's simply no ability for anybody to ever evaluate the security risk of NodeJS applications So don't. Tell people that you're not going to run their NodeJS crud and let them know it would be better to write their scripts wherever possible to be able to run on the sandboxed JS runtime that everyone already happens to have installed: the browser. https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646
- IggleSniggle 6y ago

geofft 6y ago

The principle of least privilege/authority has been around for a while, and the reason we don't see much adoption of it in real-world systems is not because it's unknown. The first question is overhead: it's true that the majority of libraries are purely computational, but that means that there's frequent interaction between code written by the end developer and code from the library. If every call to, say, lodash's _.filter goes through a process to marshal the programmer's list, send it to a separate execution environment, and then marshal it right back in the other direction to call the predicate, people would choose not to use it. I do agree that the proposal in the post you link to seems to be on the right track - directly run the code in the current execution environment if it can be statically demonstrated that the code has no access to dangerous capabilities. The second question is making the policy decision about whether to grant privileges. You might be familiar with this from your mobile phone: the security architecture is miles better than that of your desktop OS, but still, most people do say "yes" when asked to let Facebook, Twitter, Slack, etc. access their photos and their camera and their microphone, because they intentionally want those apps to have some access. What do you do in the above model when, say, the "request" library wants access to the network? Now it can exfiltrate all of your data. (The capability-based model is that you pass into the library a capability to access the specific host it should talk to, instead of giving it direct access, but again, if it did this, people would choose not to use it - the whole point of these libraries is to make writing code more convenient.) The other problem, and perhaps the most important, is that purely-computational libraries can still be dangerous. Yes, _.filter (and perhaps all of lodash) is purely computational, but if you're using it to, say, restrict which user records are visible on a website, and someone malicious takes over lodash, they can edit the filter function to say, "if the username is me, don't filter anything at all." Or if you had a capability-based HTTP client that only talked to a single server, the library could still lie about the results that it got from the server. I think the way to think about it is that the principle of least privilege is a mitigation strategy, like ASLR or filtering out things that look like SQL statements from web requests. ASLR mitigates not being able to guarantee that your code is memory-safe; if you could, you wouldn't need it. SQL filtering mitigates making mistakes with string interpolation (but it comes with a significant cost, so you really want to avoid it if you can). Least privilege mitigates the reality that you cannot code-review all of your code and its dependencies to ensure that it's free of bugs. But, on the other hand, a mitigation is not a license to stop doing the thing you can't do perfectly - it's just a safety measure. You can still have serious security bugs from buffer overflows even with ASLR; you just have fewer. You should not use ASLR as an excuse to write memory-unsafe code. You can still have SQL injection attacks from people being clever about smuggling strings. You should not use a WAF as an excuse to not use parametrization in SQL queries. And you can still have malicious dependencies cause problems even in a least-privilege situation, because they still have some privilege. You should not use it as a reason to run dependencies you don't trust.

sergeykish 6y ago

Reminds of Gilad Bracha Newspeak.

7373737373 6y ago
While most Smalltalk-like languages are good candidates for such security mechanisms, they have never been integrated, perhaps because the mostly academic environment in which they are developed is more cooperative than malicious.

inopinatus 6y ago

So basically, rely on about 5% of JavaScript (my copy of JavaScript: The Good Parts is looking slimmer every day) and hope that everything you’re either directly or transitively exposed to has exactly the same standards you do and will continue to do so in perpetuity, and/or build tons of additional scaffolding to try to sandbox violators, because that has always been such a sure fire path to secure code. The language, and it’s ecosystem, is a baroque Gormenghast of curiosities built on an ancient sewer where nightmare beasts still roam, and you’ll never stop it stinking just by holing up in the throne room and hoping a few trusted paladins will decontaminate the rest.

cgh 6y ago
An excellent comment that merits upvotes based on the Gormenghast reference alone.
markholmes 6y ago
So what’s the best way out?
- inopinatus 6y ago
  New languages, new paradigms at the foundations. We keep throwing new shit at the wall, eventually something sticks. To a whole generation of developers it might like like JavaScript is the One True Web Programming Language but anyone whose lived through a few transitions knows that we replace entrenched technologies on the scale of decades, it has come and it will go like everything else, sic transit gloria lingua. The usual (but not universal) trigger is a technological arms race between three or more competing firms attached to a compelling new idea.
  - alquemist 6y ago
    Not sure how a new language can help with an ecosystem problem. In the old days, people write your own code and relied on a vendor provided standard lib, for example C++ stdlib, Java platform or Python's batteries included. Since software is expensive, to save time and money people started to rely on 3rd party libraries, conveniently delivered by package repositories, for example CPAN, PyPI or npm. A new language will be subject to the exact same cost and delivery deadline pressures. If anything, newer languages tend to have ecosystems even more dependent of 3rd party modules. The PL problem is largely solved, the ecosystem problem is not.

stefan_ 6y ago

Trying to solve the halting problem are we. Remember that one of the most dangerous JavaScript APIs turned out to be a sub-millisecond monotonically increasing time source.

samatman 6y ago
Solving the halting problem is quite tractable. You can do it the right way, by using total functional programming. Or you can do it the wrong way, by providing a time budget or "gas", and yanking the process if and when it's exceeded. No, this is more of a Rice's Theorem kind of situation...
- 7373737373 6y ago
  Why do you think using 'gas' is the wrong way? Not only does it solve this problem, it solves it in a deterministic way, which has many applications, for example deterministic debugging and replicable computation!
  - samatman 6y ago
    I don't, actually. What I really meant was that total functional programming is the MIT way to do it, and gas caps or supervisors are the New Jersey way to do it.
matheusmoreira 6y ago
> one of the most dangerous JavaScript APIs turned out to be a sub-millisecond monotonically increasing time source Details?
- acemarke 6y ago
  Pretty sure that's a reference to the Spectre CPU timing attacks and JS's SharedArrayBuffer type being used to construct timers as an attack vector: https://v8.dev/blog/spectre https://v8.dev/blog/spectre