3 ms·

> Now we have to run a background check when someone wants to help? The problem is in the tools. I don't agree with this comment, really. But -- there's almos

> Now we have to run a background check when someone wants to help? The problem is in the tools. I don't agree with this comment, really. But -- there's almost always room for improvement w/tools. IIUC this unpacks encrypted JS bytecode and then executes it? Is there any way to statically know whether this could happen? "var newModule = new module.constructor;" ... newModule['_compile']() From what terribly little I know about Javascript it looks like it would be hard to create a lint/warning that finds this sort of thing without false positives. However, an audit tool that merely discloses this and any other things-that-deserve-greater-scrutiny would be valuable. If you could walk your dependency tree and see whether/when this changes, it would be very useful. Of course, to be useful you probably need some kind of dependency pinning too, which IIUC npm does not (yet) support?

yoklov 8y ago
That doesn't look that far off from what you'll see in generated code, e.g. something like babel could easily output the lines you've pasted. The rest of it is extremely dodgy, of course.
- wyldfire 8y ago
  I feared as much would be the case. Even in non-generated code there's perhaps some instances where that code would make sense. However, if you were to audit your dependencies and find a new case of this, you could examine it further to determine whether it passes muster. I suspect code like this is infrequently added to packages.
  - yoklov 8y ago
    Eh, again, this kind of thing is common for compiler output, and the use of such compilers is very common. I think you'd have more luck looking at static strings and warning on any string that has a sufficiently high entropy. Sure, some of them will be hashes for verification, or compressed harmless data, but it it seems like it would be rare enough to be auditable.
shittyadmin 8y ago
Maybe something that would actually run it in a sandbox and say, catch the calls to AES256 decryption and flag for human review would do the job?
mifreewil 8y ago
npm [recently] now has a lockfile called package-lock.json, in addition to package.json, which defines the entire dependency tree (not just the direct dependencies as package.json does), contains package hashes, and will pin dependencies to specific versions for an application.

yoklov 8y ago

That doesn't look that far off from what you'll see in generated code, e.g. something like babel could easily output the lines you've pasted. The rest of it is extremely dodgy, of course.

wyldfire 8y ago
I feared as much would be the case. Even in non-generated code there's perhaps some instances where that code would make sense. However, if you were to audit your dependencies and find a new case of this, you could examine it further to determine whether it passes muster. I suspect code like this is infrequently added to packages.
- yoklov 8y ago
  Eh, again, this kind of thing is common for compiler output, and the use of such compilers is very common. I think you'd have more luck looking at static strings and warning on any string that has a sufficiently high entropy. Sure, some of them will be hashes for verification, or compressed harmless data, but it it seems like it would be rare enough to be auditable.

shittyadmin 8y ago

Maybe something that would actually run it in a sandbox and say, catch the calls to AES256 decryption and flag for human review would do the job?

mifreewil 8y ago

npm [recently] now has a lockfile called package-lock.json, in addition to package.json, which defines the entire dependency tree (not just the direct dependencies as package.json does), contains package hashes, and will pin dependencies to specific versions for an application.