[Xymon] 'Shell shock' mitigation

[me at tdiehl.org]

On Fri, 26 Sep 2014, J.C. Cleaver wrote:

> On Fri, September 26, 2014 1:14 pm, me at tdiehl.org wrote:
>> Hi Henrik,
>>
>> On Fri, 26 Sep 2014, Henrik Størner wrote:
>>
>>>> The xymon CGI interface runs via shell wrappers around the actual C cgi
>>>> code (to set the environment properly), which means this would be an
>>>> avenue for attack.
>>> Indeed, this one is nasty. Fortunately, most Linux systems I know of
>>> have /bin/sh linked to /bin/dash and hence are not vulnerable.
>>>
>>> In light of this, I think it is about time we retire the shell-script
>>> wrappers from Xymon. I have written a replacement which is now checked
>>> into the 4.3.18 branch.
>>>
>>> There is a preliminary release of 4.3.18 available on
>>> https://www.xymon.com/patches/ - feel free to try it out. I will release
>>> 4.3.18 over the weekend unless I find some problems with it.
>>>
>>> NOTE: Replacing the shell script wrappers means that the cgioptions.cfg
>>> file is no longer processed as a shell script. The new wrapper works
>>> fine with the default version of cgioptions.cfg, but it you have
>>> modified it in a way that it relies on being processed by a shell, then
>>> it will break.
>>
>>
>> I just upgraded bash to the latest from RH/Centos and I can report that it
>> breaks the data from machines using bbwin. They all went purple. To be
>> sure
>> my hunch was correct, I downgraded bash to bash-4.1.2-15.el6_5.1.x86_64
>> and
>> the purple went away.
>>
>> Is it expected that the fix you reference above will work with bbwin? I
>> have
>> not modified cgioptions.cfg.
>>
>
>
> That's very strange. Was there anything at all in the logs anywhere when
> that was happening? Does BBWin use anything special to communicate in to
> Xymon or is it simply submitting on port 1984 like normal?

I agree it is strange and it makes no sense to me. bbwin sends its data
over 1984 like any other client. FWIW, bbwin is running in central mode and
I am using xymon-4.3.17-1.el6.x86_64.

I saw a bunch of the following in the hostdata.log and distribute.log:
2014-09-26 15:42:58 Could not get shm of size 5242880: No such file or directory
2014-09-26 15:42:58 xymond_channel: Channel not available
2014-09-26 15:52:29 Could not get shm of size 5242880: No such file or directory
2014-09-26 15:52:29 xymond_channel: Channel not available

In the alert.log I also saw the following:
Could not get shm of size 4194304: No such file or directory
2014-09-26 15:52:29 xymond_channel: Channel not available
2014-09-26 15:52:29 Whoops ! Failed to send message (Connection failed)
2014-09-26 15:52:29 ->  Could not connect to Xymon daemon at 192.168.0.2:1984 (Connection refused)
2014-09-26 15:52:29 ->  Recipient '192.168.0.2', timeout 15
2014-09-26 15:52:29 ->  1st line: 'xymondboard color=red,yellow,purple fields=hostname,testname,color'
2014-09-26 15:52:29 xymond status-board not available, code 5

I have similar stuff in the xymongen.log but in looking at all of these errors
I suspect they occured when I was restarting xymon.

The other weird thing I saw was the bbwin service would not reconnect after
I downgraded bash. I had to go to each of the machines and restart the service
by hand before they would communicate. Fortunately there are not very many of
them.

In looking at the logs on the windoze hosts, I see the following:
BBWin failed to send the client data successfuly to the Xymon server. The
error was : Can't send message : An established connection was aborted by the
software in your host machine..

I am not sure if this is revelant or not as everything is reporting normally
but I still see that error in the eventvwr.

The really weird thing is that the linux clients kept working through all of
this.

>> I need to wait until the terabithia rpms are updated to upgrade xymon.
>>
>> Regards,
>>
>
>
> I've posted a set of 4.3.18-0.0.7471.1 RPMs at
> http://terabithia.org/rpms/xymon/testing/ if you're curious to take a
> look, but I'm still testing myself and would use caution.

Thanks, I will take a look.

>
>
> One note: The apache config file needs to be updated to allow
> FollowSymLinks in the /xymon-(sec)cgi/ directory, or all dynamic pages
> will return with a 403 error. The following line on upgrade should fix it:
>
> perl -pe 's/Options ExecCGI Includes/Options ExecCGI FollowSymLinks
> Includes/' -i /etc/httpd/conf.d/xymon.conf && /sbin/service httpd graceful

Regards,

-- 
Tom			me at tdiehl.org		Spamtrap address	 		me123 at tdiehl.org