[Xymon] Xymon notifcations disappear due to base64 encoding

[J.C. Cleaver]

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