When Red Hat / Clones such as CentOS release security fixes, you can just google red hat CVE-2017-9798, and you get a page describing the fix that also lists what version of the appropriate package contains a fix for the mentioned security hole, but searching virtualmin CVE-2017-9798 gets you nothing. This is important as installing virtualmin switches your server from using OS packages for apache and other daemons to virtualmin's own repo for these packages.
What yum or rpm command can I type to figure out if my server has been patched for Optionsbleed (CVE-2017-9788)?
What Web page exists that lists what vulnerabilites Virtualmin has and what package exists that's been released to fix them?
Since google finds nothings is there really nothing like this around?
There is a Changelog on Virtualmin's Webmin site, but it only mentions new features added or old deprecated features removed: http://www.webmin.com/vchanges.html
Is this all the info out there that there is?
Does the virtualmin repo contain this info somewhere?
I'm just trying to figure out if my server has been patched for Optionsbleed, and the lack of this information being available is making it hard.
Thanks, Dave.
Virtualmin isn't your operating system, and we don't provide the vast majority of packages in the system; the only packages we publish security information for are the ones we maintain/distribute.
In the case of Apache, we do rebuild and distribute the httpd package (because we have to rebuild it with suexec docroot set to /home; on Debian/Ubuntu that isn't necessary because they have the suexec-custom package), but you can check for CVE using the same rpm command you'd use for RHEL/CentOS:
# rpm -q --changelog httpd| grep CVEYour post made me curious, as I didn't remember that CVE...and I see I missed an updated httpd package from five days ago. So, I built a new one and it's in the repos now. When I roll out new releases, I post about them in the News forum here and on the mailing list (https://groups.google.com/forum/#!forum/virtualmin-announce) and on our twitter. They aren't secret, but they are also rare; mostly you just need to stay on top of your OS updates because we don't provide most of the security sensitive packages.
We recommend you follow us on at least one of our methods of announcing security updates. You can subscribe to notifications to the News forum here, or the mailing list (which is lower traffic, since it has no replies only the announcements).
This may be a time to remind everyone that Virtualmin exists because we wanted a control panel that didn't take over the OS. You don't have a Virtualmin system...you have a CentOS/Debian/Ubuntu system with Virtualmin on it. We don't replace the whole stack, we work with whatever stack the OS provides as best we possibly can. This is a major feature of Virtualmin over cPanel (among others) that replace everything and makeover the system in their (sloppy, poorly packaged) image.
So, mostly the only security advisories we post are about our software (Webmin, Virtualmin, Cloudmin, and all related modules). I'll occasionally post something about system packages if it's particularly scary. But, we shouldn't be your source for security details about your OS because we didn't provide your OS...your distro vendor did.
--
Check out the forum guidelines!
DLY if you'r looking for fixes / CVE's Joe is right to go looking for the OS itself. Though you in my opinion should also be aware they are using components from third party's as FE Apache, so you could and should also check some of these most important external parts. This while often the fix and vulnerability are quicker sooner posted at their sites i hope. ;)
So my advice also looking at the source programs for security vulnerability matters, ( example link Apache HTTP, https://httpd.apache.org/security_report.html ) ( then you have information if not fixed in your used package how to check things and sometimes for a short time a kind of workarround of very high status)
Also it is always better to know wich vulnerability your box could have ( even if not fixed) then stick your head in the sand. (ostrich)
I'm aware the OS updates come from my OS distro. But I was freaking out when yum said apache comes from virtualmin's repo, because I trust my OS distro, CentOS, to promptly release security fixes. Virtualmin's updates coming from virtualmin's own repo makes sense, because well it's virtualmin. You guys are obviously going to timely upload new virtualmin/webmin/etc releases to your own repo. That goes without saying.
Changing a configuration parameter seems like you should just be able to do it in httpd.conf or a environment variable. An nasty hacker could just binary patch the httpd binary with a hex editor to change it if they needed to, so I don't really see it only being a compile time parameter improving security that much except that only root could change it, but I'm no security expert. Would it be worth the effort to pursue such a change in mainline apache? Though you'd have to wait for RHEL/CentOS 8 or 9 and 6 or 7 to be deprecated to really save you any effort. I guess if your nonroot, you could just compile your own apache with the parameter changed, and run that nonroot if needed, assuming a compiler is available.
After looking into it, it seems virtualmin's slightly changed apache releases have partially the same version numbers, so those can just be used to see if a new release has been made yet or not. Ex:
Red Hat's release (CentOS's is probably similar as CentOS does not duplicate Red Hat's awesome CVE Website)
httpd-2.2.15-60.el6_9.5.x86_64.rpmVirtualmin's release
httpd-2.2.15-60.el6.5vm.x86_64The part that says "60" is the patch number or whatever that Red Hat/CentOS increases by one for every release, so if yours says 59, then you need to update.
So, in the future, I'll just compare these patch numbers to check if security releases have been released yet.
Thanks.
Yeah, I'd rather not maintain Apache packages, at all. But, it's the only way we can ship a consistent (and reasonable, IMHO) configuration for shared hosting.
And, yeah, we keep the CentOS version plus stick a "vm" on the end of the version string to let folks (including us) know it's the Virtualmin package. The goal is, of course, to make it easy to know when you've got the current package compared to a default CentOS or RHEL installation.
And, we always welcome bug reports, if I miss any CentOS/RHEL httpd release.
"Would it be worth the effort to pursue such a change in mainline apache?"
It's been discussed in the distant, distant, past...I think the Apache folks are likely adamant about it being compiled in...the docs used to be very emphatic about why it was that way, though I haven't read those docs in so many years that I don't have any clue if it's still true. I have occasionally searched around to see if there's any movement on bringing over the patched code from Debian to RHEL/CentOS, but that doesn't seem to have any momentum, either. Maybe in a modern world with capabilities they can be convinced to ease up a little (the reason it's such a dangerous feature is that it historically had to be suid root to become any user on the system...that's real scary stuff, and you have to be super careful with the code). With capabilities in Linux, it's a little less dramatic, though this is still among the scariest things for software to do; I believe it'd be possible to provide a range of users that could be suid'ed to to make it a little less scary.
--
Check out the forum guidelines!
When I run
rpm -q --changelog httpd| grep CVEtoday, I am still not seeing CVE-2017-9798 in my output. I’m also not seeing other important httpd security updates, including:Are these (and any other missing CVEs) scheduled to be published by Virtualmin soon?
This patch delivery mechanism does not feel right to me. Please understand that my concern is not with Virtualmin itself, but merely with the process of depending on any middleman between Red Hat’s security patches and my website.
Have any RHEL Virtualmin users had success replacing Virtualmin’s httpd package with the one provided by the OS?
If I miss an httpd update, file a ticket and I'll fix it the same day. I try to follow the RHEL/CentOS security mailing lists, but sometimes miss things.
As I've said before, I'd love to not maintain httpd packages at all, but unless/until the stock packages allow configuring suexec docroot, it won't work without a huge number of config changes in Virtualmin and in a variety of other packages. I don't know of anyone doing so.
I see there's a newer package than what we're shipping, and I'll roll it out now. Again, file a ticket if you see we have an old httpd in our repos.
Edit: The -80 release is syncing to the mirrors now.
--
Check out the forum guidelines!
Joe, I hope my message came across with the intended tone. I recognize and appreciate how responsive you've been in this thread and in maintaining the packages in the repo.
I’m sure other RHEL Virtualmin users would agree that a primary benefit of paying for RHEL is the trust in Red Hat’s team for timely updates to packages. This gives me a degree of faith that Apache is updated without my needing to monitor it too closely. A dependence on middlemen adds friction to that process that necessitates closer monitoring.
The idea of using the OS’s httpd package is appealing to me for those reasons, but I don’t personally know enough about the suexec docroot setting or Debian’s suexec-custom package to gauge the feasibility of such an endeavor on RHEL.
I agree that it's nice to just be able to trust that it's always up to date. I'll try to sort out a method that is more reliable for me to know when updates are available. The security mailing list I'm on gets a ton of traffic, because it covers a gazillion packages...I should just filter out the ones I care about. But, even then it relies on me being up to date on email, which I never am...I get way too much to cope with. I'll come up with something.
I don't see any realistic way to use the RHEL/CentOS packages unmodified. It means all user data has to move to /var/www, which breaks a ton of things without a ton of config changes. It would also mean SELinux would need a huge number of additional changes to work (I'm probably shipping SELinux support in Virtualmin 7, moving users to /var/www would make that even harder to support). If you have some influence on the Red Hat folks and can push for a configurable suexec, go for it. I unfortunately do not...I can't even get tiny bugfix patches included in Red Hat/Fedora packages, so I've stopped trying a few years ago. I certainly can't convince them to make a change as big as this to a package as important as httpd.
To me, it seems like a no-brainer. It's been in Debian and Ubuntu for more than a decade. If there were a security problem, surely it would have shown itself by now.
--
Check out the forum guidelines!