You are here
Chris - Wed, 2022/10/05 - 18:46
Versions of Webmin prior to 1.997 have a Critical vulnerability (CVSS3 score of 9.8). This is an authenticated vulnerability so in my case as the only Webmin user I'm not worried about it. Others may have more Webmin users so might be at a greater risk. I wondered whether it's worth applying an upgrade to the latest Webmin version?
That would at least stop my vulnerability scanner from telling me about some critical bugs!
Thanks,
Chris
Forum:
Hi Chris, deep apologies on my slow response...
Hi Chris, deep apologies on my slow response. I'm a bit under the pump at the moment trying to get the v17.x release finalised (after a range of other issues that have diverted my attention).
You are right that there are unpatched CVEs against the version(s) of Webmin that we currently provide. As you also note, by default (i.e. assuming that you use default config), none of the vulnerabilities should affect TurnKey's packaged Webmin. However, you are also right that some custom user configs/setups may make it vulnerable. Having said that, it should only be an issue if you have granted a malicious actor a log in.
Regardless, I do really hope to resolve this properly ASAP. Following some discussion on Reddit, a few weeks ago I uploaded new Webmin (v2.000) packages to both our "buster-testing" and "bullseye-testing" repos. My intention was to move them to the main repos once I had some feedback to confirm that the upgrade didn't break anything (it shouldn't but seeing as the CVEs don't affect default config, being a bit more cautious seemed wise) . Strictly speaking if the upgrade breaks Webmin (even if it fails to restart cleanly) that is considered a "DoS" (denial of service) so could be considered a security bug in and of itself. But unfortunately, despite the interest, no one has given any feedback yet!
I have tested them briefly myself, but experience has shown that that is rarely sufficient. If the CVEs affected our default config/setup, then I may have pushed them anyway. But seeing as it doesn't appear critical, I figured it better to err on the side of caution. As I'm currently juggling lots of priorities, lack of feedback meant that it slipped down my list.
If you're open to assist me to push this forward, please enable the relevant testing repo on your TurnKey appliance and install the newer packages. Then report back.
To enable the testing repo:
Now you have 2 options to upgrade Webmin (I recommend the second):
The easy way: install all upgrades
The easy way is to just update all upgradeable packages (from TurnKey Debian and any other apt repo that is enabled). That can be done like this:
As a general rule, I don't recommend doing a full package upgrade with the TurnKey testing repo enabled. It shouldn't cause any issues right now, but I can't guarantee that is always the case (it's called "testing" for a reason!).
Even if/when the TurnKey testing repo is not enabled, I would still not recommend upgrading all packages on a production server, without testing first. Especially not on a "mission critical" server!
Personally,. I'd recommend at least checking what will be upgrade before doing a full upgrade. Check upgradeable packages like this:
The "other" (better) way - install updated Webmin packages only
Running the following command will only upgrade the Webmin packages:
Either way, hopefully that should "just work". Installing the updated packages should also restart it, so you should be able to log straight in as per usual, and everything should be working, no error messages, etc.
Please give it a try and let me know how it goes. If I can get at least one report of it upgrading cleanly and successfully - I'll look at rebuilding (with the latest release, now v2.001) and pushing to the "main" repos.
Hi Jeremy
Hi Jeremy
No need for apologies. You're an incredibly busy guy and I don't know how you manage to do everything you do!
I've added the test repository on three appliances. One is a Bullseye (Build 17) test appliance and two are low importance Buster appliances. On the Buster boxes when I did 'apt update' I got
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'http://archive.turnkeylinux.org/debian buster-testing InRelease' doesn't support architecture 'i386'
I've not tried Webmin yet, but I do know that upgrading it on Bullseye has removed it from the list of vulnerabilities which is a good start.
I'll do all three upgrades, do some testing and let you know how I get on.
Chris
Thanks heaps for your quick response!
Hi Chris, thanks heaps for your quick response.
The warning about 'i386' is (as the message suggests) because we don't provide a i386 architecture apt repo. I assume that you have multi-arch enabled (otherwise it should be checking for 32 bit packages). If you'd like to quiet that warning, you can edit the 'deb' line for our repos (you'll need to do it on every line). Where it says '[signed-by=/usr/share/keyrings/tkl-bullseye-main.gpg]', insert 'arch=amd64, ' in the square brackets. I.e. after adjustment, the full line (on a bullseye based system) should like like this:
Hint, to be sure that you caught them all, you can check using grep:
FWIW - this is what mine returns:
Webmin 2.0 upgrade problems on Buster
Accessing webmin after a test repository upgrade on a Buster appliance...
Clicking the 'Yes - try to restart it' button fixed things.
I can't see any errors in the logs.
I upgraded a second Buster appliance and the webmin process also wasn't restarted after the upgrade (I checked that it still had the same process number from before the upgrade). Manually running 'systemctl restart webmin' before accessing the web interface meant that I didn't see the error on first login on the second appliance.
Quick initial tests (on Buster) after restarting webmin are that it looks to be working OK.
Hmm, bugger!
I thought that I had fixed that! :(
Hmm, so long as it's only the restart issue, I'm wondering whether perhaps I should just publish them anyway and explicitly note the need for a restart? What do you think? Just to be clear, I wouldn't push them (as an automatically installed) security update. But doing a blog post and sending out an email newsletter explicitly noting the required restart might get us across the line?
Webmin 2.0 on Buster
I've run through pretty much all the Webmin 2.0 modules/module tabs on Buster and done some changes using it. After the initial problem of no restart it looks good.
I've not managed to test it on Bullseye yet because my test server seems to have gone AWOL off the network. It's accessible via the console but external access isn't working for some reason. I'm sure that's not Webmin's fault. I don't think I've ever connected to that appliance remotely so I've probably missed something in the network config. I'll do some digging and test Webmin ASAP.
Fantastic - thanks so much!
Great feedback, thank you so much!
A pity about the required restart, but otherwise sounds great.
If you can check Bullseye too when you get a chance, that'd be fantastic.
1) Your fix resolves the i386
1) Your fix resolves the i386 error. I only saw this after I enabled the TKL testing repo so the other TKL repos without seem to be OK without it arch=amd64. All my containers are shown as amd64 architecture in Proxmox and I've not knowingly set any container as multi-architecture (I don't even know how to do that). Also, Bullseye doesn't give the warning message even though the TKL Testing repo doesn't have arch=amd64. Maybe it's just a Buster thing?
2) I've now tested Webmin 2.0 on Bullseye and it looks OK.
3) I wouldn't worry about the missing restart, so I'd go for a release even. When you access the Webmin page for the first time post-upgrade there's a check that warns you that a restart hasn't been done and that provides a button to do the restart. The button worked on both of my Buster servers so if you tell people they need to do it, then the only issue is if people don't read the screen and click the 'no I don't want to restart button'. I guess there's also a case for if the restart button doesn't work but it worked on the limited number of tests I did. I don't remember getting the warning for Bullseye, so that either means it worked OK or my memory is getting worse!
Hmm, your report re the apt sources is weird.
Hmm, your report re the apt sources is weird. That should only be an issue if/when you have "multi-arch" enabled (it allows installation of 32 bit apps and libraries alongside 64 bit ones). And as our repos only have 64 bit support, the issue you are reporting should have occurred as soon as you enabled "multi-arch". Whether or not our "testing" repo is enabled or not should make no difference. Obviously it did in your case and I have no idea why. I guess at least my suggestion fixed it (although I'm surprised that just adjusting the entry in the testing sources.list fixed it too). Anyway, if it works now, no need to fight it! :)
Awesome! Thanks for testing on Bullseye and reporting back.
Thanks for your feedback. I really appreciate it.
I'll see if I can do a rebuild for the main repo for both Buster and Bullseye this week. I notice that there is a newer version out now too, so I may as well package that one instead (the newer version just has some minor bug fixes for the current version so should be fundamentally the same).
Your guidance regarding the restart makes tons of sense. Thanks again.
Add new comment