Bugzilla Bug 62194

aide 0.10 emerged with "+crypt +nls -postgres +zlib" on three different x86
boxes.

On all the boxes I get a segmentation fault when doing "aide --config-check",
with no output at all. On two out of three boxes, I got a segmentation fault
also when doing "aide --init" (hence, aide is not usable). I was not able to
find a difference between the two PCs where I get segfault on --init and the
other one.

I traced the problem of the config-check segfault and reported it to the AIDE
mailing list (see "Segfault on Gentoo - fixed" on
https://mailman.cs.tut.fi/pipermail/aide/2004-August/thread.html). I am not
sure whether it is just a bug in AIDE or also a missing mandatory configuration
parameter in the 0.10 ebuild (--with-confighmackey, see the post for details).
That is, it is not clear to me whether the HMAC key should be given always or
not -- the AIDE documentation does not mention it at all.

Regarding the severity of the problem: if you have a machine where "--init"
segfaults, the bug is indeed blocking. Otherwise, you can just avoid doing
"--config-check" and you're done.

Reproducible: Always
Steps to Reproduce:
1. aide --config-check
2.
3.

Actual Results:  
golem ~ # aide --config-check
Segmentation fault


Expected Results:  
No segfault :)

Looks like app-crypt/mhash is to blame...

Core was generated by `aide --config-check'.
Program terminated with signal 11, Segmentation fault.
#0  0x08059f7d in mhash (td=0x0, plaintext=0x8131728, size=1) at mhash.c:376
376             if (td->hash_func!=NULL)
(gdb) bt
#0  0x08059f7d in mhash (td=0x0, plaintext=0x8131728, size=1) at mhash.c:376
#1  0x0804d50a in conf_input_wrapper (buf=0x8131728 "#", max_size=8192, in=0x8131590) at commandconf.c:231
#2  0x0804a325 in yy_get_next_buffer () at conf_lex.c:5339
#3  0x0804a0fe in conflex () at conf_lex.c:5174
#4  0x080484ba in confparse () at conf_yacc.c:1216
#5  0x0804d2d5 in commandconf (mode=68 'D', line=0x80f6151 "") at commandconf.c:165
#6  0x08059442 in main (argc=2, argv=0xbffff424) at aide.c:417

373     int mhash(MHASH td, const void *plaintext, size_t size)
374     {
375
376             if (td->hash_func!=NULL)
377                     td->hash_func( td->state, plaintext, size);
378
379             return 0;
380     }

mhash() does not like the NULL td pointer which is passed from aide: mhash can
only be blamed for not being robust (a check on 'td' would have been
beneficial). Nevertheless, the original bug lies in aide, which is calling
mhash() without having initialized the library (for details have a look into
aide, src/commandconf.c, lines 203-232, or at my post to the AIDE mailing
list).

The patch has been slightly modified and is now applied in the portage ebuild
as even not having a key to check against should not cause a segfault. Do you
have any suggestions on how to implement --with-confighmackey et al into the
ebuild?

Created an attachment (id=39760) [details]
aide-0.10-fix-config-check-segfault.patch

I still get a seg fault when running aide --config-check.  I found this patch
on
aide's SF bug tracker and after patching, it no longer dumps core.  It is
already
fixed in aide cvs.  Shall we include until next upstream release?

net-mon people - Hope you don't mind. The forensics herd has taken ownership of
the aide package and will fix this bug and a few other aide bugs that exist.

dragonheart and I have cooked up a cvs snapshot and postgres patch (slightly
modified from the patch submitted by Joshua Schmidlkofer in bug #37007) and
have released aide-0.10_p20040917.  This should fix bugs 23764, 37007, and
62194.  Please test.