41–50 of 104 posts
You can try clearing environment variables before running a command: env -i And only set the ones you absolutely need.
I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of mali…
I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of mali…
Does this work at the system call level, where it would detect e.g. any attempt to open ~/.aws/credentials, or does it rely on heuristic analysis of the code itself, which will always be able to be "coded around" by the malware authors? The correct approach would seem to be to not run untrusted code in an environment where it can read your AWS credentials.
I imagine you'd want some kind of fuzzer with security-oriented tracing on top. I've never heard of such a tool, but I'd bet it exists somewhere.
Earlier quoted context omitted.
This is the kind of stuff that antiviruses did for ages, from signature, code simulation to heuristics. They have a lot of expertise in this, it feels like they could branch out in finding malware in source code, instead of in binaries.
Source code has issues with obfuscation methodologies that can defeat a lot of techniques. It’s why companies are trying to build more analysis down into the kernel such as via EBPF. For example, concatenating a series of strings and characters that wind up reading from .AWS/credentials in the end is surprisingly tough to catch based upon simple pattern recognition alone, especially if it’s done in a subtle way such…
In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user? I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. There's AppArmor, but the last time I tried it, I came away with the opinion that it's not very convenient or user-friendly. Per…
> I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. You can create users manually for each app. For GUI apps, https://firejail.wordpress.com/
In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user? I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. There's AppArmor, but the last time I tried it, I came away with the opinion that it's not very convenient or user-friendly. Per…
Earlier quoted context omitted.
Does this work at the system call level, where it would detect e.g. any attempt to open ~/.aws/credentials, or does it rely on heuristic analysis of the code itself, which will always be able to be "coded around" by the malware authors? The correct approach would seem to be to not run untrusted code in an environment where it can read your AWS credentials.
https://github.com/ossillate-inc/packj#how-it-works I imagine you'd want some kind of fuzzer with security-oriented tracing on top. I've never heard of such a tool, but I'd bet it exists somewhere.
For example, instead of writing
open('/etc/password')
method = calculateMethodName()
name = calculateEtcPassword()
geattr(__builtins__, method)(name)I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of mali…
Looks interesting, thanks. I'd like to see something like this but with a transparent proxy interface that you can point your package managers to so that you always in inspected and approved packages.
The point of that project is that you can create or use an existing repository proxies and attach to it what I called "audit policies" those are basically a list of packages/versions you want to block or allow. The default ones include for example malicious, vulnerable, yanked packages etc... (the blacklist repository) to which you point pip, poetry etc... and it will block installation of the packages listed in the audit policies attached to the repository. You can also create ad-hoc repositories or repository per project to keep it separate and operate in whitelist mode where you allow only whitelisted&audited packages.
On top of that there is also "monitor" mode where you can allow installation of any package or subsset of packages and it will capture all depedencies for purpose of tracking the software supply chain accross the company or project and those packages would be automatically scanned and audit using integration with another project of mine called Aura that is a static analysis scanner designed for the python supply chain.
As mentioned this is currently in open alpha mode so access is limited and user registration is not open (I am currently working on users&permissions for making their own repositories and audit policies) but if someone is interested in testing or this project in general or an early access to features behind the curtain feel free to shoot me an email at admin @ sourcecode.ai . The license is open source so it can be also self-hosted.
Earlier quoted context omitted.
> I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. You can create users manually for each app. For GUI apps, https://firejail.wordpress.com/
firejail is not limited to GUI apps, is it?
Earlier quoted context omitted.
https://github.com/ossillate-inc/packj#how-it-works I imagine you'd want some kind of fuzzer with security-oriented tracing on top. I've never heard of such a tool, but I'd bet it exists somewhere.
As I understand, they use static analysis. So the malicious code can be hidden by obfuscation. For example, instead of writing open('/etc/password') One can write method = calculateMethodName() name = calculateEtcPassword() geattr(__builtins__, method)(name)