Puppet users - May 2013 - What data on the server can a compromized host read

Hello,

I am trying to better understand the security impact a compromised host 
managed by puppet could have on our infrastructure.

Suppose an attacker gained root on a machine called ''owned'',
and we have
this in site.pp:

node owned {
    file {''foo'':
        content => ''puppet:///modules/module_name/foo'',
    }
}

Will agent running on ''owned'' be able to retrieve:
 - <modulepath>/module_name/files/bar
 - <modulepath>/module_name/manifests
 -  hiera data (other than what it''s supposed to have access to)


Thanks very much,

Vlad



-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Pretty much everything in puppet is secured with SSL certificates. If 
someone has root access to one of your client machines, they have that 
certificate. They can then retrieve anything that that node is allowed to 
retrieve, which is generally specified in auth.conf. By default, I think 
this includes their own catalog, their own node definition, all files 
served by the master process... a few other things.

It shouldn''t be able to get at your manifests directly, as those are 
compiled before being sent to the client, nor should it be able to get at 
hiera data on the master.

On Thursday, May 30, 2013 1:24:27 PM UTC-7, Vladimir Brik
wrote:
>
> Hello,
>
> I am trying to better understand the security impact a compromised host 
> managed by puppet could have on our infrastructure.
>
> Suppose an attacker gained root on a machine called
''owned'', and we have
> this in site.pp:
>
> node owned {
>     file {''foo'':
>         content =>
''puppet:///modules/module_name/foo'',
>     }
> }
>
> Will agent running on ''owned'' be able to retrieve:
>  - <modulepath>/module_name/files/bar
>  - <modulepath>/module_name/manifests
>  -  hiera data (other than what it''s supposed to have access to)
>
>
> Thanks very much,
>
> Vlad
>
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Vlad,

This is all more or less dictated by the auth.conf file, although the 
implications can take a little while to chase down. You can see 
http://docs.puppetlabs.com/guides/rest_auth_conf.html for the syntax of 
this file and its general capabilities. The default rules in Puppet 3.x are 
here: https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf

Moving on to your concrete questions:

- "Owned" would NOT be able to directly access ANY manifests or Hiera
data.

In current versions of Puppet with default auth.conf, it works like this: A 
node is allowed to access the /catalog/<NAME> HTTP endpoint, where NAME 
*must* be the node''s own certificate name. (Nodes cannot access 
/catalog/<SOMEONE ELSE>.) A GET request to this endpoint causes the puppet
master to use its manifests and Hiera data to compile a "catalog." (We
mention this here: 
http://docs.puppetlabs.com/puppet/latest/reference/lang_summary.html#compilation-and-catalogs)


A catalog is not just a subset of manifests; it removes all conditional 
logic, irrelevant data, etc., and becomes an unambiguous single-node 
document, rather than a contingent multi-node piece of code. All Hiera data 
gets resolved, and becomes literal node-appropriate values in the catalog.

- By default, "owned" WOULD be able to access file contents in 
<modulepath>/module_name/files. This can be prevented by making additional
rules in auth.conf for specific modules you are worried about. 

The default auth.conf allows all certified nodes to access any endpoint 
beginning with /file. When fetching file contents for 
<modulepath>/my_module/files/this_file.txt, puppet agent hits 
/file_metadata/modules/my_module/this_file.txt (to check whether it already 
has the correct content) and then 
/file_content/modules/my_module/this_file.txt (to fetch the content if it 
isn''t up to date). These are both prefixed by "/file", so
everyone can get
them. Nodes can also use the "file_metadatas" endpoint to get
directory
listings. 

If you have files in a special module that you are worried about, and if 
you can express the nodes who are allowed to access it in terms of 
certificate name or IP address, you can create a new auth.conf rule for 
that module and place it ABOVE the "/file" rule in auth.conf:

path ~ ^/file_(metadata|content)s?/modules/my_module
auth yes
allow /^(.+)\.dmz\.example\.com$/
allow_ip 192.168.100.0/24

This trick also works for custom fileserver mount points as defined in 
fileserver.conf (http://docs.puppetlabs.com/guides/file_serving.html), 
which may be a better choice for highly sensitive files.

Finally, for truly sensitive content, you have some extra options: 

- You can avoid the "source" attribute for sensitive files, and use 
"content" instead. This compiles the approved content for THAT NODE
into
the catalog. You can use the template() function 
(http://docs.puppetlabs.com/references/latest/function.html#template) to 
get content from an external file which nodes cannot directly access, and 
if your manifests make sure that only highly trusted nodes will have that 
content compiled into their catalogs, the information is effectively 
protected from less-trusted nodes that get owned. 
- You can investigate the hiera-gpg tool, which... I''m afraid I
haven''t
learned how to use it, yet, but it promises a fairly robust way to handle 
dangerous content. 

Also, keep in mind that facts 
(http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#facts-and-built-in-variables)
reported by the node are not necessarily trustworthy -- If you are using 
facts to make decisions about who can access certain content, it may be 
possible for an attacker to guess a fact value that will get them something 
interesting in their catalog. Note also that the special $clientcert 
variable is essentially just a fact; it isn''t validated by the puppet 
master. We''re currently investigating adding a trusted certificate name
variable, see here: http://projects.puppetlabs.com/issues/19514

Hope that helps, 

N


On Thursday, May 30, 2013 1:24:27 PM UTC-7, Vladimir Brik
wrote:
>
> Hello,
>
> I am trying to better understand the security impact a compromised host 
> managed by puppet could have on our infrastructure.
>
> Suppose an attacker gained root on a machine called
''owned'', and we have
> this in site.pp:
>
> node owned {
>     file {''foo'':
>         content =>
''puppet:///modules/module_name/foo'',
>     }
> }
>
> Will agent running on ''owned'' be able to retrieve:
>  - <modulepath>/module_name/files/bar
>  - <modulepath>/module_name/manifests
>  -  hiera data (other than what it''s supposed to have access to)
>
>
> Thanks very much,
>
> Vlad
>
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Nick,

Thank you very much for the detailed explanation!

Vlad

On 05/30/13 20:09, Nick Fagerlund wrote:
> Hi Vlad,
>
> This is all more or less dictated by the auth.conf file, although the
> implications can take a little while to chase down. You can see
> http://docs.puppetlabs.com/guides/rest_auth_conf.html for the syntax of
> this file and its general capabilities. The default rules in Puppet 3.x
> are here: https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf
>
> Moving on to your concrete questions:
>
> - "Owned" would NOT be able to directly access ANY manifests or
Hiera data.
>
> In current versions of Puppet with default auth.conf, it works like
> this: A node is allowed to access the /catalog/<NAME> HTTP endpoint,
> where NAME *must* be the node''s own certificate name. (Nodes
cannot
> access /catalog/<SOMEONE ELSE>.) A GET request to this endpoint
causes
> the puppet master to use its manifests and Hiera data to compile a
> "catalog." (We mention this here:
>
http://docs.puppetlabs.com/puppet/latest/reference/lang_summary.html#compilation-and-catalogs)
>
>
> A catalog is not just a subset of manifests; it removes all conditional
> logic, irrelevant data, etc., and becomes an unambiguous single-node
> document, rather than a contingent multi-node piece of code. All Hiera
> data gets resolved, and becomes literal node-appropriate values in the
> catalog.
>
> - By default, "owned" WOULD be able to access file contents in
> <modulepath>/module_name/files. This can be prevented by making
> additional rules in auth.conf for specific modules you are worried about.
>
> The default auth.conf allows all certified nodes to access any endpoint
> beginning with /file. When fetching file contents for
> <modulepath>/my_module/files/this_file.txt, puppet agent hits
> /file_metadata/modules/my_module/this_file.txt (to check whether it
> already has the correct content) and then
> /file_content/modules/my_module/this_file.txt (to fetch the content if
> it isn''t up to date). These are both prefixed by
"/file", so everyone
> can get them. Nodes can also use the "file_metadatas" endpoint to
get
> directory listings.
>
> If you have files in a special module that you are worried about, and if
> you can express the nodes who are allowed to access it in terms of
> certificate name or IP address, you can create a new auth.conf rule for
> that module and place it ABOVE the "/file" rule in auth.conf:
>
> path ~ ^/file_(metadata|content)s?/modules/my_module
> auth yes
> allow /^(.+)\.dmz\.example\.com$/
> allow_ip 192.168.100.0/24
>
> This trick also works for custom fileserver mount points as defined in
> fileserver.conf (http://docs.puppetlabs.com/guides/file_serving.html),
> which may be a better choice for highly sensitive files.
>
> Finally, for truly sensitive content, you have some extra options:
>
> - You can avoid the "source" attribute for sensitive files, and
use
> "content" instead. This compiles the approved content for THAT
NODE into
> the catalog. You can use the template() function
> (http://docs.puppetlabs.com/references/latest/function.html#template) to
> get content from an external file which nodes cannot directly access,
> and if your manifests make sure that only highly trusted nodes will have
> that content compiled into their catalogs, the information is
> effectively protected from less-trusted nodes that get owned.
> - You can investigate the hiera-gpg tool, which... I''m afraid I
haven''t
> learned how to use it, yet, but it promises a fairly robust way to
> handle dangerous content.
>
> Also, keep in mind that facts
>
(http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#facts-and-built-in-variables)
> reported by the node are not necessarily trustworthy -- If you are using
> facts to make decisions about who can access certain content, it may be
> possible for an attacker to guess a fact value that will get them
> something interesting in their catalog. Note also that the special
> $clientcert variable is essentially just a fact; it isn''t
validated by
> the puppet master. We''re currently investigating adding a trusted
> certificate name variable, see here:
> http://projects.puppetlabs.com/issues/19514
>
> Hope that helps,
>
> N
>
>
> On Thursday, May 30, 2013 1:24:27 PM UTC-7, Vladimir Brik wrote:
>
>     Hello,
>
>     I am trying to better understand the security impact a compromised
>     host managed by puppet could have on our infrastructure.
>
>     Suppose an attacker gained root on a machine called
''owned'', and we
>     have this in site.pp:
>
>     node owned {
>          file {''foo'':
>              content =>
''puppet:///modules/module_name/foo'',
>          }
>     }
>
>     Will agent running on ''owned'' be able to retrieve:
>       - <modulepath>/module_name/files/bar
>       - <modulepath>/module_name/manifests
>       -  hiera data (other than what it''s supposed to have access
to)
>
>
>     Thanks very much,
>
>     Vlad
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.