Bug #1871

Sensitive information leaked in log reports

Added by Ian Turner about 3 years ago. Updated almost 3 years ago.

Status:Closed Start date:01/15/2009
Priority:Normal Due date:
Assignee:James Turnbull % Done:

0%
Category:file
Target version:0.24.8
Affected Puppet version:0.24.7 Branch:
Keywords:security content source logs
Votes: 0

Description

It seems that at the moment, any files mastered through the “content” tag will sometimes have their contents reported through the various logging domains, either with a diff or with the complete file contents. This does not appear to happen with files mastered through the “source” tag.

Since installed files may contain highly sensitive information, such as passwords, it should be possible to disable this behavior, either by a change for all users or through a configuration directive.

History

#1
Updated by James Turnbull about 3 years ago

  • Category set to file
  • Status changed from Unreviewed to Needs More Information

Can you provide some sanitised examples?

#2
Updated by Luke Kanies about 3 years ago

I agree in wanting examples – I thought I’d fixed all cases of content logging actual content. It should only log checksums now. Or do you even want the checksums to go away?

#3
Updated by Ian Turner about 3 years ago

  • Affected Puppet version changed from 0.24.7 to 0.24.6

Tagmail is sending us messages of the form “Mon Jan 12 15:00:25 -0500 2009 //Node[default]/sudoers/File[/usr/site/etc/sudoers]/content (notice): is ” followed by the file contents. This is for a file whose contents are generated from templates. Client and server are on the same machine running puppet 0.24.6.

#4
Updated by Luke Kanies about 3 years ago

I think this is fixed in 0.24.7; I just checked the code and it looks like I’m only logging hashes, not content.

#5
Updated by Luke Kanies about 3 years ago

  • Status changed from Needs More Information to Closed

Please reopen if you still find this problem in later releases.

#6
Updated by Josh Anderson almost 3 years ago

  • Status changed from Closed to Re-opened
  • Affected Puppet version changed from 0.24.6 to 0.24.7

This is still an issue in 0.24.7. Here’s an example:

/tmp/test.pp:

file { "/tmp/test.txt":
  content => template("/tmp/test.erb"),
  noop => true
}

/tmp/test.txt:

Good-bye!

/tmp/test.erb:

Hello!

Puppet output:

# puppet test.pp
notice: //File[/tmp/test.txt]/checksum: is {md5}d5aeca13b2492cb7ae71178d3e4297a8, should be md5 (noop)
notice: //File[/tmp/test.txt]/content: is Good-bye!
, should be Hello!
 (noop)
#

This was tested with Puppet 0.24.7/Ruby 1.8.6 on Solaris 10 (SPARC) and Mac OS 10.5 (x86).

The log messages are coming from the “go” method in the Puppet::Transaction::Change class:

change.rb:

    def go
        if self.noop?
            @property.log "is %s, should be %s (noop)" % [property.is_to_s(@is), property.should_to_s(@should)]
            return [event(:noop)]
        end

I’m afraid that I haven’t spent enough time with the source code to track this any further.

#7
Updated by Luke Kanies almost 3 years ago

  • Status changed from Re-opened to Ready For Checkin
  • Assignee set to James Turnbull
  • Target version set to 0.24.8

Fixed, again.

This time I used ‘is_to_s’ and ‘should_to_s’, so anyone who uses the API correctly should now never have the actual content.

#8
Updated by James Turnbull almost 3 years ago

  • Status changed from Ready For Checkin to Closed

Pushed in commit:d758f45a14057f0b9517a1905d575d6b28b90bc2 in branch 0.24.x

Also available in: Atom PDF