
Webmin 1.890 Exploit – What Happened? - edwintorok
http://www.webmin.com/exploit.html
======
floatingatoll
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.

~~~
jarfil
How does this interact with git clean, reset and checkout?

~~~
floatingatoll
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.)

------
kiallmacinnes

      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.:

    
    
      git clone --reference ~/.cache/git-whatever https://github.com/whatever/whatever

~~~
jwilk
> Is `git status` / `git diff` etc relying only on the timestamp of modified
> local files to decide if a diff is needed?

Of course. There's no other way to implement these commands efficiently.

But you don't even need to play with timestamps. You can ask git to pretend
not to see the changes:

    
    
      git update-index --assume-unchanged password_change.cgi

------
mercora
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.

Just saying this could have been worse.

~~~
LukeShu
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.

~~~
moviuro
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.

~~~
johannes1234321
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.

------
mises
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.

~~~
tenebrisalietum
Client side cetificates are also convenient for this purpose.

~~~
edoceo
Yes! From your own CA. This is a great method.

------
nevi-me
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.

~~~
ohyeshedid
You may want to look into Cockpit.[1]

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.

[1]: [https://cockpit-project.org/](https://cockpit-project.org/)

~~~
wazoox
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.

------
kontorlaore
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!!!

------
mistrial9
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 !

------
cuillevel3
webmin has been around for centuries and was dropped from Debian in 2005.

It has a long history of vulnerabilities
([https://www.cvedetails.com/vulnerability-
list/vendor_id-358/...](https://www.cvedetails.com/vulnerability-
list/vendor_id-358/Webmin.html)).

------
jchw
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.

------
rhinoceraptor
And, of course their site is HTTP only, including the path for their PGP
signing key (!!!).

They do have a valid Let's Encrypt cert, but apparently it's only configured
for the `download` subdomain.

------
TACIXAT
It should be of interest that Webmin is a listed target on Zerodium.

------
runningmike
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?

~~~
tecleandor
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.

~~~
mistrial9
doesn't git hold a checksum for all files changed in a change-set ?

~~~
kontorlaore
As an optimization git doesn't check files with an "old" date.

Running git status in an 1 GB checkout directory will return instantly. Do you
really believe it has hashed all those files?

------
segfaultbuserr
I misread the title as "Webmin has 1890 exploits - what happened". Could
someone change "1.890" to "version 1.890" (Hello, @dang?) Thanks.

