171–177 of 177 posts
Earlier quoted context omitted.
At that point, why not just boot the virtual machine with no network interface attached?
Malware anti detection: some will not launch without a network connection. The idea is to simulate a functional network but not provide access.
Earlier quoted context omitted.
Sure, that's basically what services like AWS Lambda do. As a starting point, you'd want to run the code in a short-lived VM with little to no network access which is dedicated to just running untrusted code.
This is a bad solution. Lambda allows arbitraty network access and may allow access to your AWS resources. If you have to do this, the best approach is to containerise it, use capabilities to enforce restrictions and run in a virtual machine as isolated as possible. It's still not great though. Some languages (eg Java) have additional features that help with this though.
Earlier quoted context omitted.
Just because something is useful doesn't mean it's not a hackjob. Just looks at how PHP got so popular. Clearly it was useful and thus became popular. I think it's hard to argue that it wasn't a hackjob when it first started.
JavaScript is a perfect instance
Earlier quoted context omitted.
Full disclosure, I wrote both of these. The following describes the entire unauthenticated attack: https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapi... And, if you like that sort of thing, there is a metasploit module you can use to reproduce the unauthenticated attack: https://github.com/rapid7/metasploit-framework/commit/6f4aa5...
> Specifically HandleFileUploads in uploads.go is called from a couple of PreAuthorizeHandler contexts allowing the HandleFileUploads logic, which calls down to rewrite.go and exif.go, to execute before authentication. I'm no security guy, but this seems... incredibly dumb? Like even for perfectly secure code, the asymmetry in resource usage alone to submit an image vs. get them to dump a file, shell out to a scanner…
My VOIP vendor, voip.ms, has been under attack for weeks. Wonder if this is the source?
Totally different. The attacks on VOIP vendors mostly used UDP amplification, which relies on having a server that can fake its source IP due to an incompetent (or complicit!) network provider, while this is a botnet (that is only about a week old).
Seems like one solution would be to require users uploading images to remove metadata themselves before uploading. The website could reject images that contain matadata. Was Gitlab was extracting the metadata and using it for some purpose. If not, what is the reason to accept images with metadata. Perhaps they assume their customers prefer less "security" and more "convenience", instead of vice versa (less "convenien…
How do you reject an image that has metadata without doing basically exactly the same process as removing the data?
Earlier quoted context omitted.
If you have to process it at all, do it in a WebAssembly sandbox on the server. Or, alternatively, in a seccomp-secured sandbox that isn't allowed to make any system calls whatsoever, just read data from one file descriptor and write processed data to another.
.... why webassembly?
- It's a separate interface with a different attack surface than your system, so compared to a locked-down version of the normal syscall API, it provides better defense-in-depth.
- It's designed to be a fully self-contained sandbox, by default. If you're locking down everything but reading and writing previously opened file descriptors, you can build a secure sandbox atop syscalls fairly easily. If you need more nuance than that, WebAssembly seems more likely to remain secure, while syscall sandboxes seem more likely to fail-insecure if you get a detail wrong.
- It seems easier to sandbox otherwise-unmodified code that way. If you have code that needs some access to system resources, I think WebAssembly makes it easier to give it just what it needs and nothing else.
(Also, note that I'm not talking about running in a browser; I'm talking about standalone WebAssembly runtimes like wasmtime.)