Bug 868519 - LUKS passphrase exposed in /root/anaconda-ks.cfg
LUKS passphrase exposed in /root/anaconda-ks.cfg
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
Unspecified Unspecified
urgent Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker AcceptedNTH
: Reopened, Security
Depends On:
Blocks: F18Blocker/F18FinalBlocker F18Beta-accepted/F18BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2012-10-20 10:16 EDT by Steve Tyler
Modified: 2014-08-18 10:39 EDT (History)
11 users (show)

See Also:
Fixed In Version: anaconda-18.22-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-08 04:34:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda-ks.cfg with plaintext LUKS passphrase (1007 bytes, text/plain)
2012-10-20 10:16 EDT, Steve Tyler
no flags Details

  None (edit)
Description Steve Tyler 2012-10-20 10:16:34 EDT
Created attachment 630447 [details]
anaconda-ks.cfg with plaintext LUKS passphrase

Description of problem:
After installing with an encrypted /home filesystem, the LUKS passphrase is stored in plaintext in /root/anaconda-ks.cfg. The passphrase should be obfuscated in some way.

Version-Release number of selected component (if applicable):
anaconda-18.19-1
Fedora-18-Beta-TC6-x86_64-DVD.iso

How reproducible:
Presumably always.

Steps to Reproduce:
1. During installation, configure a separate filesystem for /home and specify that it be encrypted. Do not encrypt any other filesystems.
2. After completing the install and rebooting, look at /root/anaconda-ks.cfg.

Actual results:
/root/anaconda-ks.cfg contains the passphrase entered during installation in plaintext. See the attached anaconda-ks.cfg.

[root@localhost ~]# grep passphrase /root/anaconda-ks.cfg 
--encrypted --passphrase="joeblow_secret" --type=plain

Expected results:
The passphrase is obfuscated in some way:
--passphrase="XXXXXX"

Additional info:

Only root has read/write access:
[root@localhost ~]# pwd
/root
[root@localhost ~]# ls -lF
total 4
-rw-------. 1 root root 1007 Oct 20 08:41 anaconda-ks.cfg
[root@localhost ~]# 

Tested with:
$ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC6/Fedora-18-Beta-TC6-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse
Comment 1 Steve Tyler 2012-10-20 12:24:41 EDT
Proposed F18-Beta blocker:

1. Users may not know /root/anaconda-ks.cfg exists, so they may not know to remove it or edit it.
2. Cannot be fixed with an update.
3. F18-Beta users who upgrade to F18-Final without reformatting or changing their LUKS passphrase have an ongoing vulnerability.
4. Anyone with root access or physical access can mount '/home' in the scenario where '/' is not encrypted and '/home' is encrypted. Verified by booting from the installer DVD in rescue mode.

There do not appear to be any criteria covering user secrets, such as passphrases:

"User secrets in plaintext are not written to a filesystem or transmitted across a network without informed user consent."
Comment 2 Steve Tyler 2012-10-20 13:16:38 EDT
See also:
Bug 868509 - LUKS passphrase exposed in storage.log attached to bug report
Comment 3 Chris Lumens 2012-10-21 19:41:43 EDT
/root/anaconda-ks.cfg is meant to accurately reflect the choices you made during installation so you can reuse it in the future.  We make the permissions on this file closed by default, and only root has access to them.  This is working as we intend it.
Comment 4 Steve Tyler 2012-10-21 22:34:50 EDT
If that were true, you would include my partitioning choices too:

# Partition clearing information
clearpart --none --initlabel --drives=sda

The "it is secure because only root can read it" argument is specious. If that were a valid argument, user passwords would not need to be hashed and salted in /etc/shadow. Why not write the root password in plaintext too?

# Root password
rootpw --iscrypted $6$Z3eXI72W4PuNkDSH$WPwo7r6de3LXkGGfJmuZzMDcY5UCzWCJMHAFTrnZkCJXXcV7HY.DyO9yHAQKCSNCRumR9.ULVsWOPpIQLjDuA0

Adam: I'm adding you, because I believe a release criterion may be needed to help protect the security of user passwords.
Comment 5 Chris Lumens 2012-10-21 22:41:18 EDT
kickstart does not allow for expressing encrypted passphrases, and we have no plans to add that.  Your argument that "all my partitioning isn't listed, thus this needs to be fixed" does not follow in the least.
Comment 6 Steve Tyler 2012-10-21 22:44:13 EDT
(In reply to comment #3)
> /root/anaconda-ks.cfg is meant to accurately reflect the choices you made
> during installation so you can reuse it in the future.
...

You said the file would "accurately reflect the choices" I made, but it does not, because it does not say what partitioning choices I made. Why not?
Comment 7 Steve Tyler 2012-10-21 23:19:38 EDT
(In reply to comment #5)
> kickstart does not allow for expressing encrypted passphrases, and we have
> no plans to add that.  Your argument that "all my partitioning isn't listed,
> thus this needs to be fixed" does not follow in the least.

Why does kickstart support encrypted root passwords? If root-only permissions are so secure, why not save the root password in plaintext?

My suggestion was to *obfuscate* the LUKS passphrase, not encrypt it. That would be trivial to implement.

For reference, here is a link to the kickstart documentation:

rootpw [options] <password>
--iscrypted|--plaintext 

http://fedoraproject.org/wiki/Anaconda/Kickstart#rootpw
Comment 8 Steve Tyler 2012-10-21 23:25:43 EDT
"Never store passwords as plaintext. This feels like security 101 ..."

You're Probably Storing Passwords Incorrectly
by Jeff Atwood
September 16, 2007
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
Comment 9 Steve Tyler 2012-10-21 23:29:26 EDT
Lax Security at LinkedIn Is Laid Bare
By NICOLE PERLROTH
Published: June 10, 2012 
http://www.nytimes.com/2012/06/11/technology/linkedin-breach-exposes-light-security-even-at-data-companies.html

"Last week, hackers breached the site and stole more than six million of its customers’ passwords, which had been only lightly encrypted."
...
'“If they had consulted with anyone that knows anything about password security, this would not have happened,” said Paul Kocher, president of Cryptography Research, a San Francisco computer security firm.'
Comment 10 Steve Tyler 2012-10-21 23:53:59 EDT
(In reply to comment #3)
> /root/anaconda-ks.cfg is meant to accurately reflect the choices you made
> during installation so you can reuse it in the future.  We make the
> permissions on this file closed by default, and only root has access to
> them.  This is working as we intend it.

"reuse it in the future"

Computer Security 101: Do not reuse passwords.
Comment 11 Volker Sobek 2012-10-22 04:27:43 EDT
This is security bug, how could one argue it's not?

(In reply to comment #3)
> /root/anaconda-ks.cfg is meant to accurately reflect the choices you made
> during installation so you can reuse it in the future.  We make the
> permissions on this file closed by default, and only root has access to
> them.  This is working as we intend it.

You missed the point that closed permissions don't help when you have physical access in the case described by Steve:

(In reply to comment #1)
> 4. Anyone with root access or physical access can mount '/home' in the
> scenario where '/' is not encrypted and '/home' is encrypted. Verified by
> booting from the installer DVD in rescue mode.
Comment 12 Adam Williamson 2012-10-22 20:20:03 EDT
Throwing the Security keyword on here to get an evaluation from someone with a clue. On the face of it, I agree with Volker and Steve that there appear to be concerns here.

Steve's arguments about partitioning seem specious, I'd agree with Chris that that's a blind alley. Just consider the issue of whether anaconda should write a file that exposes the encryption passphrase for any partitions encrypted as part of the install in plain text. Thanks.
Comment 13 Adam Williamson 2012-10-22 20:20:30 EDT
Chris, can you not re-close this until security folks take a look at it? Thanks.
Comment 14 Vincent Danen 2012-10-23 10:37:18 EDT
Yeah, this needs to be fixed.

There is an obvious deficiency if we're encrypting root's password (which is obvious looking at the log) and then turning around and not encrypting the LUKS password.

The re-use of passwords is a non-argument.  The real issue is we are conscious enough to not put root's password in plaintext, and then shortly after we put the LUKS password in plaintext.  Permissions on the file don't really matter either (well, they do, but...).

This certainly isn't a huge security issue, but it _is_ a security issue and it needs to be corrected.  And fixing it prior to F18 GA should be a priority.

How was this handled in F17?  Is the password in plaintext there as well, or was the call to LUKS not stored at all?  Looking at mine here (although I did use whole-disk encryption), I see nothing in my kickstart config about LUKS at all.
Comment 15 Vincent Danen 2012-10-23 10:42:01 EDT
Not sure how to set this bug as a blocker, but it should be a blocker.
Comment 16 Steve Tyler 2012-10-23 10:51:35 EDT
(In reply to comment #15)
> Not sure how to set this bug as a blocker, but it should be a blocker.

Thanks, Vincent. This bug is already a proposed F18 blocker:

Fedora 18 Beta Blocker Bugs
http://qa.fedoraproject.org/blockerbugs/milestone/18/beta/buglist

To propose a blocker, add the appropriate alias: "Blocks: F18Beta".
http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
Comment 17 Vincent Danen 2012-10-23 15:27:27 EDT
Oh, ok, perfect.  Thanks, Steve.
Comment 18 Adam Williamson 2012-10-23 18:43:57 EDT
For the record, a better reference for how to propose blockers...we have a whole SOP on the blocker process:

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
Comment 19 Adam Williamson 2012-10-24 12:36:11 EDT
Discussed at the 2012-10-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-5.2012-10-24-16.01.log.txt .

We agreed in principle that, roughly, security bugs that can't be fixed with updates (e.g. in the anaconda path) ought to be fixed by Final. We'll flesh out the details in the test list, but on that principle, this bug is accepted as a Final blocker and Beta NTH, but not Beta blocker.
Comment 20 Steve Tyler 2012-10-24 16:39:31 EDT
(In reply to comment #19)
> Discussed at the 2012-10-24 blocker review meeting:
> http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-
> 5.2012-10-24-16.01.log.txt .
> 
> We agreed in principle that, roughly, security bugs that can't be fixed with
> updates (e.g. in the anaconda path) ought to be fixed by Final. We'll flesh
> out the details in the test list, but on that principle, this bug is
> accepted as a Final blocker and Beta NTH, but not Beta blocker.

Thanks, Adam. That all sounds good. AIUI, the release criteria are based on actual examples. This bug and Bug 868509 would be covered by a more specific criterion:

"User secrets in plaintext are not written to a filesystem or transmitted across a network without informed user consent."
Comment 21 Adam Williamson 2012-10-24 19:19:16 EDT
It's a bit of a side alley, but I *really* don't want to get into the business of reinventing the definition of security bugs in the Fedora release criteria. It seems more practical to me simply to say 'all issues that would be considered security issues of severity level XX according to Secunia are blockers', or something like that - you get the idea. defining what is a security issue and how severe various types of issue are is a) complex and b) something that several groups already have considerable experience at, so we should really take advantage of that and not re-invent it.

anaconda team is apparently still not convinced that this ought to be 'fixed', I've been discussing this with dcantrell. The idea is that the kickstart ought to be an exact reproduction of the installation. But I just don't think it's really valid to reproduce the encryption passphrase used during installation. Anyone going to the trouble of encrypting a partition is presumably doing it for security reasons. I can't see any valid case for re-using the kickstart with the same encryption passphrase, that just doesn't seem like a good idea for any user from any angle. Speaking entirely personally, my preferred option would be not to write the passphrase to the kickstart at all; presumably in this case anaconda would prompt for it if you ran an install from the kickstart without editing one in first.
Comment 22 Chris Lumens 2012-10-30 10:26:02 EDT
We are just going to blank out the passphrases for anaconda-ks.cfg.  Any bugs opened about the passphrases not existing, thus the kickstart files doesn't match what you did during installation, will be closed WONTFIX.
Comment 23 Steve Tyler 2012-10-30 12:16:21 EDT
[PATCH] Blank out passphrases from /root/anaconda-ks.cfg (#868519).
https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-October/001829.html

Thanks, Chris.
Comment 24 Fedora Update System 2012-10-31 22:51:42 EDT
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18
Comment 25 Fedora Update System 2012-11-01 14:27:27 EDT
Package anaconda-18.22-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.22-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17432/anaconda-18.22-1.fc18
then log in and leave karma (feedback).
Comment 26 Fedora Update System 2012-11-02 00:06:15 EDT
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18
Comment 27 Fedora Update System 2012-11-02 21:05:40 EDT
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18
Comment 28 Fedora Update System 2012-11-05 20:40:50 EST
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18
Comment 29 Fedora Update System 2012-11-06 21:12:53 EST
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18
Comment 30 Adam Williamson 2012-11-08 04:34:25 EST
18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken).

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