Hacker News Reader

Comment by ashishbijlani | Hacker News Reader

Plug: We've been building Packj [1] to detect such malicious, abandoned, typo-squatting, and other "weak links" in your software supply chain. Supports auditing as well as install-time sandboxing of PyPI/NPM/Ruby packages. It carries out static/dynamic/metadata analysis to look for "suspicious” attributes such as spawning of shell, use of SSH keys, network communication, use of decode+eval, mismatch of GitHub code vs packaged code (provenance), change in APIs across versions, and several more.

1. https://github.com/ossillate-inc/packj

View on HN

How would you deal with malicious packages that randomize or time delay their malicious behavior?

Say you have a package that only triggers the evil activity one out of 10,000 evaluations? It'd have a 99.99% of passing validation but could still wreak havoc on a heavily used client side application.

Ditto for a package that simply delays it's malicious payload until some point in the future, after the scan has occurred? I guess this is a bit easier to test for by future dating the system clock, but again what if it's a random window? (e.g. every other day for five minutes, at 4:59pm UTC).

You're right; a sophisticated bad actor can employ time- or event-based hiding techniques. However, these limitations apply to dynamic/runtime analysis only. Packj performs static+dynamic+metadata analysis. As static analysis scans every line, it will flag use of risky APIs (e.g., file delete, net send, process fork) regardless of when they are being invoked at runtime.

Having said that, obfuscated code (e.g., base64 encoded) or runtime payloads (e.g., downloaded from pastebin) will not be analyzed with static analysis, but it will tell you if the recent package version uses base64 or exec APIs in the code (file/line) for you to take a deeper look. We've some ideas on runtime lightweight sandboxing, and will eventually implement those.

But how will we audit the auditor? taps head

This is a valid concern. That is why we're building this in the open. You can take a look at the code. We welcome your feedback/suggestions and code contributions to add new security checks/policies.

>That is why we're building this in the open. You can take a look at the code.

...You mean, in the same manner everyone should have been auditing code all along, but hasn't, thereby creating the problem you're trying to solve?

It's alright. You're trying, and there's nothing wrong with that answer, but the people you're trying to sell a shovel to don't want to dig. That's the chief problem.

> people you're trying to sell a shovel to don't want to dig.

That's exactly where a tool like Packj can help. It can cut the digging time down significantly. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out a "risky" behavior (file and line number). Using obfuscation to hide malicious code itself is a suspicious behavior, which is flagged. After all, we have to start somewhere.

You’re not wrong, but at some point, the dependency problem will slip onto someone’s desk in then legal department and rules will be pushed back across the hall into the engineering department.

It’s not a bad idea to stake out a product that’s mature and ready to go when that happens. It doesn’t even have to be foolproof. It just needs to be earnest enough to check off some boxes and show that “best practice” effort was made.

Ken Thompson’s Trusting Trust is very relevant.

> It sandboxes install-time scripts, including any native compliation. It uses strace (i.e., NO VM/Container required).

Is this tool unix-only or just the sandbox thing?

Nevermind, found the answer regarding PyPI install:

> Packj only works on Linux.

Yes, strace works on Linux. Mac has dtrace that we will integrate. Packj sandbox should, however, also work under WSL on Windows. May be someone can test and share contributions.

> Mac has dtrace that we will integrate.

But won't this require your target users turning off SIP [1] on Macs to enable dtrace? A lot of dtrace tools require SIP to be disabled before they can produce any meaningful output.

1: https://developer.apple.com/documentation/security/disabling...

AFAIK, SIP only blocks dtrace on system executables (i.e., that ship with Mac). But there are alternatives as well such as Endpoint security: https://developer.apple.com/documentation/endpointsecurity/

Reply on news.ycombinator.com