4 ms·
Detecting sketchy-looking hex codes should be pretty straightforward, but then I imagine there are ways to make sketchy code non-sketchy, which would be immedia
by mystifyingpoi 1y ago
Detecting sketchy-looking hex codes should be pretty straightforward, but then I imagine there are ways to make sketchy code non-sketchy, which would be immediately used. I can imagine a big JS function, that pretends to do legit data manip, but in the process creates the payload.
- nicce 1y agoIt is just about bringing the classic non-signature based antivirus software to the release cycle. Hard to say how useful it is, but usually it is endless cat-and-mouse play like with everything else.
- hombre_fatal 1y agoYeah, It’s merely a fluke that the malware author used some crappy online obfuscator that created those hex code variables. It would have been less work and less suspicious if they just kept their original semantic variables like “originalFetch”.
- Cthulhu_ 1y agoIt wouldn't be just one signal, but several - like a mere patch version that adds several kilobytes of code, long lines, etc. Or a release after a long silent period.
- cluckindan 1y agoA complexity per line check would have flagged it. Even a max line length check would have flagged it.
- chatmasta 1y agoThat would flag a huge percentage of JS packages that ship with minified code.
- jay_kyburz 1y agoHow are people verifying their dependencies if they are minified?
- SethTro 1y agoThat's the magic part, they aren't
- chatmasta 1y agoMy guy… in the JS ecosystem a “lock file” is something that restricts your package installer to an arbitrary range of packages, i.e. no restrictions at all and completely unpredictable. You have to go out of your way to “pin” a package to a specific version.
- Izkata 1y agoLockfiles use exact hashes, not versions/version ranges. Javascript projects use two files, a package file with version ranges (used when upgrading) and a lockfile with the exact version (used in general when installing in an existing project).
- zdragnar 1y agoNPM is rather infamous for not exactly respecting the lockfile, however.
- chatmasta 1y agoSure, but a lockfile with a hash doesn’t mean that next time it will fail if it tries to install a version of the package without that hash. If your package.json specifies a semver range then it’ll pull the latest minor or patch version (which is what happened in this case with e.g. duckdb@1.3.3) and ignore any hash differences if the version has changed. Hence why I say you need to go out of your way to specify an exact version in package.json and then the lock file will work as you might expect a “lock” file to work. (Back when I was an engineer and not a PM with deteriorating coding ability, I had to make a yarn plugin to pin each of our dependencies.) The best way to manage JS dependencies is to pin them to exact versions and rely on renovate bot to update them. Then at least it’s your choice when your code changes. Ideally you can rebuild your project in a decade from now. But if that’s not possible then at least you should have a choice to accept or decline code changes in your dependencies. This is very hard to achieve by default in the JS ecosystem.
- cluckindan 1y agoWhy would you be including minified code in a build? That’s just bad practice and makes development-time debugging more difficult.
- saghm 1y agoIt's not like minified JS can't be parsed and processed as AST. You could still pretty easily split up each statement/assignment to check the length of each one individually.
- cchance 1y agoFeels like a basic light weight 3b AI model could easily spot shit like this on commit