Open dariosusman opened 2 years ago
I am also experiencing segfaults in 3.7.0, though mine are happening in the ossec-analysisd
program. Valgrind output:
==68360== Conditional jump or move depends on uninitialised value(s)
==68360== at 0x410FB1B: ???
==68360== by 0xBA145DD: ???
==68360==
==68360== Invalid read of size 1
==68360== at 0x4C2D112: __GI_strlen (vg_replace_strmem.c:462)
==68360== by 0x6947B7D: strdup (in /usr/lib64/libc-2.17.so)
==68360== by 0x121FF8: DB_Search (syscheck.c:632)
==68360== by 0x121FF8: DecodeSyscheck (syscheck.c:765)
==68360== by 0x118919: OS_ReadMSG (analysisd.c:767)
==68360== by 0x10CFBD: main (analysisd.c:525)
==68360== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==68360==
==68360==
==68360== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==68360== Access not within mapped region at address 0x0
==68360== at 0x4C2D112: __GI_strlen (vg_replace_strmem.c:462)
==68360== by 0x6947B7D: strdup (in /usr/lib64/libc-2.17.so)
==68360== by 0x121FF8: DB_Search (syscheck.c:632)
==68360== by 0x121FF8: DecodeSyscheck (syscheck.c:765)
==68360== by 0x118919: OS_ReadMSG (analysisd.c:767)
==68360== by 0x10CFBD: main (analysisd.c:525)
==68360== If you believe this happened as a result of a stack
==68360== overflow in your program's main thread (unlikely but
==68360== possible), you can try to increase the size of the
==68360== main thread stack using the --main-stacksize= flag.
==68360== The main thread stack size used in this run was 8388608.
--68360-- Discarding syms at 0xa5bc1b0-0xa5c3501 in /usr/lib64/libnss_files-2.17.so (have_dinfo 1)
same here constant ossec-maild segfault after restart and never getting ossec mails from the system
I've tried the 3.7.0 release on a fairly vanilla Debian 11.4 install (runs a not very busy pi-hole) and a possibly cursed fedora 35. I haven't had any crashes on either except when I've misconfigured things. I haven't tried disabling systemd, is that a common setting among the failing installs?
EDIT: They're local installs. I tried both hostname and ip for mail.
No, I've run this on a Debian Testing. Not the stable branch. And using SysVinit. Not systemd.
Cheers, Dario Susman
On 16/08/2022 17:03, Dan Parriott wrote:
I've tried the 3.7.0 release on a fairly vanilla Debian 11.4 install (runs a not very busy pi-hole) and a possibly cursed fedora 35. I haven't had any crashes on either except when I've misconfigured things. I haven't tried disabling systemd, is that a common setting among the failing installs?
— Reply to this email directly, view it on GitHub https://github.com/ossec/ossec-hids/issues/2047#issuecomment-1217103090, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE36VI3F2AJ7T2BBYUWVXKDVZPXXXANCNFSM5UKBJHPA. You are receiving this because you authored the thread.Message ID: @.***>
Greetings!
I've attempted to upgrade to ossec-hids 3.7.0 as a local server/agent/standalone on a Debian/Testing box, without systemd (USE_SYSTEMD=NO). It didn't seem to have any issues until it tried to send the notifications out via email where it threw a segmentation fault.
I've downgraded to 3.6.0 and there were no problems whatsoever. So, I went and recompiled ossec-hids 3.7.0 manually (running make myself) and found the following warning/error at the beginning:
I'm not entirely sure this might be the cause, but it certainly piqued my interest. There was no way this was going to work and I'm not that kind of programmer/developer to understand what needs fixing here, but nonetheless, I thought I'd report this.
Thank you!
Best regards, Dario Susman