3 ms·
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 it
by jhugo 4y ago
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.
- lrem 4y agohttps://github.com/ossillate-inc/packj#how-it-works 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.
- codedokode 4y agoAs 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)
- rjh29 4y agoI guess you'd have to run it in a malware sandbox like Cuckoo.
- oblio 4y agoTurns out, stuff like Java's SecurityManager:https://docs.oracle.com/javase/7/docs/api/java/lang/SecurityManager.html https://docs.oracle.com/javase/7/docs/api/java/lang/Security... were there for a reason. Note, it's been around since JDK 1.0, so 1996, 28 years ago (!), though it's not widely used. But it allows sandboxing of libraries you use. I was using it to make a faulty library that was calling System.exit(0) - yes, a library that was shutting down the entire process, closing the main app... - not do that and instead wrap the exit in a regular exception. Python and especially Javascript are reinventing a lot of "enterprise" ideas that Java invented 20+ years ago. Maven groupIds are another example from the Java ecosystem (they're used to avoid top level package name squatting).
- makmanalp 4y agoYou are of course correct that those features are extremely useful and that the JDK authors foresaw these situations long before they were a big deal. But also you do note that it's not widely used which is also correct and that's the important bit. I think it would be more accurate to say that python and javascript are discovering (perhaps not fully intentionally) ways to implement these ideas that are suitable for mass community adoption. IMHO it's like the difference between basic research (mostly not very useful on its own but extremely important) and public health in medicine (the thing that actually makes a massive impact on the world that leverages the former but at a slower and more controlled pace). To stretch the analogy even more any doctor worth their salt will tell you that a treatment plan is only as good as the likelihood that the patient will stick to it. Other things like let's encrypt (https everywhere) and signal/whatsapp/telegram (strong privacy enabled by default) come to mind as implementing ideas on things that experts had been handwringing for decades that people "should" be doing that are now done so well that it feels almost silly not to do them the good way.
- unnah 4y agoThe Java Security Manager was not very effective in practice. It was already deprecated in Java 17 and will be removed in the future: https://openjdk.org/jeps/411 https://openjdk.org/jeps/411
- oblio 4y agoI understand their reasoning but it's still kind of sad that there's no replacement planned. It would be cool if there was a universal access control platform, but I guess the best we're getting is Docker, because such a platform would commoditize OSes, which OS creators for sure don't want :-(
- monkeybutton 4y agoFrom an organizational standpoint its better because it lets a sysadmin/security person sandbox anything and everything instead of having to become proficient with the tooling for every different language (which may not even exist).
- ashishbijlani 4y agoYes, we are incorporating strace-based dynamic analysis (containerized) to collect system calls. However, Packj can currently flag use of getattr() API as it is equivalent to "runtime code generation" [1]; a developer can go and take a deeper look then. 1. https://github.com/ossillate-inc/packj/blob/main/main.py#L476 https://github.com/ossillate-inc/packj/blob/main/main.py#L47...
- deleted 4y ago[deleted]
- ashishbijlani 4y agoPackj currently uses static code analysis to derive permissions (e.g., file/network accesses). Therefore, it can detect open() calls if used by the malware directly (e.g., not obfuscated in a base64 encoded string). But, Packj can also point out such base64 decode calls. Fortunately, malware has to use these APIs (read, open, decode, eval, etc.) for their functionality -- there's no getting around. Having said that, a sophisticated malware can hide itself better, so dynamic analysis as you suggested must be performed for completeness. We are incorporating strace-based dynamic analysis (containerized) to collect system calls.