ashishbijlani

Would love to know the specifics I'm missing. Based on my experience, Docker/FC just works out of the box and gives you a shell.

> There's Firecracker, which I believe is secure (AWS built it for Lambda after all) but good luck figuring out how to run that on a Mac.

Then, how about using AWS Lambda for your use case?

Curious to know why existing sandboxing/isolation technologies like VMs & Containers not enough here?

Interesting. I wonder if this is also true for available/existing commercial/open-source PyPI mirroring solutions [Edited].

A high-latency network will certainly become the bottleneck, but ONLY for file reads/writes. Metadata attributes (e.g., symlinks, dentries, inodes) are maintained by the file system (FUSE). Caching them in the kernel with ExtFUSE will yield faster metadata ops (e.g., lookups).

FUSE does not work well with a large number of small files (due to high metadata ops such as inode/dentry lookups).

ExtFUSE (optimized FUSE with eBPF) [1] can offer you much higher performance. It caches metadata in the kernel to avoid lookups in user space. Disclaimer: I built it.

1. https://github.com/extfuse/extfuse

This is something we have noticed as well in our supply-chain security analysis of Github repos. It could be "build it in the open" philosophy as well that offers complete transparency and security audibility.

We’ve built an open-source tool, called Packj [1], to offer developers more insights into packages, such as risky install hooks, embedded binary blobs, and other malicious/risky packages. It performs static/dynamic/metadata analysis to look for "suspicious” attributes.

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

Plug: I've been building Packj [1] to detect dummy, malicious, abandoned, typo-squatting, and other "risky" packages. It carries out static/dynamic/metadata analysis and scans for 40+ attributes such as num funcs/files, 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, etc. to flag risky packages.

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

We carried out a similar analysis using Packj tool [1] and found that a large number of repos are vulnerable to supply-chain attacks. We received a bunch of bounties for reporting vulnerabilities. Hopefully, these findings will bolster open-source security.

1. http://github.com/ossillate-inc/packj flags vulnerable/malicious NPM/PyPI/Rubygems/Cargo/Packagist packages. I'm the lead dev.

Packj [1] flags malicious/risky NPM/PyPI/RubyGems packages by carrying out static analysis and looking for capabilities/permissions (diff from runtime permission enforcement). Supporting VSCode/browser extensions is on our roadmap.

Disclaimer: I'm the lead developer.

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

This is a great idea! What have been your findings comparing packaged code vs repo code? If you're interested, I'd love to integrate this in Packj tool.

1. http://github.com/ossillate-inc/packj flags vulnerable/malicious NPM/PyPI/Rubygems packages.

The project is active (just not merged in the kernel yet). Please DM me for questions.

I'm working on optimizing FUSE using eBPF (ExtFUSE [1]) and adding a caching layer exactly as you mentioned. Will post publicly when ready.

1. https://github.com/extfuse/extfuse

I built Packj [1] sandboxing for securing “pip/NPM install”. It uses strace for sandboxing and blocks access to sensitive files and limits traffic to known-good IP addresses.

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

Great work! This provenance check is going to be very valuable for enforcing supply-chain security. We are working on adding support to check for provenance in Packj.

1. https://github.com/ossillate-inc/packj flags risky/malicious NPM/PyPI/Ruby dependencies

Cool project. Would love to integrate this in Packj [1] as one of the open-source SAST scanners. Will DM you.

1. https://github.com/ossillate-inc/packj flags malicious/risky open-source dependencies.

Plug: I've been building Packj [1] to detect dummy, malicious, abandoned, typo-squatting, and other "risky" packages. It carries out static/dynamic/metadata analysis and scans for 40+ attributes such as num funcs/files, 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, etc. to flag risky packages.

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

We've made it highly customizable [1]. For some folks, a package that has not been updated for a while could be classified as abandonware. You can turn off the alerts that do not apply to you by commenting out in .packj.yaml file.

We're working on making it similar to email spam. Will post more soon. Meanwhile, we welcome changes that can make it less noisy for the community.

[Edit:] one can specify Github API token to get around rate limiting. We'd deeply appreciate if could create an issue for this on the repo.

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

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/

A number of academic researchers (including us) have studied malware samples from past open-source supply chain attacks and identified code/metadata attributes that make packages vulnerable to such attacks. Packj scans for several such attributes to identify insecure or "weak links" in your software supply chain (e.g., missing or incorrect GitHub repo, very high version number, use of decode+exec, etc.). Full list here: https://github.com/ossillate-inc/packj/blob/main/packj/audit...

We’ve built Packj [1] to detect packages with install hooks, embedded binary blobs, and other such malicious/risky packages. It performs static/dynamic/metadata analysis to look for "suspicious” attributes.

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

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.

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.

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

The problem with using downloads as a proxy for "safety" is that a bad actor can use CI infra/bots/scripts to inflate the number. This is why in Packj [1] we check for multiple attributes (e.g., dependents).

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

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.

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

"This site is blocked due to a security threat that was discovered by the Cisco Umbrella security researchers."

Thanks for posting this! I'm the lead developer. I've been building Packj to empower developers/security engineers to easily audit third-party open-source dependencies for supply chain attacks. Please allow me to highlight a couple of important aspects of the technology:

- It analyzes Python/NPM/Rubygems packages for several risky code and attributes such as Network/File permissions, expired email domains, data exfiltration, mismatching repo code vs packaged code (provenance)

- Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out if a package accesses sensitive files (e.g., SSH keys), spawns shell, sends telemetry info, is abandoned, lacks 2FA, etc.

- It can be customized to your threat model by commenting out alerts that don't apply.

- We found a bunch of malicious packages on PyPI using the tool, which have now been taken down; a few are listed here https://packj.dev/malware