Docker Shocker | TechSNAP 167

Docker Shocker | TechSNAP 167

An exploit that leaves Docker containers leaky, who really owns your email account and one hash algorithm to rule them all.

Then it’s a great batch of your questions and much, much more!

Thanks to:




Direct Download:

HD Video | Mobile Video | MP3 Audio | Ogg Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feeds | Torrent Feed

— Show Notes: —

Docker Linux containers spring a security leak

  • A security exploit has surfaced that can allow rogue programs to break out of Docker containers and access files on their host OS.
  • The flaw has been solved in the latest version of the tech.
  • The flaw \”Demonstrates that any given Docker image someone is asking you to run in your Docker setup can access ANY file on your host, e.g. dumping hosts /etc/shadow or other sensitive info, compromising security of the host and any other docker container is on\”
  • \”The proof of concept exploit relies on a kernel capability that allows a process to open any file in the host based on its inode. On most systems, the inode of the / (root) filesystem is 2. With this information and the kernel capability it is possible to walk the host’s filesystem tree until you find the object you wish to open and then extract sensitive information like passwords,\” Docker explained in a blog post published after the flaw came out.
  • \”In earlier Docker Engine releases (pre-Docker Engine 0.12) we dropped a specific list of kernel capabilities, ( a list which did not include this capability), and all other kernel capabilities were available to Docker containers. In Docker Engine 0.12 (and continuing in Docker Engine 1.0) we drop all kernel capabilities by default. Essentially, this changes our use of kernel capabilities from a blacklist to a whitelist.\”
  • \”Please remember, however, that at this time we don\’t claim that Docker Engine out-of-the-box is suitable for containing untrusted programs with root privileges,\”
  • Proof of Concept exploit prints /etc/shadow from the host from within Docker

Generalized Secure Hashing Algorithm

  • Ted Unangst (one of the lead developers of LibreSSL, as well as OpenBSDs secure signing infrastructure and many other things) posted a thought experiment to his blog
  • How would you design an uncrackable password hashing algorithm?
  • Ted’s idea: create a very large number of unique hashing algorithms, or rather, a generalized hashing algorithm that takes a ‘tweaking’ parameters that changes how the hash is generated
  • “Consider a hash function GSHA512, very similar to SHA512, but with slight variations on each of its constants. You could use GSHA512 #42, or GSHA512 #98765, or even GSHA512 #658743092112345678890 if there were enough variants available. 2^512 variants should be enough for anyone.”
  • Now, instead of having to spend a few million on specialized SHA512 cracking hardware, an attacker (the NSA) would have to build 2^512 different specialized cracking chips
  • The results?
  • “Safe to say we’ve defeated custom silicon. Nobody has a fab that can trace out millions of distinct custom circuits per second.”
  • “FPGA is finished too. Assuming you don’t melt it trying, you can’t reprogram an FPGA fast enough.”
  • “GPUs are harder. Without having tried it, my gut tells me you won’t be able to copy out the GSHA code to the GPU fast enough to make it worthwhile.”
    • “An attacker with lots of CPUs can still crack our password, but CPUs are very expensive. What if somebody could fab their own very cheap, very limited CPUs? Like a 100000 core CPU with only just enough cache to implement GSHA? Now we may be in trouble. The transistor count for GSHA is quite low, but they need to be the special high speed general purpose kind of transistor circuit. The scrypt paper notes that a CPU could be cheaper than RAM if stripped of all its extra functionality, but in practice it’s hard to calculate all the tradeoffs.”
    • “This part isn’t very practical The idea is that a cracker would look less like a SHA512 cracker, capable only of performing one hash, and more like a typical CPU, capable of performing many hashes. Requiring the attacker to be adaptable in this way brings their costs in line with our costs. Maybe. Waves hands.”
  • Of course, to defeat custom CPUs, one could just use GSHA512 as the core to something like scrypt, which tries to defeat customer hardware by requiring a lot of memory instead
  • Example Implementation
  • “Don’t use these functions for anything but password hashing. (Don’t use them at all is even sounder advice.)”

Who owns your email account?

  • A user had their Yahoo email account terminated by Yahoo for violation of its terms of service
  • The violation was apparently for flaming another user in the comments thread under Yahoo news articles
  • Since the email address is part of the overall ‘Yahoo Account’, it was terminated
  • Eric Goldman, law professor at Santa Clara University says: \”A cloud service can lock off your assets,\” he adds. \”They may still be your assets from a matter of legal ownership, but if you have no access to them, who cares?\” (Possession is 9/10th of the law?)
  • Microsoft and Google have similar terms, although Google adds: \”If we discontinue a Service, where reasonably possible, we will give you reasonable advance notice and a chance to get information out of that Service\”
  • This is why it is probably best to always use your own domain, that you own it
  • Even if you use gmail or some other service to actually host the mail, if your gmail account gets terminated, you can move your hosting elsewhere and most importantly, your email address does not change
  • There is also the option to host your own email, with a hosting account, VPS or dedicated server
  • In these cases, especially when you do not have multiple servers to provide backup MX, I recommend a service such as: DNSMadeEasy Backup Email Service


Round Up:

Question? Comments? Contact us here!