Chkrootkit finds /lib/init/rw/.ramfs on debian etch

If you have chkrootkit installed on debian etch, you might be getting these messages:

/etc/cron.daily/chkrootkit:
The following suspicious files and directories were found:
/lib/init/rw/.ramfs

This is a bug in initscripts, which puts a hidden file in /lib/init/rw but shouldn’t. Until it is fixed, you can patch chkrootkit to get rid of that message.

Update: Apparently, chkrootkit also stumbles on /lib/init/rw/.mdadm. Adapt the patch as needed.

7 thoughts on “Chkrootkit finds /lib/init/rw/.ramfs on debian etch”

  1. I applied the patch. But this is of course a securtity issue. A rootkit could use this for a malicious file placement. So I added a /etc/cron.daily/chkramfs script with a line only:
    test “$(ls -la /lib/init/rw/.ramfs | cut -d’ ‘ -f5)” != “0” && echo ‘Alarm!!! File size of /lib/init/rw/.ramfs does not equal 0 Byte!!!!’

    Thanks for the hint.

  2. Hi there,

    I stumbled upon your blog when I noticed these messages from chrootkit. I had a quick look at your patch and to me it seems a bit weird to hard code the ‘/lib/init/rw/.ramfs’. I can imagine that a root kit author would now use this as a rather convenient place to store its data and using your patch chrootkit would not notice this. Or did I not understand your patch correctly?

  3. I think this is a workaround. And from a security POV: There are tons of other possible filenames an attacker could use so chkrootkit would not notice.

    Why should an attacker use ‘/lib/init/rw/.ramfs’ now if he could use ‘/etc/hosts’ for example?
    Or ‘/lib/init/rw/myrootkitdata’?

  4. Instead of:

    -and -not -wholename /lib/init/rw/.ramfs

    another alternative would be to use:

    -and -not -empty

    This would ignore any empty dot files. This will not ignore empty dot directories, like ones create by Java.

Leave a Reply

Your email address will not be published. Required fields are marked *