nagios2 plugin output sanitization

[rouilj+nagiosdev at cs.umb.edu]

In message <200711081706.lA8H6lte029156 at post.webmailer.de>,
Matthias.Flacke at gmx.de writes:
>Andreas Ericson wrote:
>> Matthias Flacke wrote:
>> > 
>> > The question is how to ensure that the plugin
>> > output which Nagios receives is really the same
>> > the plugin sent. There are multiple causes in
>> > between which might change it: cutting off due
>> > to small buffers, or misconfiguration, filtering,
>> > escaping, quoting issues...
>> > 
>> 
>> Nagios should (and does) do a byte-by-byte copy of
>> whatever the plugin returns.  Stripping malicious
>> output is an exercise left to the medium where it's
>> used. After all, plugin output could just as well
>> contain shell characters, and Nagios dabbles in
>> that area too (when sending notifications, notably).
>> Escaping html output in the core will btw add many
>> such shell control chars.
>> 
>> There is also database logging modules. They
>> of course have to make sure no sql injection attempt
>> slips past.
>
>You're right concerning the content itself. The plugin
>can send whatever it likes to and the frontend or DB
>or whatever works with the plugin output has to take
>care of any oddities.
>
>> > A solution could be that the plugin provides a CRC
>> > for its output which is checked afterwards. This
>> > could be included in the sanitized_output
>> > option.
>> > 
>> 
>> This is a big nono. A very large part of Nagios'
>> success is that it's really, really easy to add
>> functionality to it by providing a plugin that does
>> something, prints something and then exits with one
>> of four well-defined exit codes.
>
>I understand your point and surely don't want to break
>the simplicity. But take the following scenario:
>
>A plugin uses both return code and output (let's
>assume 10K), but during NRPE transport only the first
>4K survive due to NRPE and kernel compile
>limitation. The return code is OK but the plugin
>output is shortened silently and nobody notices
>this... I don't think that NSCA handles this
>differently. I don't want to 'solve' the problem
>increasing the buffers, since tomorrow certainly a
>message comes around with length = buffer + 1... 
>
>> > Generally I would say that it's Nagios part to
>> > validate the sanity of the transport and raise
>> > UNKNOWN if not ok.
>> > 
>> 
>> You're wrong. Nagios needs to validate (and fix) the
>> strings it uses depending on the context where it's
>> used. The output from the plugins is written to a
>> file as far as Nagios core is concerned, so there's
>> really no need to mangle them at all.
>
>I meant the transport level only. On the sender side
>there is a plugin where I can do everything easily
>(maybe such a CRC or something else). On the receiver
>side there is Nagios core where any bytes are
>gracefully received, eve n if it's only half of the
>stuff. ;-)
>
>How can I deal with this problem?

You are concerned about truncation and not corruption
(if you have corruption I imagine you will get all
sorts of strange characters, and you have bigger
issues).

One thing that comes to mind is an end of data (EOD)
marker <data/>. However checking for it should bepa
optional and on a per service basis. So older plugins
that don't support/need the EOD marker can still
function.

The EOD is simple to add and doesn't have the overhead
of checksums which are overkill for this.

				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/