On Fri, February 6, 2015 9:08 am, Mark Felder wrote:
On Fri, Feb 6, 2015, at 10:26, Ribeiro, Glauber wrote:
I'm not sure the problem is internally in xymon, but rather in the
diversity of sources of the text that ends up in email bodies.
Internally Xymon is using \r (CR) in a lot of places. The info that is
put in alerts is fairly straightforward -- just pieced together from
various ENVs related to the event. As far as I can tell there is no data
sourced directly from the clients in the alerts unless you include
BBALPHAMSG in your alert message, which is going to be a huge amount of
information.
A simple sanitation routine in do_alert.c would probably take care of
this, but if we can remove the \r from being used internally the problem
should solve itself. I think a sanitation routine is probably more
treating the symptom and not the problem, as well as unlikely to solve
all possibilities of dangerous data which shouldn't be getting this far
in the first place.
A simple removal of "\r" characters wouldn't be difficult. But line breaks
can be tricky to get correct for all of the various needs. I'm sure there
are precious few class Mac OS systems out there we're dealing with, but I
also how Windows vs. Unix clients might be affected at display time.
I think xymon should do some simple sanitization of alert texts (maybe a
configuration item), to eliminate CRs (for benefit of email), but also
characters that are not safe for HTML (for benefit of the browser). I
wonder is a crafty person would be able to trick xymon into putting
Javascript in an alert, by manipulating error messages.
If you use the full BBALPHAMSG in your alert message and the client
sends some nasty data I am certain it could do some unsavory things. I
also bet you could -- from a compromised client -- send a crafted alert
message to a new or existing column and attack the admin when he views
the alert in his browser. Your saving grace might be the fact that alert
messages are limited to 4096 bytes:
#define MAX_ALERTMSG_SCRIPTS 4096
That will help you wrt. email somewhat, although one would hope that that
would make an incoming alert message no more or less a possible source of
mal-data than any other potentially untrusted email source.
Hopefully Xymon 5 brings us encrypted and authenticated transport
between the client and server as that will help prevent this type of
attack, as well as protect your sensitive info in transit :-)
This is really the solution -- end-to-end encoding using key trust; right
now the most client security that you have is IP-based. But even if your
transport mechanism is over an stunnel, you're really still at the mercy
of the original source. A local user could execute a script placing a
specially crafted message in $0, which would show up in the 'ps' output
and might survive <PRE> wrapping in the 'procs' test to cause a browser
problem, for example.
Regards,
-jc