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 attachment 39760 [details, diff] 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.
