Bug #2069


(encrypted) root passwords are world readable

Added by Andreas Rogge about 11 years ago. Updated about 11 years ago.

Target version:
Fixed in Releases:
Found in Releases:


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:

puppetmaster: puppet.master.server.fqdn
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.

Related issues 3 (1 open2 closed)

Related to Foreman - Bug #2121: Unauthenticated YAML fact and reports importers can be exploitedClosedDominic Cleal01/09/2013Actions
Related to Foreman - Feature #2127: Support newer hash schemes for root passwordsClosed01/15/2013Actions
Related to Foreman - Bug #3060: Remove YAML host permissions from basic users,New09/09/2013Actions
Actions #1

Updated by Sam Kottler about 11 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?

Actions #2

Updated by Greg Sutcliffe about 11 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?

Actions #3

Updated by Ohad Levy about 11 years ago

or maybe have a setting that only allow ip's from smart proxies with puppet feature?

Actions #4

Updated by Andreas Rogge about 11 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.

Actions #5

Updated by Dominic Cleal about 11 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:

In addition, we're looking to verify the SSL certs to ensure it's just the puppet process on the system that has access.

Actions #6

Updated by Dominic Cleal about 11 years ago

  • Status changed from New to Assigned
  • Assignee set to Dominic Cleal
Actions #7

Updated by Dominic Cleal about 11 years ago

  • Status changed from Assigned to Ready For Testing

Some PRs submitted: fixes password hashing (CVE-2013-0173) restricts access to the ENC interface (CVE-2013-0174) 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.

Actions #8

Updated by Dominic Cleal about 11 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #9

Updated by Dominic Cleal about 11 years ago

  • Status changed from Closed to Ready For Testing
  • % Done changed from 100 to 50
Actions #10

Updated by Dominic Cleal about 11 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 50 to 100
Actions #11

Updated by Dominic Cleal about 11 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.

Actions #12

Updated by Dominic Cleal over 10 years ago

  • Related to Bug #3060: Remove YAML host permissions from basic users, added

Also available in: Atom PDF