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.
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
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 :-)