I just posted updated code to CVS today to take a stab at fixing
this. I added an "illegal_macro_output_chars" variable to the main
config file that allow the user what characters should be stripped
from the $OUTPUT and $PERFDATA macros before they are substituted.
Currently the nasty chars (that the user can specify) are stripped
out completely - no escaping is done of anything that remains int he
macros, although we could think about doing this as well.
I decided to only strip the macros before they're substituted into
notification commands, performance data commands, event handlers,
etc. No characters are stripped from the internal buffers that
actually hold the plugin output, as I want to retain this. I don't
see a problem with keeping these characters internally or writing
them out to the status log (as they are never used in a command).
On 28 Jun 2002 at 10:59, Subhendu Ghosh wrote:
> I understand the issue but would like to see if it is possible to return a
> hyperlink in the output, at least in the case that the plugins are
> executed locally. Since there is no differentiation between local and
> remote that would be hard to currently.
> The other way would be to allow only the urlize plugin to pass a
> The third option would be to add a field to the config that creates the
> hyperlink - i.e internalize the urlize plugin into nagios.
> I have found it very useful for links to traceroute and other tools.
Do you use the links from the web or wap interface? Or from the
notification messages you receive. The way I wrote things, quotes
would be stripped from the output macro for notifications, but would
remain in the status data for viewing via the web interface. So that
won't break hyperlinks for most users.
> Other than the above comments, I think the five characters below should
> About host names and service names - my preference has been to write them
> in following case sensitive DNS naming rules. So removing the characters
> from the names would not be a bad thing.
I added an "illegal_object_name_chars" variable to the main config
file. Instead of enforcing what is and isn't legal, I decided to let
the user decide. Single and double quotes in object names can cause
web interface issues though, so its best to not allow them in object
> Question - should the plugins be forced to check / sanitize their output
> to limit themsleves to alphanumeric+5?
> I would think - yes, but not to escape anything.
Well, we could... but in the end its not very effective, since its
easy to write custom plugins that break the rules. The sanitization
should happen within Nagios.
> The escape should be done on the receiving end.
I was thinking about this and I don't know if we actually need to try
and escape anything. One problem is that I don't know how the user's
commands are defined and how they'll handle escaped characters. The
other thing is that if you strip out most nasty characters (backtick,
etc.), you should be okay with leaving more benign characters like
()?! unescaped. This assumes that the user is enclosing the macros
in quotes in their command definitions.
> A couple of other things - I am not sure about as yet...
> 1. Does this have any impact on the check_command
Nope - only the $OUTPUT and $PERFDATA macros are sanitizes before the
are sent to notification commands, performance data, event handlers,
> 2. Does this have an impact on the maxsize of the input and output
No again - the way I did things, nothing gets done until the macros
are just about to be substituted into command lines that are going to
> On Fri, 28 Jun 2002, Ethan Galstad wrote:
> > Anyway, on to the issue at hand. I had been thinking about stripping
> > all single and double quotes out of the plugin output, so this might
> > was well be the time to do it all. This of course will break any
> > plugin that returns a hyperlink in the output.
> > I would like to keep the following characters, available for output,
> > as
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: firstname.lastname@example.org
[Nagios-devel] Re: [Nagiosplug-devel] Re: Major Secuirty Hole in Netsaint/Nagios.
Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
1 post • Page 1 of 1
1 post • Page 1 of 1