51–60 of 132 posts
Looks that it's not that easy unless the file is formatted in a special way:
https://stackoverflow.com/questions/410980/include-a-text-fi...
(sorry for the stack overflow link - my C/C+ is rusty to say politely)
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...
> Recently I saw a tweet where someone mentioned that you can include /dev/stdin in C code compiled with gcc. This is, to say the very least, surprising. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…
Famous last words.
On a related note, the XML standard defines a way to include external files in the document. If you come across a service which replies with a part of your request(e.g. validation errors) and uses XML parser with this feature turned on, which is true by default in many cases, this can be used to read arbitrary files. I wonder how many poorly maintained enterprise systems systems are vulnerable to that. https://www.ow…
Its less common now that most major parsers are turning this feature off by default though.
Earlier quoted context omitted.
This is true, but containers are so much better than nothing and relatively simple to use, so if someone isn't going to put in the effort for a more secure solution I'd rather they use Docker than nothing.
Are containers simpler to automate from a service provider's POV than, say KVM or qemu or Firecracker (or other VM tech)?
I was wondering if it there is a _practical_ attack that stores the content of a file into a string, char array, etc.. Looks that it's not that easy unless the file is formatted in a special way: https://stackoverflow.com/questions/410980/include-a-text-fi... (sorry for the stack overflow link - my C/C+ is rusty to say politely)
Earlier quoted context omitted.
Can you elaborate? Doesn't a KVM bug result in pretty much the same thing? Or is the argument that this is less likely?
The attack surface of a container is massive. The attack surface of a hypervisor is tiny, in comparison. There was 'interesting' research out of IBM a couple of years ago where they claimed they found that containers with good seccomp profiles etc were 'as secure as' a VM. Well, nobody goes around believing that. I recall once asking Joanna Rutkowska this same question, I think just days after she had outlined some p…
Earlier quoted context omitted.
Docker was not made for security, and this is explicitly documented in its manual. Also, you don't need VM, just playing with namespaces, chroots and syscall filters should be enough. VMs are very ineffective and complicated.
Funny you say the docker is not for security (it’s there in the manual) but then suggest chroot of all things — that is just as well documented as not being meant for security!
Compiling untrusted code is already a dangerous affair. Compilers are not audited for security vulnerabilities, and many versions of popular compilers have contained memory corruption bugs or similar issues that could be leveraged to gain code execution. Many services that compile untrusted code will run the resulting binaries too, which definitely requires a sandbox or disposable VM - at which point you may as well…
> Recently I saw a tweet where someone mentioned that you can include /dev/stdin in C code compiled with gcc. This is, to say the very least, surprising. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…
> That's quite a leap from 'I can read /etc/shadow' to 'I am root'. Of all the leaps in that post, that's the least leapy thing. `shadow` exists precisely so that only `root` can read its content, whereas before said content resided in `passwd` which _needs_ to be readable by all. I see only two possibilities here. Either the people who set up that compile service are complete morons and run said compile as actual ro…
In fact that's kinda the standard practice anyway nowadays (disallow logging in directly as root), so I'm really not sure what these guys are doing.