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.
Only if I directly base off my image from Alpine. All images that base off something that either directly bases off Alpine (or worse, with more intermediaries) have a problem as ALL images in the chain must be rebuilt.
That is the core problem.
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.
You make it sound like it was a bad thing. It's not.
How can a server running Docker rebuild itself a new image and deploy it? Without your intervention. With cron?
Reminds me, I actually could automate this using Jenkins, it has an interface to Marathon (which backs DC/OS)...
> 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".
If you can not arbitrarily compute on the target machine ASLR is still completely useful. This is the case for tons of vulnerabilities, like basically anything that isn't a web browser with JS execution privileges.
