Error in ossec-reportd

[kir-b]

I'm trying create a report.
cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd
2017/08/28 16:18:47 ossec-reportd: INFO: Started (pid: 4079).
*** Error in `/var/ossec/bin/ossec-reportd': free(): invalid pointer: 0x0000000000bdd388 ***
Aborted

cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f level 10
2017/08/28 16:18:57 ossec-reportd: INFO: Started (pid: 4083).
*** Error in `/var/ossec/bin/ossec-reportd': double free or corruption (out): 0x00000000021ba670 ***
Aborted

OSSEC version is v.9.2

[nbuuck]

Seems to only occur when there is at least one matching alert:

[root@x x]# /var/ossec/bin/ossec-reportd -V

OSSEC HIDS v2.9.1 - Trend Micro Inc.
...

[root@x x]# cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f level 10; echo $?
2017/08/28 12:17:41 ossec-reportd: INFO: Started (pid: 62317).
2017/08/28 12:17:46 ossec-reportd: INFO: Report completed and zero alerts post-filter.
0

[root@x x]# cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f level 3; echo $?
2017/08/28 12:17:31 ossec-reportd: INFO: Started (pid: 62315).
*** Error in `/var/ossec/bin/ossec-reportd': double free or corruption (out): 0x00007f72448e3c10 ***
Aborted
134

[nbuuck]

I built v2.9.1 from source with DEBUG=1 so I could run this with gdb and it doesn't crash like it does when run from the default install path /var/ossec. The binary in the default path is from the RPM in the Atomic repo:

Installed Packages
Name        : ossec-hids-server
Arch        : x86_64
Version     : 2.9.1
Release     : 1764.el7.art
Size        : 4.0 M
Repo        : installed
From repo   : atomic

[nbuuck]

This issue was previously reported in #1084 and a patch was recently merged in #1088.

[kir-b]

I tried again with different count of alerts, but it's the same.
I use package for ubuntu from Atomic repo.
Package: ossec-hids-server
Version: 2.9.2-2035xenial
Architecture: amd64
Maintainer: Atomicorp [email protected]

[nbuuck]

#1088 wasn't merged until 12 hours after 2.9.2 was finalized, so the patch to fix reportd isn't included in 2.9.2.

ossec-hids/src/shared/report_op.c

Line 525 in afd09b3

free(mgroup);

versus

ossec-hids/src/shared/report_op.c

Line 525 in cb2ac11

//free(mgroup);

[atomicturtle]

Tagged this for 2.9.3, we should have this out in the next few days. 3.0 snapshots are in the pipeline right now ahead of it

[ipmb]

Hi @atomicturtle is there anything we can do to help the 2.9.3 release get out?

[atomicturtle]

Absolutely, I could use a hand backporting any rule/decoder updates from master and fixes (the double-free for example). At the moment Im wrapping up on the 3.0 snapshots, but should be back into this one soon.

[ipmb]

Did this land in 2.9.3? ossec-reportd is still crashing after installing the latest package from the AtomicCorp repo.

# dpkg -S /var/ossec/bin/ossec-reportd
ossec-hids-server: /var/ossec/bin/ossec-reportd
# dpkg -s ossec-hids-server
Package: ossec-hids-server
Status: install ok installed
Priority: extra
Section: admin
Installed-Size: 4559
Maintainer: Atomicorp <[email protected]>
Architecture: amd64
Version: 2.9.3-2912xenial
Depends: libc6 (>= 2.15), libgeoip1, libmysqlclient20 (>= 5.7.11), libssl1.0.0 (>= 1.0.1), expect, debconf
Conflicts: ossec-hids-agent
Conffiles:
 /var/ossec/etc/ossec.conf 45e1b4a4e4c9b62fdf4c8788e2579984
Description: OSSEC Server - Host Based Intrusion Detection System
 OSSEC HIDS for log analysis, integrity checking, rootkits detection and
 active response. This package includes the server
Homepage: http://www.ossec.net
# md5sum /var/ossec/bin/ossec-reportd
43cdc2f86f3b1cb0e72557cf9186ca04  /var/ossec/bin/ossec-reportd
# grep ossec-reportd /var/lib/dpkg/info/ossec-hids-server.md5sums
43cdc2f86f3b1cb0e72557cf9186ca04  var/ossec/bin/ossec-reportd

I also noticed it is still reporting its version as 2.9.2.

# /var/ossec/bin/ossec-reportd -V

OSSEC HIDS v2.9.2 - Trend Micro Inc.

[ddpbsd]

Looks like it: https://github.com/ossec/ossec-hids/blob/master/src/shared/report_op.c#L525

Can you provide a test case? It's not crashing for me in my simple tests.

[ipmb]

Here's an example given this alert.log:

# cat /tmp/alert.log | /var/ossec/bin/ossec-reportd
2018/01/02 10:26:31 ossec-reportd: INFO: Started (pid: 30941).
*** Error in `/var/ossec/bin/ossec-reportd': double free or corruption (out): 0x0000000000f7c6d0 ***
Aborted (core dumped)

[ipmb]

It looks like the potential fix is not in the v2.9.3 branch, but just in master https://github.com/ossec/ossec-hids/blob/v2.9.3/src/shared/report_op.c#L525

[ddpbsd]

Ahhh, I was looking at master, not the branch. Sorry about that.

[ipmb]

Any chance of a git cherry-pick -x cb2ac11cf8e3a6957783c4f2b6b3dcea8dd7d8fe on v2.9.3 and a release of 2.9.4? 😃

[ddpbsd]

@ipmb Please see Issue #1346
There are a few things that need to be backported. Hopefully I remembered them all, but that's doubtful.

[the-getdown]

Can anyone comment on whether this has been fixed? I am still seeing the error, and no word on the release of v2.9.3. Luckily I had backed up my previous version and simply replaced "ossec-reportd", which fixed the problem.

Reading other comment threads, it looks like this has been reported since December 2015.

[ddpbsd]

@the-getdown It's fixed in master.

[ddpbsd]

Pretty sure I just pushed it to the 2.9.4 branch as well. So that could be tested.

[the-getdown]

Thank you. Out of interest, when will v2.9.4 be available for download from ossec.github.io? Apologies, but I'm not a Linux/Github guru. I assume if I pull it from the code repository I will need to compile it?

[ddpbsd]

Yes you would. I think next week or the week after. I'd have to check with @atomicturtle

[IknowJoseph]

Would there be any chance of backporting the fix to v2.9.2?

I have installed OSSEC from the atomicorp debian stretch repository and am running 2.9.2

Thanks

[ddpbsd]

There's a chance. Backporting takes me away from doing the fun stuff, but I'll do it. It doesn't solve the problem of the lack of testing of a possible 2.9.4. I don't have any 2.9 hosts to test on

[ddpbsd]

Ok, the fix I had previously applied is in the v2.9.4 branch.