171–180 of 269 posts
Earlier quoted context omitted.
Wouldn't that mean you need to find a collision?
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.
What are dockerhub's alternatives? No 2FA. That is bad.
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?
Nowadays, it's arguably a best-practice when designing a new protocol or storage format to simply make all checksums cryptographically strong unless there's a reason not to. I think that might be where the confusion is coming from.
What are dockerhub's alternatives? No 2FA. That is bad.
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/getting_started/) in order to establish a chain of trust for images. If an image gets changed, Docker will refuse to use it and you will be warned that it is untrusted.
Biased opinion on an alternative registry:
- Cloudsmith: https://cloudsmith.io/l/docker-registry/
But you've got other options, such as:
- Self-hosted: https://github.com/docker/distribution)
- Cloud-specific (e.g. ECR, GCR, ACR, etc.)
- Sonatype Nexus: https://www.sonatype.com
- ProGet: https://inedo.com/proget
- Gitlab: https://gitlab.com
- Artifactory: https://jfrog.com/artifactory/
If you're missing the auto-build functionality, this can be achieved reasonably easily with any of the mainstream and awesome CI/CD services out there, such as:
- SemaphoreCI: https://semaphoreci.com/
- CircleCI: https://circleci.com/
- DroneCI: https://drone.io/
Disclaimer: I work for Cloudsmith, and still think Docker Hub is great. :-)
Earlier quoted context omitted.
Libraries off Github literally have the source available for you and the community at large to vet. And you'll find almost no sane shop on the planet where people are allowed, hell encouraged to use shady distros or install random utility tools in production the way they are encouraged to pull unchecked binary blobs from Docker Hub in an often non-reproducible manner.
> Libraries off Github literally have the source available for you and the community at large to vet. 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...
Earlier quoted context omitted.
Yes, in particular we need to know algorithm, work factor and salting details to know whether or not the passwords may be compromised.
Just assume that it's compromised and generate a new one. There is no point in wasting time trying to estimate how long it might take someone to crack it.
It may also explain some suspicious behaviour / source of compromise in the past (we know when the issue was uncovered, not when the first dump was taken)
What permissions did the leaked tokens have? If they had write access, then leaked personal data is the least of anyone's worries. The real concern is how close the hackers came to infiltrating the image source for virtually every modern microservices system. If you could put a malicious image in say alpine:latest for even a minute, there's no telling how many compromised images would have been built using the base i…
Maybe some day we'll get serious about reproducible builds, since reproducibility can serve as a layer of defense against such compromises.
Earlier quoted context omitted.
Hacking aside, Docker is an invitation to trouble. Anybody can publish a binary blob, and users are expected to blindly trust it. It's centralized. It doesn't have a context of "trustworthiness" yet I don't recall docker ever warning me that the image I'm downloading could have been the work of any person. Shortcuts all around -- kind of reminds me of MongoDB. Sad it's the primary player...
> Docker is an invitation to trouble. Anybody can publish a binary blob, and users are expected to blindly trust it 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 t…
Strawman. Anyone can use Debian Stable or at least Testing.
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.
Installing known-vulnerable old versions of legitimate software can be just as bad as installing custom malware.
Earlier quoted context omitted.
And do we ever find out how much that was being exploited "in the wild"?
we grit our teeth and "believe" that anyone traceably affected got an email directly from the company or something :D (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?)