Im going to open a space in Sourceforge where we can coordinate all tasks /
patchs, etc. Stay tuned
2010/9/19 Gouin Patrick <pg.freez...@free.fr>
> Hi John,
>
> In a mail out of the list, I just responded to gordy (your wiki maintainer)
> :
>
> Le 19/09/2010 12:45, Gouin Patrick a écrit :
>
>> <snip>
>>
>>> 2) In particular.....the log does not appear to list the details of
>>> the PIDs etc if this test is enabled.
>>>
>> That's due to the way RkHunter parse the unhide output. It only reads the
>> first line.
>> That's probably due to the fact that old version (prior to 2009) of unhide
>> doesn't
>> output the command line or executable name.
>> So you can remove YMMV on the last line of the unhide paragraph in the
>> wiki, it's for
>> everybody the same :)
>>
>> We can probably display all the output on a single line if the RkHunter
>> team want to
>> log this info and, then, if it helps the parsing.
>> Something like :
>> Found HIDDEN PID: 4214 Command: /sbin/procname
>> As the command line may contain space characters, I wonder if we should
>> include it in
>> double quotes ? Or does it make no difference for awk ?
>>
>>> I have run a manual test and if you feel like it here is the link to the
>>> files
>>> http://paste.debian.net/plain/90364
>>>
>> Here, we can see two things :
>>
>> - a bug in RkHunter :
>> [10:31:20] Warning: Hidden processes found: 1470
>> The value 1470 is not the number of hidden process but the pid of the 1st
>> one.
>> The line in RkHunter
>>
>> HIDDEN_PROCS=`${UNHIDE_CMD} sys | grep '^F' | awk -F':' '{
>> print $2 }'`
>> is wrong in this respect.
>> I haven't noticed this before as I haven't hidden process on my system ;)
>>
>> - another difference between quick test and sys test of unhide :
>> In sys test, each subtests scans the whole processes, so each hidden
>> process is
>> output many times.
>> In quick test, all subtest are done once for each process, so hidden ones
>> are output only one time.
>> <snip>
>>
> I should have looked in the CVS :).
> In revision 1.357 of the rkhunter file, you remove a "'sort|uniq' line
> which does not seem necessary".
> Well, in fact i think it was necessary as the same hidden process appears
> many times in the output
> of the sys test of unhide.
> But as you added the capture of the process command line in rev 1.337, the
> sort surely mess up the log.
> I see that last version gets all the interesting lines.
> But with sys and procfs tests, hidden processes will be output more than
> one time.
> And for the version 20100201 of unhide (the more spread one ?), warning
> message could pollute the output.
>
> I quickly cooked a version of unhide-linux26 which output all the info on
> one line :
> Found HIDDEN PID: pid Command|Exe|Wchan: "cmdline|procname|kthread".
> with the double quotes.
> The wchan string is enclosed in square brackets as in ps.
> This way you can "sort | uniq" with sys test.
> The other alternative is to use the quick test which is equivalent to
> proc+sys+procfs tests
> but is much faster (the process number range is scan only once while making
> all subtests,
> the other tests scan all the range for each subtest).
> The drawback is that there could a little bit more false positives but most
> (if not all) of them will be output as :
> Found HIDDEN PID: 13220 " ... maybe a transitory process"
> I should add that, up to now, I haven't see any such FP on my system
> (except with the brute test).
>
> I also add a "-V" to read the version of unhide-linux26
> I also correct the value returned by unhide-linux26, which can now be
> reliably tested.
>
> Here's the complete changelog
> - Make the output of hidden process monoline to facilitate parsing
> - Read wchan if there is no cmdline and no exe link (sleeping kernel
> threads)
> - Add -V version to show version and exit.
> - Use printbadpid() in checkallnoprocps() as in other tests.
> - Use printbadpid() in checkallreverse() as in other tests.
> - Correct the value returned by unhide
> - Add a warning about the generic version of unhide in README.txt
> - Modify man page to add the -V option, correct typos and clarify quick
> test.
>
> I attach the tarball in case you want to test it.
>
> Regards,
>
> Patrick.
>
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Rkhunter-users mailing list
Rkhunter-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkhunter-users
