Red Hat Bugzilla – Bug 743474
CVE-2011-3588 CVE-2011-3589 CVE-2011-3590 kexec-tools: Multiple security flaws by management of kdump core files and ramdisk images [fedora-all]
Last modified: 2014-12-04 02:35:25 EST
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected Fedora
For comments that are specific to the vulnerability please use bugs filed
against "Security Response" product referenced in the "Blocks" field.
For more information see:
When creating a Bodhi update request, please include the bug IDs of the
respective parent bugs filed against the "Security Response" product.
Please mention CVE ids in the RPM changelog when available.
Bodhi update submission link:
Please note: this issue affects multiple supported versions of Fedora.
Only one tracking bug has been filed; please only close it when all
affected versions are fixed.
[bug automatically created by: add-tracking-bugs]
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
It seems this has not been fixed in Fedora at all and StrictHostKeyChecking=no is still used.
What's the problem here? we use StrictHostKeyChecking=yes in rawhide and f17 in fact. In f16 we did not support ssh dump
Regardless of the setting of StrictHostKeyChecking, that was not the only flaw this tracking bug was filed for. To recap from the parent bug:
Multiple security flaws were found in the way kexec-tools performed management
of created kdump core files and ramdisk images:
* the default value of "StrictHostKeyChecking=no" has been used for kdump /
mkdumprd openssh integration. A remote malicious kdump server could use
this flaw to impersonate the intended, correct kdump server to obtain
security sensitive information (kdump core files),
* mkdumprd utility copied content of certain directories into newly created
initial ramdisk images, potentially leading to information leak,
* mkdumprd utility created the final initial ramdisk image with world-readable
permissions, possibly leading to information leak.
Have all of these been fixed in supported versions of Fedora? Keep in mind that F16 is still supported too.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
With latest F19 kexec-tools there problems should not exist any more, could you verify?
Could you please fix this soon?
I've investigated these issues further and reached the following conclusions.
CVE-2011-3588 has been mitigated via setting StrictHostKeyChecking=yes in /sbin/mkdumprd.
CVE-2011-3589 is no longer applicable to kexec-tools, since currently supported Fedora releases use dracut to generate initramfs files and not a modification of the traditional mkinitrd script.
As for CVE-2011-3590, the disclosure of private SSH keys for the root user has been solved by copying only a specified key rather than the entire /root/.ssh directory. By default this key is "/root/.ssh/kdump_id_rsa".
This issue can be considered resolved.
Great, thanks for verification.