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