Bug #2069
closed
(encrypted) root passwords are world readable
Description
This is related to #39.
Essentially I do ask for the same feature, but I believe it is not a feature request, but a major security issue.
Right now anyone can download the external nodes YAML without any limitation. For a really basic setup (that doesn't even use external nodes) it looks like this:
--
parameters:
puppetmaster: puppet.master.server.fqdn
owner_email: owner@domain.tld
foreman_env: &id001 production
owner_name: Admin User
root_pw: $1$GDJmRQFN$3hXafZx7hyZdbaL5q2Q8t1
classes: []
As you can see this makes the hash of the root password world readable.
The access to the external nodes script should be limited.
Maybe simply by checking the remote ip address against an array of configured addresses. We definitely need to set the default to no access.
We did move the password hashes from /etc/passwd to /etc/shadow in the early nineties by intent: they should not be world-readable.
Updated by Sam Kottler about 12 years ago
- Category changed from External Nodes to Security
- Assignee deleted (
Ohad Levy) - Priority changed from High to Normal
I agree this would be a nice to have, but it's not a security risk if you're ensuring that your systems don't use MD5 (and maybe not SHA-1). Even using SHA-1 is relatively safe, though because a lot of effort is required to break it. If you use a 6 character password (too short IMO) it takes there are 6.236738252 × 10³⁵ permutations; it would take roughly 8.909626074×10²⁶ CPU years to crack it at 700,000,000 tries a second.
Also, this can be mitigated easily with iptables/firewalld/SG's. @Ohad Levy - what do you think?
Updated by Greg Sutcliffe about 12 years ago
Personally I mitigate this by blocking root access via SSH+password as part of my initial puppet run (which I do during the installer).
However, it is something we should fix at some point. Perhaps we should add a Setting (default to Off) which is an array of IPs which are allowed to recieve externalnodes?
Updated by Ohad Levy about 12 years ago
or maybe have a setting that only allow ip's from smart proxies with puppet feature?
Updated by Andreas Rogge almost 12 years ago
I see two issues here:
1. The default configuration is insecure
All products should be shipped with secure defaults. This is not the case with foreman currently.
I also don't think that recent hashing algorithms work around the problem sufficiently, because by default foreman ships with a well known default password hash.
Whatever you say: this is not what I'd call secure by default.
2. There is no simple/obvious way to deny access to the YML
I googled the topic and there was no documentation available on how to limit access.
Also I haven't found a simple way to deny access. The Information is available through at least two different URLs, so URL pattern matching is probably not sufficient - I cannot be sure there isn't another URL I need to block.
Even if we choose to ship insecure by default, there should be a simple way to make this part of the system more secure.
Updated by Dominic Cleal almost 12 years ago
- Priority changed from Normal to High
- Target version set to 1.1
- Difficulty changed from easy to medium
Proposal above of limiting access to smart proxy hosts by default has been posted here and in #2121:
http://groups.google.com/group/foreman-users/browse_thread/thread/fe39ca595e1f03db
In addition, we're looking to verify the SSL certs to ensure it's just the puppet process on the system that has access.
Updated by Dominic Cleal almost 12 years ago
- Status changed from New to Assigned
- Assignee set to Dominic Cleal
Updated by Dominic Cleal almost 12 years ago
- Status changed from Assigned to Ready For Testing
Some PRs submitted:
https://github.com/theforeman/foreman/pull/372 fixes password hashing (CVE-2013-0173)
https://github.com/theforeman/foreman/pull/373 restricts access to the ENC interface (CVE-2013-0174)
https://github.com/theforeman/puppet-foreman/pull/34 to support restricted access and enable login by default
I'd like to go further in restricting the viewing of hashes to authenticated users too, obfuscating them in ENC, host edit, settings and template previews, but that work isn't complete.
Updated by Dominic Cleal almost 12 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 31b7d5de00c21735164fa92940e6be2c08820c37.
Updated by Dominic Cleal almost 12 years ago
- Status changed from Closed to Ready For Testing
- % Done changed from 100 to 50
Updated by Dominic Cleal almost 12 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 50 to 100
Applied in changeset 358ec5a3a1b59c098b5c14fcd7a90ca1a6a5dccd.
Updated by Dominic Cleal almost 12 years ago
For users updating and hitting this change, please see the following documentation:
We appreciate it's a difficult change, but is necessary to improve the security of the application. If you have problems, do check the troubleshooting text in the manual, and do contact one of the Support channels.
Updated by Dominic Cleal over 11 years ago
- Related to Bug #3060: Remove YAML host permissions from basic users, added