News for hackers. Stuff that matters.
Re:ESLint compromised, may have stolen your credentials by fulafel on Thursday July 12, 2018 @09:32AM (#17514288)
We don't really know how to audit for backdoors/vulns that don't want to be found. See eg the underhanded c contest.
Re:ESLint compromised, may have stolen your credentials by _bxg1 on Thursday July 12, 2018 @09:39AM (#17514381)
Due to sandboxing, the concerns for malicious JS are different from those of C. From what I've seen, bad JS usually tries to record/read and then exfiltrate data, which can only be done through a narrow set of native APIs, which would be comparatively easy to check for.
Re:ESLint compromised, may have stolen your credentials by fulafel on Thursday July 12, 2018 @09:43AM (#17514440)
This was a node app, running without sandbox.

For sandboxed browser apps, I think the exfiltration problem is not much easier - there are a zillion ways a piece of data can get incorporated into an outgoing xhr or image url. And everything can be monkey-patched. And the code will get transpiled, minified and webpacked etc a zillion times over, all steps which are attractive spots to mess with your code.

Re:ESLint compromised, may have stolen your credentials by _bxg1 on Thursday July 12, 2018 @09:52AM (#17514535)
Also, it's still easy to detect fetch/XHR/img requests that appear out of nowhere and scrutinize them as points of interest. No matter how much your code is obfuscated and minimized, it still has to go through those APIs. There's no way around that.
Re:ESLint compromised, may have stolen your credentials by fulafel on Thursday July 12, 2018 @10:54AM (#17515218)
Actually there is the famiar bestiary of side-channels available (eg timing, traffic modulation), along with web-specific ones (cookies, dns, non-http protocols such as webrtc, etc).

Also, fields in XHR payloads are frequently not human-readable.

Even discounting the above - scrutinizing the XHR payloads with a suspicious eye is in any event labour-intensive expert work. It happens once in a blue moon in security audits, and has a fairly low detection rate given the amount of inherently malware-like behaviour that most commercial web apps incorporate (eg img-tags used to carry tracker payloads is routine behaviour from google and facebook, and iframes used to embed terrible things).

Re:ESLint compromised, may have stolen your credentials by _bxg1 on Thursday July 12, 2018 @09:51AM (#17514519)
Maybe sandbox is the wrong technical term, but JS as a language runs with constraints. It can't manipulate pointers, mainly. As far as I know there's no such thing as a buffer-overflow attack in the context of Node.js.
Re:ESLint compromised, may have stolen your credentials by fulafel on Thursday July 12, 2018 @10:02AM (#17514644)
If the malicious JS code is already running in node, there is no need to exploit a RCE bug.

edit: to expand, an underhanded js bug might be a path traversal bug, xss bug, leak of session cookies - any of the familiar js security bugs that occur as honest mistakes too.

(But while on the subject, Node API's are historically quite unsafe and do have lots of memory safety vulns, search results are in 3 digits in the issue tracker for queries like segfault. Node API's are not really written with hostile code in mind.)