191–200 of 255 posts
As a kid in the late 90s my mind was blown when I realized I could telnet to port 80, 25, or 110 and interact with the servers manually. Simple get: GET / HTTP/1.1 Content-Type: text/html User-Agent: l33t hax0rs lol X-Funny-Monkey: farts For sending a mail message on port 25: HELO mail-from: whoever@whatever.com mail-to: sysadmin@yaya.com Body of the message yay. POP3 was so long ago I forgot but you could list the m…
Isn't that the whole point of TCP? Creating a pair of two streams you can read out of and write to out of less reliable network primitives? I am not sure why this is a revelation. Any college level networking course would cover this?!
As an actual kid it's easy for it to be a revelation, no? At least it was for me, with no college level networking course experience.
shame it's not a real device so the surface is limited to bash only
I wonder what software might be vulnerable to this attack surface
Earlier quoted context omitted.
More than one ~500 employee company I've worked at has had security policies either encouraging or requiring the use of "distro-less" images - images with no OS components other than the absolute minimum required to run the application. For go binaries this meant literally nothing in the container apart from the executable. In theory it has a couple of benefits. You don't have to re-deploy your image to patch CVE's i…
> not having standard debugging tools available where and when we need them Keeping in mind that containers are merely a bunch of namespaces, there's nothing stopping you from entering the same PID namespace with a different mount namespace in order to debug.
To summarize, in my experience there is immense value to having basic shell tools available in the environment where you need them with zero extra friction. Stripping those out provides a security benefit only in specific nebulous and niche scenarios.
Earlier quoted context omitted.
> FROM scratch just reduces the surface. The actual attack surface of your application? Or the attack surface of you and your team's attention from a busybody security org. It's important not to confuse the two.
Both. Many attacks take the form of an exploit to get a shell, then using available utilities to exploit the kernel to escape to the host. If your image has neither a shell nor utilities that won't get very far.
Earlier quoted context omitted.
Isn't that the whole point of TCP? Creating a pair of two streams you can read out of and write to out of less reliable network primitives? I am not sure why this is a revelation. Any college level networking course would cover this?!
> Any college level networking course would cover this?! As an actual kid it's easy for it to be a revelation, no? At least it was for me, with no college level networking course experience.
I find /dev/udp much more useful. I can create aliases for fire and forget commands to my daemons without actually writing *ctl program.
Earlier quoted context omitted.
Both. Many attacks take the form of an exploit to get a shell, then using available utilities to exploit the kernel to escape to the host. If your image has neither a shell nor utilities that won't get very far.
What percentage of CVEs can be used to obtain a shell, but can't otherwise be used to obtain some other form of code execution in a distro-less container?