5 ms·

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

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 https://github.com/ossillate-inc/packj

booi 4y ago
But how will we audit the auditor? taps head
- ashishbijlani 4y ago
  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.
  - salawat 4y ago
    >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.
    - swatcoder 4y ago
      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.
    - ashishbijlani 4y ago
      > 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.
    - i_love_cookies 4y ago
      [dead]
- profile53 4y ago
  Ken Thompson’s Trusting Trust is very relevant.
koolba 4y ago
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).
- ashishbijlani 4y ago
  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.
jve 4y ago
> 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.
- ashishbijlani 4y ago
  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.
  - ayewo 4y ago
    > 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_and_enabling_system_integrity_protection https://developer.apple.com/documentation/security/disabling...
    - ashishbijlani 4y ago
      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/ https://developer.apple.com/documentation/endpointsecurity/

booi 4y ago

But how will we audit the auditor? taps head

ashishbijlani 4y ago
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.
- salawat 4y ago
  >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.
  - swatcoder 4y ago
    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.
  - ashishbijlani 4y ago
    > 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.
  - i_love_cookies 4y ago
    [dead]
profile53 4y ago
Ken Thompson’s Trusting Trust is very relevant.

koolba 4y ago

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).

ashishbijlani 4y ago
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.

jve 4y ago

> 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.

ashishbijlani 4y ago
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.
- ayewo 4y ago
  > 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_and_enabling_system_integrity_protection https://developer.apple.com/documentation/security/disabling...
  - ashishbijlani 4y ago
    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/ https://developer.apple.com/documentation/endpointsecurity/