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]
Summary: CVE-2011-3588 CVE-2011-3589 CVE-2011-3590 kexec-tools: Multiple security fla...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kexec-tools
Version: 19
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Young
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: fst_owner=bvincent, fst_ping=1
Depends On:
Blocks: CVE-2011-3588, CVE-2011-3589, CVE-2011-3590
TreeView+ depends on / blocked
 
Reported: 2011-10-05 02:31 UTC by Huzaifa S. Sidhpurwala
Modified: 2014-12-04 07:35 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-04 07:05:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Huzaifa S. Sidhpurwala 2011-10-05 02:31:02 UTC
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 06:12:56 UTC
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 19:56:24 UTC
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 19:58:39 UTC
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 08:05:37 UTC
It seems this has not been fixed in Fedora at all and StrictHostKeyChecking=no is still used.

Comment 5 Dave Young 2012-08-07 08:13:36 UTC
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 21:04:12 UTC
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 08:06:22 UTC
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 08:09:11 UTC
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 19:51:32 UTC
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 06:41:17 UTC
Hi,

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

Thanks
Dave

Comment 12 pjp 2014-12-03 18:22:17 UTC
Hello ruyang,

Could you please fix this soon?

Comment 13 Brandon Vincent 2014-12-04 07:05:53 UTC
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 07:35:25 UTC
Great, thanks for verification.


Note You need to log in before you can comment on or make changes to this bug.