asterisk users - Jan 2015 - Asterisk executable suddenly about 40KB larger - modules

Hi guys

Thanks for the pointers - I'll look into the possible compromise scenario
though I've got no idea how I'll counter it -if- I manage to detect
it...!

I've disabled prelinking (thanks Tony!) and I'll see if that helps.

Interesting thing I've now discovered (had this failure again at the head
office this morning) is the "growth" in the file's size is
precipitated by
Asterisk crashing with (in /var/log/messages):

Jan  8 06:13:27 veridial kernel: asterisk[7856]: segfault at
00002aaaaaae0900 rip 00002aaaaaae0900 rsp 0000000041e9ad88 error 15

So the sequence is the running Asterisk segfaults, and when it is restarted
ODBC functionality is broken and the executable in /usr/sbin is += 40kb
larger than before.

As for the segfault, when it happened yesterday the address and rip were the
SAME, only the rsp (stack pointer?) values were different, with the same
error 15, e. g. yesterday it was

Jan  7 07:27:12 veridial kernel: asterisk[16462]: segfault at
00002aaaaaae0900 rip 00002aaaaaae0900 rsp 000000004309c428 error 15

Also, the fix I used yesterday (copying the previously compiled asterisk
executable from src/main to /usr/sbin) did NOT work - the file in /src/main
had the same +40kb size / was -already- compromised.

So I did a make clean;make and copied the file from src/main to /usr/sbin
and only -then- did my setup start working again with ODBC CDRs / CELs
running correctly.

I'll also now try Doug's chattr suggestion to try and "freeze"
the live
executable.

Thanks for the replies and assistance.

Regards

Stefan

On 1/8/15 2:24 AM, Stefan Viljoen wrote:
> Hi guys
>
> Thanks for the pointers - I'll look into the possible compromise
scenario
> though I've got no idea how I'll counter it -if- I manage to detect
it...!
>
> I've disabled prelinking (thanks Tony!) and I'll see if that helps.
>
> Interesting thing I've now discovered (had this failure again at the
head
> office this morning) is the "growth" in the file's size is
precipitated by
> Asterisk crashing with (in /var/log/messages):
>
> Jan  8 06:13:27 veridial kernel: asterisk[7856]: segfault at
> 00002aaaaaae0900 rip 00002aaaaaae0900 rsp 0000000041e9ad88 error 15
>
> So the sequence is the running Asterisk segfaults, and when it is restarted
> ODBC functionality is broken and the executable in /usr/sbin is += 40kb
> larger than before.
>
> As for the segfault, when it happened yesterday the address and rip were
the
> SAME, only the rsp (stack pointer?) values were different, with the same
> error 15, e. g. yesterday it was
>
> Jan  7 07:27:12 veridial kernel: asterisk[16462]: segfault at
> 00002aaaaaae0900 rip 00002aaaaaae0900 rsp 000000004309c428 error 15
>
> Also, the fix I used yesterday (copying the previously compiled asterisk
> executable from src/main to /usr/sbin) did NOT work - the file in /src/main
> had the same +40kb size / was -already- compromised.
>
> So I did a make clean;make and copied the file from src/main to /usr/sbin
> and only -then- did my setup start working again with ODBC CDRs / CELs
> running correctly.
>
> I'll also now try Doug's chattr suggestion to try and
"freeze" the live
> executable.
>
> Thanks for the replies and assistance.
I would also start by putting an audit rule on the binary. Something 
like this:
auditctl -w /usr/sbin/asterisk  -p war -k asterisk-bin

then you can get a report on who modified it and when by using:
ausearch -f /usr/sbin/asterisk

Its a start, but eventually you might need to monitor even keystrokes 
with pam_tty_audit.so to understand who is doing this:
http://poorlydocumented.com/2014/05/enabling-pam_tty_audit-on-rhel-centos-or-scientific-linux/
> Regards
>
> Stefan
>
>
>
-- 
Technical Support
http://www.cellroute.net