Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with negated Cidr in ossec-2.9 #1065

Open
Azidburn opened this issue Feb 17, 2017 · 9 comments
Open

Problem with negated Cidr in ossec-2.9 #1065

Azidburn opened this issue Feb 17, 2017 · 9 comments

Comments

@Azidburn
Copy link

Hey, i updated to ossec 2.9.0 and got errors when i tested the rules.

*** Error in `bin/ossec-logtest': free(): invalid pointer: 0x0000000001c34031 ***

I searched which rule makes the problem. The problem caused by negation of the cidr in the following rule.

  <rule id="73126" level="7">
    <dstip>!xxx.xxx.xxx.0/23</dstip>
    <match> S </match>
    <description>Description</description>
  </rule>
@ddpbsd
Copy link
Member

ddpbsd commented Feb 17, 2017

I can reproduce this:

(gdb) run -qt
Starting program: /var/ossec/bin/ossec-logtest -qt
2017/02/17 13:58:47 ossec-testrule: INFO: Reading the lists file: 'rules/lists/ossec.block'
ossec-logtest(68968) in free(): chunk canary corrupted 0x1468f59d6631 0xf@0xe

Program received signal SIGABRT, Aborted.
0x000014693971e5ea in thrkill () at <stdin>:2
2       <stdin>: No such file or directory.
        in <stdin>
Current language:  auto; currently asm
(gdb) bt
#0  0x000014693971e5ea in thrkill () at <stdin>:2
#1  0x000014693976bd89 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2  0x000014693971a412 in wrterror (d=Variable "d" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:303
#3  0x000014693971a4e2 in validate_canary (d=Variable "d" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:1042
#4  0x000014693971a593 in find_chunknum (d=0x14693c02aa10, r=Variable "r" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:1061
#5  0x000014693971b386 in ofree (argpool=0x14693c02aa10, p=0x1468f59d6631) at /usr/src/lib/libc/stdlib/malloc.c:1359
#6  0x000014693971b8cb in free (ptr=0x1468f59d6631) at /usr/src/lib/libc/stdlib/malloc.c:1411
#7  0x000014667d31e187 in OS_IsValidIP () from /var/ossec/bin/ossec-logtest
#8  0x000014667d3058e7 in Rules_OP_ReadRules () from /var/ossec/bin/ossec-logtest
#9  0x000014667d30af89 in main () from /var/ossec/bin/ossec-logtest

I'm not sure negation or CIDR search work though. Is that a legal rule entry?

@oparrish2
Copy link

Ran into this same issue recently where a negated CIDR generated an invalid pointer message in 2.9. My negated CIDR was in a srcip element. This is CentOS 7.3 + OSSEC 2.9.0

According to the documentation, negated CIDR values are legal: http://ossec.github.io/docs/syntax/head_rules.html#element-srcip

2017/03/27 16:35:06 ossec-testrule: INFO: Reading local decoder file.
*** Error in `/var/ossec/bin/ossec-logtest': free(): invalid pointer: 0x00005555559351f1 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7c503)[0x7ffff6300503]
/var/ossec/bin/ossec-logtest(+0x27bef)[0x55555557bbef]
/var/ossec/bin/ossec-logtest(+0x8964)[0x55555555c964]
/var/ossec/bin/ossec-logtest(+0x3c4e)[0x555555557c4e]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ffff62a5b35]
/var/ossec/bin/ossec-logtest(+0x3ed8)[0x555555557ed8]
======= Memory map: ========

Program received signal SIGABRT, Aborted.
0x00007ffff62b91d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.14.1-27.el7_3.x86_64 libcom_err-1.42.9-9.el7.x86_64 libgcc-4.8.5-11.el7.x86_64 libselinux-2.5-6.el7.x86_64 libstdc++-4.8.5-11.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64
(gdb) backtrace
#0  0x00007ffff62b91d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff62ba8c8 in __GI_abort () at abort.c:90
#2  0x00007ffff62f8f07 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff6403b48 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:196
#3  0x00007ffff6300503 in malloc_printerr (ar_ptr=0x7ffff663e760 <main_arena>, ptr=<optimized out>, str=0x7ffff6401214 "free(): invalid pointer",
    action=3) at malloc.c:5013
#4  _int_free (av=0x7ffff663e760 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3835
#5  0x000055555557bbef in OS_IsValidIP (in_address=<optimized out>, final_ip=0x5555559281d0) at shared/validate_op.c:331
#6  0x000055555555c964 in Rules_OP_ReadRules (rulefile=<optimized out>) at analysisd/rules.c:501
#7  0x0000555555557c4e in main (argc=<optimized out>, argv=<optimized out>) at analysisd/testrule.c:246

@mjbroekman
Copy link

This is still a problem in 2.9.1

@Azidburn
Copy link
Author

Problem exists in 2.9.2 too

@ddpbsd
Copy link
Member

ddpbsd commented Oct 19, 2017

It doesn't appear to just be CIDR addresses. I get a crash with non-CIDR addresses as well.

@calve
Copy link
Contributor

calve commented Dec 19, 2017

Hi, runned into the same bug in 2.9.2 and master (did not tested 2.9.1)

From my point of view, the bug triggers when negating an IP on a CIDR, in scrip or dstip.

Quickly looking at the code, the bug might be at https://github.com/ossec/ossec-hids/blob/master/src/shared/validate_op.c#L263;

    if (*ip_address == '!') {
        ip_address++;
    }
    // then latter we have
   free(ip_address);

@calve
Copy link
Contributor

calve commented Dec 19, 2017

@ddpbsd I suggest the following fix;

    if (*ip_address == '!') {
-        ip_address++;
+        os_strdup(in_address+1, ip_address);
    }

@ddpbsd
Copy link
Member

ddpbsd commented Dec 19, 2017

Thanks @calve This was next on my list of things to look at. I'll give that a try and make a pull request if it works for me.

ddpbsd added a commit to ddpbsd/ossec-hids that referenced this issue Dec 19, 2017
@calve provided the fix, os_strdup the ip address instead of just
++ing it.
@ddpbsd
Copy link
Member

ddpbsd commented Dec 19, 2017

Pull request #1334 uses the fix provided by @calve

ddpbsd added a commit to ddpbsd/ossec-hids that referenced this issue Dec 19, 2017
the daily report emails. As @calve pointed out in PR ossec#1065 it's a
bad idea to use a static servername. This seems to have been fixed
in maild already.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants