ossec / ossec-hids

OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.
http://www.ossec.net
Other
4.44k stars 1.04k forks source link

segfault with ossec 3.7.0 on Debian Testing #2047

Open dariosusman opened 2 years ago

dariosusman commented 2 years ago

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.

[Mon Apr 25 19:57:31 2022] Code: 6e 0b 00 e8 8f cd f4 ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 85 ff 74 33 55 53 48 89 fb 48 83 ec 08 66 90 48 89 dd <48> 8b 5b 28 48 8b 7d 20 e8 a8 de f3 ff 48 89 ef e8 a0 de f3 ff 48
[Mon Apr 25 19:58:41 2022] ossec-maild[4190]: segfault at 3e7000081c8 ip 00007f55e36f7473 sp 00007fff0ae98bd0 error 4 in libc-2.33.so[7f55e3635000+158000]
[Mon Apr 25 19:58:41 2022] Code: 6e 0b 00 e8 8f cd f4 ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 85 ff 74 33 55 53 48 89 fb 48 83 ec 08 66 90 48 89 dd <48> 8b 5b 28 48 8b 7d 20 e8 a8 de f3 ff 48 89 ef e8 a0 de f3 ff 48
[Mon Apr 25 19:59:22 2022] ossec-maild[5538]: segfault at 3e7000081c8 ip 00007f98ae651473 sp 00007ffd11c30350 error 4 in libc-2.33.so[7f98ae58f000+158000]
[Mon Apr 25 19:59:22 2022] Code: 6e 0b 00 e8 8f cd f4 ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 85 ff 74 33 55 53 48 89 fb 48 83 ec 08 66 90 48 89 dd <48> 8b 5b 28 48 8b 7d 20 e8 a8 de f3 ff 48 89 ef e8 a0 de f3 ff 48

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:

os_maild/os_maild_client.c: In function ‘OS_RecvMailQ’:
os_maild/os_maild_client.c:70:13: warning: ‘strncat’ specified bound 16 equals source length [-Wstringop-overflow=]
   70 |             strncat(logs, "Old md5sum was: ", 16);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
os_maild/os_maild_client.c:79:13: warning: ‘strncat’ specified bound 16 equals source length [-Wstringop-overflow=]
   79 |             strncat(logs, "New md5sum is : ", 16);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
os_maild/os_maild_client.c:88:13: warning: ‘strncat’ specified bound 17 equals source length [-Wstringop-overflow=]
   88 |             strncat(logs, "Old sha1sum was: ", 17);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
os_maild/os_maild_client.c:97:13: warning: ‘strncat’ specified bound 17 equals source length [-Wstringop-overflow=]
   97 |             strncat(logs, "New sha1sum is : ", 17);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from os_maild/os_maild_client.c:11:
os_maild/maild.h:44:29: warning: ‘%s’ directive output may be truncated writing up to 6144 bytes into a region of size between 917 and 7061 [-Wformat-truncation=]
   44 | #define MAIL_BODY           "\r\nOSSEC HIDS Notification.\r\n" \
      |                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
os_maild/maild.h:44:29: note: in definition of macro ‘MAIL_BODY’
   44 | #define MAIL_BODY           "\r\nOSSEC HIDS Notification.\r\n" \
      |                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
os_maild/maild.h:49:60: note: format string is defined here
   49 |                             "Portion of the log(s):\r\n\r\n%s\r\n" \
      |                                                            ^~
os_maild/os_maild_client.c:205:5: note: ‘snprintf’ output 141 or more bytes (assuming 12429) into a destination of size 7167
  205 |     snprintf(mail->body, BODY_SIZE - 1, MAIL_BODY,
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  206 |              al_data->date,
      |              ~~~~~~~~~~~~~~
  207 |              al_data->location,
      |              ~~~~~~~~~~~~~~~~~~
  208 |              al_data->rule,
      |              ~~~~~~~~~~~~~~
  209 |              al_data->level,
      |              ~~~~~~~~~~~~~~~
  210 |              al_data->comment,
      |              ~~~~~~~~~~~~~~~~~
  211 |              extra_data,
      |              ~~~~~~~~~~~
  212 |              logs);
      |              ~~~~~
 cc -I./external/compat -DMAX_AGENTS=2048 -DOSSECHIDS -DDEFAULTDIR=\"/var/ossec\" -DUSER=\"ossec\" -DREMUSER=\"ossecr\" -DGROUPGLOBAL=\"ossec\" -DMAILUSER=\"ossecm\" -DLinux -DINOTIFY_ENABLED -DZLIB_SYSTEM -DUSE_PCRE2_JIT -DLIBOPENSSL_ENABLED -DLOCAL -Wall -Wextra -I./ -I./headers/ -DARGV0=\"ossec-maild\" -c os_maild/sendcustomemail.c -o os_maild/sendcustomemail.o
cc -I./external/compat -DMAX_AGENTS=2048 -DOSSECHIDS -DDEFAULTDIR=\"/var/ossec\" -DUSER=\"ossec\" -DREMUSER=\"ossecr\" -DGROUPGLOBAL=\"ossec\" -DMAILUSER=\"ossecm\" -DLinux -DINOTIFY_ENABLED -DZLIB_SYSTEM -DUSE_PCRE2_JIT -DLIBOPENSSL_ENABLED -DLOCAL -Wall -Wextra -I./ -I./headers/ -DARGV0=\"ossec-maild\" -c os_maild/sendmail.c -o os_maild/sendmail.o
os_maild/sendmail.c: In function ‘OS_Sendmail’:
os_maild/sendmail.c:31:29: warning: ‘%s’ directive output may be truncated writing up to 129 bytes into a region of size 118 [-Wformat-truncation=]
   31 | #define SUBJECT             "Subject: %s\r\n"
      |                             ^~~~~~~~~~~~~~~~~
os_maild/sendmail.c:330:32: note: in expansion of macro ‘SUBJECT’
  330 |         snprintf(snd_msg, 127, SUBJECT, _g_subject);
      |                                ^~~~~~~
os_maild/sendmail.c:31:39: note: format string is defined here
   31 | #define SUBJECT             "Subject: %s\r\n"
      |                                       ^~
os_maild/sendmail.c:330:9: note: ‘snprintf’ output between 12 and 141 bytes into a destination of size 127
  330 |         snprintf(snd_msg, 127, SUBJECT, _g_subject);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

reyjrar commented 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)
atanas18 commented 2 years ago

same here constant ossec-maild segfault after restart and never getting ossec mails from the system

ddpbsd commented 2 years ago

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.

dariosusman commented 2 years ago

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: @.***>