Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

news.ycombinator.com

Post reply on HN
Print view View original

241–250 of 269 posts

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#241

Post by tomc1985 »

AsyncAwait wrote: post #210
craftoman wrote: post #163

Earlier quoted context omitted.

Yeah just like Mint one of the most popular Linux distro where you had a preinstalled malmware on your ISO because servers got hacked. Should I mention the ultra critical vulnerability of apt that was discovered few months ago or that apt doesn't use https, cuase it designed to work with http only in the first place.

Not sure about apt, but this is solvable. Arch's pacman supports https and package signing and only packages signed by trusted maintainers will get installed. That means it should be fairly difficult to swap legit packages for malicious ones and them getting installed. Not impossible, nothing ever is, but fairly difficult.

APT does https and multiple flavors of signing, the repo maintainer just has to use it

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#242

Post by kbirkeland »

gtsteve wrote: post #169
toxik wrote: post #137

Earlier quoted context omitted.

A checksum’s typical use is to detect transmission errors. A cryptographically secure signature is what’s needed.

It uses SHA-256 right? My understanding is that there isn't yet a workable collision attack on the SHA-2 family. Regardless, I think it's certainly an excellent hardening step.

A hash only provides integrity. A signature provides integirty and authentication.

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#243

Post by joveian »

jhasse wrote: post #155
Robin_Message wrote: post #152

Earlier quoted context omitted.

You can tamper with data protected by checksums: they are not designed to be irreversible, just fast to calculate and good at detecting errors, not deliberate manipulations. Use proper cryptography and don't roll your own!

Wouldn't that mean you need to find a collision?

Second preimage mostly, which is harder than collision with most common algorithms (even MD5 might still be secure for this, not that anyone should use it for anything at this point). Collision resistance is only important if someone can create two versions at the same time that have the same hash and wants to quietly switch them later.

Using SHA-256 as you describe works well and is widely used by package systems to ensure that source code being built does not change. Signatures can be better for determining if the initial image is valid if the signing is done away from the distribution infrastructure since development machines might be more secure than distribution infrastructure (and if not you will have problems either way). You still need to get the correct public key to start with. However, if you do have a good image by luck or actually secure enough distribution infrastructure then SHA-256 will certainly let you know that you get the same one later. Signatures almost always sign a cryptographic hash of the message and not the message itself.

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#245

Post by orisho »

jhasse wrote: post #171
orisho wrote: post #168

Earlier quoted context omitted.

I think his point is that for some checksums it could be trivial (and for some, tools already exist). Checksums aren't designed for this, while on the other hand secure hashing is. As a result, authors of hashing algorithms often attempt to mathematically prove their strength and resistance to a collision.

Docker uses SHA256 though, for which it isn't trivial.

Yes. The previous comments were about checksums, which SHA256 is not.

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#246

Post by ownagefool »

cyphar wrote: post #158
Polyisoprene wrote: post #150

Earlier quoted context omitted.

You can pull an image using the sha: docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

Which effectively nobody does. Package managers and distribution packaging systems default to the safe method rather then defaulting to insecure rewritable tags. To be fair, the docker.io/library/* images are signed but no other images are and there are a bunch of issues with how the signing policies work for users that want to enforce that some images must be signed.

It's a bit of a pain, you need to build, push, pull, then get the sha. I suspect it would be done more if there was actually a decent UX for it.

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#247

Post by lskillen »

netsectoday wrote: post #233
lskillen wrote: post #174

Earlier quoted context omitted.

As others have stated you could run your own registry or use an alternative service for private repositories, to minimise or eliminate the attack vector. By replicating the images (or packages) that you need into your own account, you can minimise the possibility of a bad actor replacing a well-known image with something untrusted. An alternative is to side-cart a service like Notary ( https://docs.docker.com/notary/…

You can run your own private Docker registry but you will still depend upon the base images pulled from hub.docker.com in your deploy chain unless you make sure to clone the base image Dockerfile from github and build it yourself. Even with this protected setup; you still have exposure from poisoned Github repos after this attack because of the compromised Github access keys. I'm not sure you can eliminate this threa…

It might be OK for the Docker Hub aspect at least, with a caveat later on; the GitHub aspect is unfortunate and I completely agree. Direct access to source is rather dangerous territory.

Back to the images bit first:

Base images are only referenced/pulled at build time. So if you've already built your own image and stored it, it'll contain all of the layers necessary to run it without explicitly pulling from Docker Hub.

In the case that you're building new images (likely), it'll need to pull the base images from Docker Hub. However, if you pull the base image(s) from Docker Hub first, you can tag them and store them in your local (or hosted) registry, then refer to those explicitly instead.

For example (using a Cloudsmith hosted registry):

  docker pull alpine:3.8
  docker tag alpine:3.8 docker.cloudsmith.io/your-account/your-repo/alpine:3.8
  docker push docker.cloudsmith.io/your-account/your-repo/alpine:3.8
Now, instead of the usual FROM directive:

  FROM alpine:3.8
You can refer to your own copy of alpine:

  FROM docker.cloudsmith.io/your-account/your-repo/alpine:3.8
As you can see Docker's syntax doesn't make this extremely pleasant, and you'll have to change existing Dockerfiles to point at the base images, but it's certainly possible to mirror your dependencies without rebuilding.

Caveat: The downside is that you have to trust those dependencies at the exact point you pull them down, so I concede it is still not perfect without rebuilding the lot. :-)

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#248

Post by krferriter »

subway wrote: post #239
ithkuil wrote: post #235

Earlier quoted context omitted.

Can't the hash be verified by the client too?

Sure, but who tells the client what the correct hash is?

If you're the entity who created the image you can retain the original hash and verify it against the downloaded copies. But that kind of defeats the purpose of being able to download docker images across distributed hosts.

They'd really need to be signatures attached to the images, not just hashes.

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#249

Post by jjeaff »

kbirkeland wrote: post #242
gtsteve wrote: post #169

Earlier quoted context omitted.

It uses SHA-256 right? My understanding is that there isn't yet a workable collision attack on the SHA-2 family. Regardless, I think it's certainly an excellent hardening step.

A hash only provides integrity. A signature provides integirty and authentication .

Integrity is all you need as long as you have verified the original image that you have saved the hash for.

Re: Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

#250

Post by jjeaff »

r3bl wrote: post #170
jhasse wrote: post #155

Earlier quoted context omitted.

Wouldn't that mean you need to find a collision?

There's a good chance that someone who can modify your base image can also modify the checksum you're showing to whatever is the new checksum. For example, when Linux Mint's ISOs were briefly backdoored, the attackers also changed the checksum shown on the website: https://www.zdnet.com/article/hacker-hundreds-were-tricked-i...

But that's not the point here. The point is that you choose an image and verify that it is safe and then pin the hash. So I can pull that hash a thousand times over from whatever source I want and I can be sure it is always the same image that 8 originally verified. I don't care who has it or who now has control over the site because if the image doesn't match the hash, then it isn't mine.
Post reply on HN