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

91–100 of 132 posts

Re: #include </etc/shadow>

#91

Post by soraminazuki »

willvarfar wrote: post #26
anonymousDan wrote: post #24

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…

> 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 actually did is to create a hypervisor-like narrow interface on top of containers by restricting the available system calls to closely resemble KVM's hypercall interface. This design allowed the authors to reduce the size of the trusted computing base while avoiding overheads associated with VMs, though it would also limit the ability to run unmodified Linux binaries. Overall, I found it to be an interesting alternative to containers or VMs.

Re: #include </etc/shadow>

#92

Post by fghtr »

rbanffy wrote: post #68
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).

There are many ways a hostile program inside a VM can escape it and run code on the host or, at least, negatively affect it.

Not many if its Qubes OS.

Re: #include </etc/shadow>

#93

Post by jacquesm »

softwarelimits wrote: post #83
jacquesm wrote: post #75

Earlier quoted context omitted.

At your service: https://www.techrepublic.com/article/vm-escape-flaw-in-qemu-...

Did you try this on an up2date Linux OS, like eg Debian or Ubuntu? What was your result? Certainly as a real hacker you are not only re-posting "things from the news" but validate everything before posting any comments? Are you? I did not see any relevant content on the websites you mention in your HN profile, I expected some in-depth security publications - maybe update it with some real code that shows us how you a…

> I did not see any relevant content on the websites you mention in your HN profile

At least I have a filled out profile, unlike you.

Besides that, and the cheap personal attacks, you seem to be completely missing the point so let me spell it out for you: VMs, containers, chroot jails and all those other tools with which we can try to isolate two pieces of software running on the same hardware all have exploits, past, current and future ones. Any piece of software of even moderate complexity will have bugs, any isolation method should be considered fallible and leaky and you best defenses will take that into consideration when architecting your setup.

If you don't then sooner or later someone with more patience, a larger budget or more knowledge than you will get the better of you with all the consequences that may have.

Re: #include </etc/shadow>

#94

Post by ajor »

fwsgonzo wrote: post #85
shawabawa3 wrote: post #71

Earlier quoted context omitted.

You aren't stripping slashes. I tried `#include ` and it eventually crashes the container failing to allocate memory (looks like they have a 4GB limit?)

Haha, that's clever. Yes, it's a 4GB limit. Guess I'll try to fix that again. EDIT: fixed

Still some workarounds to the slash-stripping:

  #include "\
  /etc/passwd"

  program221/code.cpp:1:11: warning: backslash-newline at end of file
      1 | #include "\
        |            
  In file included from program221/code.cpp:2:
  /etc/passwd:1:5: error: found ':' in nested-name-specifier, expected '::'
      1 | root:x:0:0:root:/root:/bin/bash
        |     ^
        |     ::
  /etc/passwd:1:1: error: 'root' does not name a type
      1 | root:x:0:0:root:/root:/bin/bash
        | ^~~~
Is it possible to restrict the compiler's access to only files in "/usr/include" instead? Seems like it'd be hard to cover every case with just pattern matching.

Re: #include </etc/shadow>

#95

Post by fwsgonzo »

ajor wrote: post #94
fwsgonzo wrote: post #85

Earlier quoted context omitted.

Haha, that's clever. Yes, it's a 4GB limit. Guess I'll try to fix that again. EDIT: fixed

Still some workarounds to the slash-stripping: #include "\ /etc/passwd" program221/code.cpp:1:11: warning: backslash-newline at end of file 1 | #include "\ | In file included from program221/code.cpp:2: /etc/passwd:1:5: error: found ':' in nested-name-specifier, expected '::' 1 | root:x:0:0:root:/root:/bin/bash | ^ | :: /etc/passwd:1:1: error: 'root' does not name a type 1 | root:x:0:0:root:/root:/bin/bash | ^~~~ Is…

It would be awesome if you could place restrictions on the compiler, but I don't know of any such features atm. Still, the compilation happens in the container (which is just a default Ubuntu image with a cross compiler in it). I don't know how much information there is to disclose. Not taking it lightly though, I guess I will have to find a way to really handle the preprocessor stuff, but I still want people to be able to include system headers.

Re: #include </etc/shadow>

#96

Post by blattimwind »

ajor wrote: post #94
fwsgonzo wrote: post #85

Earlier quoted context omitted.

Haha, that's clever. Yes, it's a 4GB limit. Guess I'll try to fix that again. EDIT: fixed

Still some workarounds to the slash-stripping: #include "\ /etc/passwd" program221/code.cpp:1:11: warning: backslash-newline at end of file 1 | #include "\ | In file included from program221/code.cpp:2: /etc/passwd:1:5: error: found ':' in nested-name-specifier, expected '::' 1 | root:x:0:0:root:/root:/bin/bash | ^ | :: /etc/passwd:1:1: error: 'root' does not name a type 1 | root:x:0:0:root:/root:/bin/bash | ^~~~ Is…

> Is it possible to restrict the compiler's access to only files in "/usr/include" instead? Seems like it'd be hard to cover every case with just pattern matching.

chroot into a build environment

Re: #include </etc/shadow>

#97

Post by zer0t3ch »

londons_explore wrote: post #65
himinlomax wrote: post #49

Earlier quoted context omitted.

> 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…

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.

Re: #include </etc/shadow>

#98

Post by softwarelimits »

VBprogrammer wrote: post #86
softwarelimits wrote: post #83

Earlier quoted context omitted.

Did you try this on an up2date Linux OS, like eg Debian or Ubuntu? What was your result? Certainly as a real hacker you are not only re-posting "things from the news" but validate everything before posting any comments? Are you? I did not see any relevant content on the websites you mention in your HN profile, I expected some in-depth security publications - maybe update it with some real code that shows us how you a…

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 news discussion site.

Re: #include </etc/shadow>

#99

Post by sherincall »

ajor wrote: post #94
fwsgonzo wrote: post #85

Earlier quoted context omitted.

Haha, that's clever. Yes, it's a 4GB limit. Guess I'll try to fix that again. EDIT: fixed

Still some workarounds to the slash-stripping: #include "\ /etc/passwd" program221/code.cpp:1:11: warning: backslash-newline at end of file 1 | #include "\ | In file included from program221/code.cpp:2: /etc/passwd:1:5: error: found ':' in nested-name-specifier, expected '::' 1 | root:x:0:0:root:/root:/bin/bash | ^ | :: /etc/passwd:1:1: error: 'root' does not name a type 1 | root:x:0:0:root:/root:/bin/bash | ^~~~ Is…

You can LD_PRELOAD an .so that overrides `open` and family of functions, and drop opens based on a whitelist/blacklist.

Re: #include </etc/shadow>

#100

Post by boop-the-snoot »

softwarelimits wrote: post #82
zonidjan wrote: post #39

> 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…

If that was my server I would of course put a joke in /etc/shadow - did you try to brute force the hashes? It would not be a great surprise to find some obvious funny content if you try?

That'd be pretty funny :D

Like for example, if the entry for root in the joke /etc/shadow was the hash of "Thank you Mario! But our princess is in another castle!"

Post reply on HN