For folks wondering how to check whether a given git checkout has modified files that git hasn’t detected, you can tell it to reset the cache and re-checksum all files on disk:
git update-index --really-refresh
For anyone using a persistent checkout approach, consider how often you should run this command on your checkout, and when you last did.
Those commands all depend on the index that this command regenerates. Presumably git puts a lock while it’s regenerating the index, but I haven’t tested that yet. (It would be unlike git to not place a lock here.)
Because the timestamp on the file was set back, it did not show up in any Git diffs.
Is `git status` / `git diff` etc relying only on the timestamp of modified local files to decide if a diff is needed?
If so, that's a pretty sneaky exploit and something I'll bet many build systems are vulnerable to.
This reuse of the local clone is probably done to avoid the needed to clone from scratch. An alternative might be to have a (bare/mirror) clone maintained in `~/.cache/whatever`, then use the `--reference` flag e.g.:
I would guess most people did not install Webmin via some binary distribution package but rather by using their distros package manger meaning they most likely got built from the unmodified source code using completely unrelated and probably uncompromised build servers.
It is my understanding that while git was unaffected, the source release tarballs were. Distro packages tend to prefer the source release tarballs to doing git checkouts.
I know that FreeBSD's webmin package was affected.
After reading your comment i wanted to see for myself how its done on Debian or Ubuntu and realized there are no official packages of Webmin for these distros. So my assumption that most people got a package build from the unmodified source might have been wrong as a whole and my comment is indeed misleading on multiple levels. Thanks for clarifying.
I don't get how this could happen. Why would anyone trust their build server to package the release tarball? Were they ever signed and checked by the devs?
The way I understand releases and tarballs, I'd do it like this:
- git on my machine (supposedly safe)
- bundle the source code, sign it however necessary
- upload and publish the tarball + signature & checksums
That way, unless my own machine was compromised, it should be OK.
The typical reason is that one has a build chain which predates docker and those things, where it wasn't guaranteed that doing it on different machines yields the same result, but having a master host gives consistent result, independent from who does it.
In modern times the reason is that the release is produced in a CI pipeline. So once a build is green and matches allmothe rreleas criteria that tested build is released.
In both cases using a git checkout for longer time is not a got idea and builds should be done as exports into clean directories.
This is why I set most services to listen only on localhost. When I need to expose them externally, I put them behind nginx with http basic auth. It's not top security by any means, but it does the job and provides enough security to stop stuff like this. It's like the old saying about outrunning a bear: you don't have to be the fastest guy, you just have to be faster than the slowest guy.
Wow! This is scary. I used webmin many years ago on one of my servers, and seeing this reminded me that it's still running.
I was running 1.881, and I'm at least glad I never updated to the 1.890. While I haven't needed to change network interfaces or any hardware related change, I still think it's worthwhile keeping it.
Thanks edwintorok for sharing this. I've patched and disabled webmin, I'll temporarily enable it if/when I need it.
Yes, I could do everything through the terminal, but a GUI's still useful in the case where I can't remember/don't know the terminal way of doing something.
While there are other panels out there, Cockpit is sponsored by Red Hat. I'm not a fan of panels, but it offers more functionality out of the box than Webmin. Last time I looked there was some pretty large gaps in functionality outside of a Red Hat environment; the Ubuntu package was missing container management.
The problem with cockpit is that it lacks almost everything, while webmin has modules for almost everything. I regularly look for webmin alternatives, and though there exist a couple of nicer, cleaner ones none has more than 5% of webmin's functionality.
So many mistakes, not doing a clean checkout before a build, setting up a new build server by literally copying everything from the old one, including checked out directories!!!
installed 1.930 from Jamie Cameron on a lonely Ubuntu 1804 this week.. its been 18 months since looking last.. then saw this! generally, Webmin looks great -- updated interface, and more nerdy perl tricks than you can throw a Perl Book from OReilly at .. I hope Webmin project takes this (and the cold-shoulder from Debian) in stride .. keep up the good work, Webmin !
Wow, I don’t use this software, but this went undetected for a fairly long time. There’s probably actually quite a lot of ways this could’ve been prevented, so I hope the project will view it from more angles. I think it would be smart to redo the build server from scratch as well, personally I wouldn’t trust it anymore.
A creapy exploit...” the Webmin source code had been maliciously modified to add a non-obvious vulnerability’ question: how is or was the proces for commiting the malicious pull request in July 2018 orgazized?
Seems like there was no commit. Instead of commiting code, 'they' hacked the build server somehow, and modified files on a synced directory Webmin used for building its packages.
That doesn't stop you from changing something in your working copy.
The hack here is that the working copy used to build from wasn't a clean clone on each build, so just fetching changes from the (un-pwned) github repository would apply those changes and not affect the modified file on the build server.
