Bug 743474

Summary: 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]
Product: [Fedora] Fedora Reporter: Huzaifa S. Sidhpurwala <huzaifas>
Component: kexec-toolsAssignee: Dave Young <ruyang>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 19CC: Brandon.Vincent, caiqian, nhorman, ruyang, xiyou.wangcong
Target Milestone: ---Keywords: Reopened, Security, SecurityTracking
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: fst_owner=bvincent, fst_ping=1
Fixed In Version: Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-04 02:05:53 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 716439    

Description Huzaifa S. Sidhpurwala 2011-10-04 22:31:02 EDT
This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected Fedora
versions.

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:
http://fedoraproject.org/wiki/Security/TrackingBugs

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:
https://admin.fedoraproject.org/updates/new/?type_=security&bugs=716439

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]
Comment 1 Fedora Admin XMLRPC Client 2012-04-16 02:12:56 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 Fedora End Of Life 2012-08-06 15:56:24 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Fedora End Of Life 2012-08-06 15:58:39 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Tomas Hoger 2012-08-07 04:05:37 EDT
It seems this has not been fixed in Fedora at all and StrictHostKeyChecking=no is still used.
Comment 5 Dave Young 2012-08-07 04:13:36 EDT
What's the problem here? we use StrictHostKeyChecking=yes in rawhide and f17 in fact. In f16 we did not support ssh dump
Comment 6 Vincent Danen 2012-08-09 17:04:12 EDT
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.
Comment 7 Fedora Admin XMLRPC Client 2013-02-25 03:06:22 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2013-02-25 03:09:11 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Fedora End Of Life 2013-04-03 15:51:32 EDT
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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 10 Dave Young 2013-06-24 02:41:17 EDT
Hi,

With latest F19 kexec-tools there problems should not exist any more, could you verify?

Thanks
Dave
Comment 12 pjp 2014-12-03 13:22:17 EST
Hello ruyang,

Could you please fix this soon?
Comment 13 Brandon Vincent 2014-12-04 02:05:53 EST
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.
Comment 14 Dave Young 2014-12-04 02:35:25 EST
Great, thanks for verification.