2

I did a rootkit search with chkrootkit and it came up with this strange set of files: 

/usr/lib/debug/.build-id 
/lib/modules/4.4.0-51-generic/vdso/.build-id 
/lib/modules/4.4.0-47-generic/vdso/.build-id 
/lib/modules/4.4.0-38-generic/vdso/.build-id 
/lib/modules/4.4.0-36-generic/vdso/.build-id 
/lib/modules/4.4.0-45-generic/vdso/.build-id
/usr/lib/debug/.build-id 
/lib/modules/4.4.0-51-generic/vdso/.build-id 
/lib/modules/4.4.0-47-generic/vdso/.build-id 
/lib/modules/4.4.0-38-generic/vdso/.build-id 
/lib/modules/4.4.0-36-generic/vdso/.build-id 
/lib/modules/4.4.0-45-generic/vdso/.build-id

What exactly are these? I'm fairly certain they're all false positives, but I still don't know what they are and why they're there. I did a bit of search and it looks like these are kernel images left behind from previous updates.

So why are they setting off a false positive and how do I get rid of them?

Astrum
  • 151

2 Answers2

1

/lib/modules/ is the directory to store modules. The next bit (with the digits) is the kernel number these modules belong to.

vdso in the name of the module (it stands for virtual dynamic shared object). Your system does a lot of "system calls" (like reading and writing to disk, grant permissions, etc) and it takes up a lot of resources to perform each of these. But those calls are also done a lot. The vdso module was created to help improving the time needed by allocating memory for them.

From wikipedia:

vDSO (virtual dynamically linked shared object) is a Linux kernel mechanism for exporting a carefully selected set of kernel space routines to user space applications so that applications can call these kernel space routines in-process, without incurring the performance penalty of a context switch that is inherent when calling these same kernel space routines by means of the system call interface.

Some more information on this:

  • gitbooks: part 1, part 2, part 3 all about system calls. Part 2 is about "vdso" and "vsyscall".

I'm fairly certain they're all false positives

Probably (as with 99.999999% of all those rootkits notices ;) ) but you probably need to compare these files with a clean system and check things like file size, last modification times to visually check if this is a false positive.

By the way: the /lib/modules/ directory can get large quickly. It is safe to remove old kernels (save the current and the next least oldest just to make sure you got a backup). See: How do I remove old kernel versions to clean up the boot menu?

Removing the older version also lowers the amount of notices from your rootkit ;)

Community
  • 1
Rinzwind
  • 299,756
  • Yeah, these were all last modified months ago when I updated, so they're false positives. Now, is it possible to just delete them directly from the folder, or should I use the program in the link you posted (synaptic)? – Astrum Dec 03 '16 at 07:22
  • You need to follow a "how to delete old kernels" method (synaptic is not really needed for this; there are other methods) Otherwise you remove parts of the kernel and have leftovers elsewhere :) – Rinzwind Dec 03 '16 at 08:33
  • Do you have any idea why this might set off chkrootkit? I'm not really sure how it works, but maybe that's another post. – Astrum Dec 03 '16 at 22:53
0

I saw these on a rootkit scan of a test VM (ubuntu 18.04 LTS), and deleted them. No noticeable side effects on the system, although they appear to be in use by the OS as it is repopulated on a reboot.

David Ross
  • 11