Exploiting Alpine Linux
twistlock.com
Exploiting Alpine Linux
1–10 of 25 posts
Re: Exploiting Alpine Linux
#2[deleted]
Re: Exploiting Alpine Linux
#3I was looking forward to reading this article (it's the second part) to see how the author would bypass aslr but they just disable it (running under gdb) so in the wild their method would not work.
Re: Exploiting Alpine Linux
#4Stuff like this is why I base my docker images off Ubuntu or Debian and regularly rebuild them. This way I always get the security updates from Debian/Ubuntu.
The problem with all images which base on something that is not an official distro image is that these packages always have to depend on the base image author to regularly update the images. There is no such thing as apt-get upgrade in a docker only environment, and I'm not really looking forward to the next Apache RCE vuln or the next Openssl desaster. People with long-running containers will be hit hard.
Re: Exploiting Alpine Linux
#5Stuff like this is why I base my docker images off Ubuntu or Debian and regularly rebuild them. This way I always get the security updates from Debian/Ubuntu. The problem with all images which base on something that is not an official distro image is that these packages always have to depend on the base image author to regularly update the images. There is no such thing as apt-get upgrade in a docker only environment…
Your best bet is really to build your base image using debootstrap or similar. The 'official' images are often a joke. For the longest time, the maintainer of the 'official' Ubuntu image had no clear association with either Docker Inc or Canonical.
edit: To clarify, the images themselves are quality, and do get generated from Canonical's rootfs tarball, but the trust path for a huge chunk of binary data now hinges on a single individual, rather than a corporate entity.
Re: Exploiting Alpine Linux
#6I was looking forward to reading this article (it's the second part) to see how the author would bypass aslr but they just disable it (running under gdb) so in the wild their method would not work.
This seems to be a common practice in documenting exploits -- to purposefully leave out details that would make it able to cause actual damage in the wild.
Re: Exploiting Alpine Linux
#7Stuff like this is why I base my docker images off Ubuntu or Debian and regularly rebuild them. This way I always get the security updates from Debian/Ubuntu. The problem with all images which base on something that is not an official distro image is that these packages always have to depend on the base image author to regularly update the images. There is no such thing as apt-get upgrade in a docker only environment…
Your best bet is really to build your base image using debootstrap or similar. The 'official' images are often a joke. For the longest time, the maintainer of the 'official' Ubuntu image had no clear association with either Docker Inc or Canonical. edit: To clarify, the images themselves are quality, and do get generated from Canonical's rootfs tarball, but the trust path for a huge chunk of binary data now hinges on…
> the trust path for a huge chunk of binary data now hinges on a single individual, rather than a corporate entity.
You make it sound like it was a bad thing. It's not.
Re: Exploiting Alpine Linux
#8I was looking forward to reading this article (it's the second part) to see how the author would bypass aslr but they just disable it (running under gdb) so in the wild their method would not work.
ASLR has been thoroughly broken through cache and memory subsystem timing attacks. It seems reasonable to leave breaking ASLR as an exercise for the reader in order to focus more on the core vulnerabilities being discussed.
> It is worth noting that for the sake of this exploit I assumed the attacker has knowledge of the memory layout of the executed program(3)
This is not the same as saying "this cannot be exploited with ASLR".
Re: Exploiting Alpine Linux
#9Earlier quoted context omitted.
Your best bet is really to build your base image using debootstrap or similar. The 'official' images are often a joke. For the longest time, the maintainer of the 'official' Ubuntu image had no clear association with either Docker Inc or Canonical. edit: To clarify, the images themselves are quality, and do get generated from Canonical's rootfs tarball, but the trust path for a huge chunk of binary data now hinges on…
> the trust path for a huge chunk of binary data now hinges on a single individual, rather than a corporate entity. You make it sound like it was a bad thing. It's not.
I'd trust Canonical for Ubuntu images over a random internet citizen that decided to provide them.
Re: Exploiting Alpine Linux
#10Earlier quoted context omitted.
Your best bet is really to build your base image using debootstrap or similar. The 'official' images are often a joke. For the longest time, the maintainer of the 'official' Ubuntu image had no clear association with either Docker Inc or Canonical. edit: To clarify, the images themselves are quality, and do get generated from Canonical's rootfs tarball, but the trust path for a huge chunk of binary data now hinges on…
> the trust path for a huge chunk of binary data now hinges on a single individual, rather than a corporate entity. You make it sound like it was a bad thing. It's not.
It is definitely a bad thing from a risk standpoint, no two ways about it. Simply because that person could get hit by a bus, burn out, etc.