Docker Hub being hacked was basically just a question of time.
With how much of the internet blindly pulls images from it, the potential gain from hijacking just one high-profile one would be monumental.
With how much of the internet blindly pulls images from it, the potential gain from hijacking just one high-profile one would be monumental.
Shortcuts all around -- kind of reminds me of MongoDB. Sad it's the primary player...
How is this issue specific to Docker? Anyone can download a random library off github, use a shady linux distribution, or install utility tools loaded with spyware.
I don't think Docker aims to solve issues relating to trusting upstream software. It's a tool to help package applications, just like how tar allows you to package files. What you put in it is up to you.
How is this github any different?
I wonder if docker allows this and on the other hand if that's even feasible for say application images, given that applications must be updated a lot for security reasons. Of course if the Dockerfile's parent reference is not pinned, that does only help to some degree...
docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
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.
Installing known-vulnerable old versions of legitimate software can be just as bad as installing custom malware.
And as I said, only official-library Docker images are signed. All other images are unsigned and even for third-party repos you can't force Docker to verify all images from a given repo (you have to enable it globally, which breaks the utility of a local "docker build").
[+] Arch is the only counterexample I can think of and I'm not even sure if my memory is correct.
If Github was compromised, it would be easy and obvious to insert malicious code in a repository, but hide those changes from anyone on the github website.
Images on Docker Hub don't even need to share their Dockerfile, to talk of all the source/etc that went into their build.
> Which you can avoid by forking the mainline repo and depending on your fork.
If github was compromised, the it would be pretty easy to generate forks with the same compromised code.
Nobody read the source code for this exact reason: “the community is here to read it so I won’t".
For docker (and npm for all that matters) _a lot_ of important dependencies are basically simple one-off "developments" with a single developer and no userbase at all caring for them, because they don't really solve any consistent problem, being basically just created to increase the visibility of its creator on primitive metrics. The community is there for high-level packages, but the dependencies lurk in test-scripts and seldom-used functions carefully placed by some idiotic digital nomads for their personal CV-polishment (ehm, not looking at you: https://github.com/sindresorhus/shebang-regex). Have a look at where this package is used (basically only in cross-spawn, where there are 10 other similar dependencies), then think about, how much effort creating the dependency hierarchy was, then look up who contributed the changes, where this micro-package was required and finally decide whether this was some thing sane people would do or if it's just for personal gain...
In Debian we review and vet packages.
Strawman. Anyone can use Debian Stable or at least Testing.
Actually only short names go to docker hub, one can setup their own registry and use it via dns names.
Example: docker pull quay.io/letsencrypt/letsencrypt
One day, there's going to be a colossal compromise, and that might finally change where we place security in the priority chain.
I do wish developers would be a little wiser around these things, especially when they see companies taking such huge amounts of capital. I found it quite depressing to watch the unquestioning way development communities assimilated the docker worldview.
But no, not Docker.
You're totally right; with as important as their registry is to well funded attackers, and as startup-y and "agile" as they are, and as godawful as the security practices are that underlie their tools and standards... they hadn't a chance. They still don't.
There is no reason to expect them to get better.
[0] https://twitter.com/WHHackersBR/status/1118393568656334850
(that said, google main page vulnerable to xss is kind of like... what, we're afraid someone will take over google and put some cryptominers on the google.com main page?)
6% of the people received a specific email saying the body of their email was accessed and they had to backtrack.
> This unauthorized access could have allowed unauthorized parties to access and/or view information related to your email account (such as your e-mail address, folder names, the subject lines of e-mails, and the names of other e-mail addresses you communicate with), but not the content of any e-mails or attachments, between January 1st 2019 and March 28th 2019.
Notice it says your email account. The whole email is about the account of the recipient, not those of other recipients. Given that they explicitly worded it this way and people clearly misinterpreted it to mean something else, I hope you can forgive me for being a little skeptical of third-party anecdotes that suggest Microsoft claimed nobody's email contents were accessed...
Why wasn’t that the case before?!
There's always a way to enhance your processes, monitor more indicators, etc. or otherwise improve your security.
It wasn't authentication credentials, but still.
> The bigger problem for Google isn’t the crime, but the cover-up. The vulnerability was fixed in March, but Google didn’t come clean until seven months later when The Wall Street Journal got hold of some of the memos discussing the bug. The company seems to know it messed up — why else nuke an entire social network off the map? — but there’s real confusion about exactly what went wrong and when, a confusion that plays into deeper issues in how tech deals with this kind of privacy slip.
(https://www.theverge.com/2018/10/9/17957312/google-plus-vuln...)
as long as you're using software somewhere in the stack that isn't like maturity level 5, AND you don't have constant audits looking for novel attacks on working-as-intended systems, you're pretty much guaranteed to inherit (or create) a vulnerability at some point, and if you're important enough it will get exploited. the reason that doesn't mean we should start modeling computer systems as "living organisms that eventually get old and die" and should keep modeling security like war is that when you get hit, you can respond. all the layers matter, and insofar as Microsoft or Google do it right, they primarily do it right by having a mature process for monitoring, patching, isolating, etc.
as for docker hub though, yeah i'm totally with you. i'm just saying we shouldn't overestimate the preventive capacity of anyone, honestly. if you're doing anything important over the internet at all, you're making some compromises somewhere.
here are 2 links to things i handwaved at above, for example's sake:
https://www.wired.com/story/microsoft-email-hack-outlook-hot...
https://www.forbes.com/sites/kateoflahertyuk/2018/10/09/goog...
As I understand it, there's no element of signing from the actual devs of an image, just from the central trust service of Docker Hub.
There already have been questionable images hosted there ... just by users uploading compromised images. No hacking needed.