261–270 of 334 posts
Earlier quoted context omitted.
So did it seem like some kind of weird scam, or what?
Presumably it's to trick whitehats into tipping off the hackers that their code was being analysed and had been successfully deobfuscated, so the hackers knew they needed to move to a different attack. It's actually quite devious, like a reverse honeypot that the bad guys use against the good guys, exploiting their empathy.
Earlier quoted context omitted.
Could you please share some resources/tactics for protecting your host machine from these development VMs? If I were to do this, I would want some assurances (never 100%) that my host is protected from the VM to the best of my ability. (If it makes any difference, I would probably be using VMWare Workstation Pro)
I can't give you what you're looking for. You need to decide on the trade offs for yourself. There will always be a risk. Directed attacks can get out of VMs. You could slip up and log into a personal account inside the VM.
Earlier quoted context omitted.
Your dev machine getting pwned is bad, but your CI server getting screwed up is worse. This way you don't need to sandbox the compiler, and it can freely use system resources and access source trees. You only need to sandbox the execution. (As some people point out in this thread, editors are starting to use compilers to get overall meta-information, too-- if you can't even -view the code- to tell if it's malicious w…
> This way you don't need to sandbox the compiler, and it can freely use system resources and access source trees. You only need to sandbox the execution. If this is now only helping CI and not dev machines I don't see why it's worth the effort. Wouldn't it be much simpler and more reliable to just sandbox compilation of anything in your CI? > if you can't even -view the code- to tell if it's malicious without gettin…
Not really. The compiler has to be able to access large swaths of your code. You want to e.g. keep your code safe. You would have to have very finely-grained sandboxing to prevent substantive disclosure, and even then you're likely leaking information.
Or about 190 downloads per package, and who knows how many of those are actually real downloads by victims.
This is basically a non-issue; a few fools downloaded random code from the internet and ran it on their computer and, hopefully, learned a lesson. Shock and horror!
Would it be possible to make a more trusted package mirror? Somehow validating packages before inclusion? IIRC mirrors for NPM, Packagist and others is not impossible, can be done for PyPY and others too? Maybe it's a stop-gap before all the fancy permissions feature build out (which seems hard)
This type of stuff is one reason I like vendoring all my deps in golang. You have to be very explicit about updating dependencies, which can be a big hassle, but you're required to do a git commit of all the changes, which gives you a good time to actually browse through the diffs. If you update dependencies incrementally, it's not even that big a job. Of course, this doesn't guarantee I won't miss any malicious code…
I don't think you really gain much either; vendoring was useful before modules, but now we have modules and go.sum I don't really see the advantage. If you have "github.com/foo/bar" specified at version 1.0.4 the go.sum will ensure you have EXACTLY that version or it will issue an error in case of any tomfoolery.
In a previous HN discussion on the topic of rogue Python packages, readers had suggested bubblewrap and firejail for sandboxing. They limit the access a script and its packages have to your filesystem and network. I think that's the better approach - just assume all packages are malicious by default. Can't rely on scanners because of the large number of packages and attacks.
In a previous HN discussion on the topic of rogue Python packages, readers had suggested bubblewrap and firejail for sandboxing. They limit the access a script and its packages have to your filesystem and network. I think that's the better approach - just assume all packages are malicious by default. Can't rely on scanners because of the large number of packages and attacks.
Another good option is to create a new user and run everything under the new UID. Running under a new UID has less chances of accidentally leaving something exposed that can allow for sandbox escape. If you run everything from the new UID, it will mostly be contained to it's own $HOME directory and be unable to modify your user's files or system files. Some distros do not protect home directories from being read so i…
Is there no way to safely run graphical applications in a bwrap sandbox? I thought Wayland was supposed to be better about this.
I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…
This type of stuff is one reason I like vendoring all my deps in golang. You have to be very explicit about updating dependencies, which can be a big hassle, but you're required to do a git commit of all the changes, which gives you a good time to actually browse through the diffs. If you update dependencies incrementally, it's not even that big a job. Of course, this doesn't guarantee I won't miss any malicious code…
> And why is nodejs so much more dependency-happy than python? Part of it—but I'm sure not all—is that the core language was really, really bad for decades. Between people importing (competing! So you could end up with several in the same project, via other imports! And then multiples of the same package at different versions!) packages to try to make the language tolerable and polyfills to try to make targeting the…