[SRU] chkrootkit falsely flags files owned by Firefox 3 and Sun Java 6 valid packages

Bug #575945 reported by Fabián Rodríguez on 2010-05-05
This bug affects 2 people
Affects Status Importance Assigned to Milestone
chkrootkit (Ubuntu)
Marc Deslauriers

Bug Description

Binary package hint: chkrootkit

Id like to request an SRU for this package.

IMPACT: It produces false positives for common desktop applications. chkrootdisk is suggested as one of many security tools to install in our official docs:

HOW IT S BEEN ADRESSED: This is a know issue that has been addressed in the next version that came out. Specifically, an option has been added to ignore false positives (#406493, #426068 according to changelog for version 0.48-5).

Steps to reproduce:
- Make sure Firefox 3 and Sun Java JRE 6 are installed (firefox-3.0 sun-java6-jre)
- Install chkrootkit
- sudo chkrootkit -q

The following suspicious files and directories were found:

/usr/bin/find: //home/charles/.gvfs: Permission denied
/usr/bin/find: //home/charles/.gvfs: Permission denied
eth0: PACKET SNIFFER(/sbin/dhclient3[12893])

ProblemType: Bug
Architecture: i386
Date: Wed May 5 14:28:57 2010
DistroRelease: Ubuntu 8.04
Package: chkrootkit 0.47-1.1ubuntu0.1
PackageArchitecture: i386
SourcePackage: chkrootkit
Uname: Linux 2.6.24-27-generic i686

Fabián Rodríguez (magicfab) wrote :
Changed in chkrootkit (Ubuntu):
assignee: nobody → Marc Deslauriers (mdeslaur)

Confirming; the same can be seen on my system. However, given that these are false positives, and *some* false positives are to be expected when dealing with security testing software, setting prioriy to Low.

Fabián, if you feel this needs to be re-evaluated, don't hesitate to bring it up :)

Changed in chkrootkit (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Marc Deslauriers (mdeslaur) wrote :

This is a well-known issue, and is mentioned in /usr/share/doc/chkrootkit/README.FALSE-POSITIVES and in the upstream FAQ: http://www.chkrootkit.org/faq/#8

Simply put, chkrootkit should not contain a whitelist of acceptable dotfiles by default, as a rootkit could simply use the files listed in the whitelist as known good hiding places.

That being said, the newer Debian/Ubuntu packages contain a patch that adds a "-e" option that lets administrators add their own whitelist. I think this is a reasonable idea and it should be included in the hardy package so chkrootkit can be used by system admins without constantly getting false positives.

Marc Deslauriers (mdeslaur) wrote :

I have uploaded chkrootkit packages for hardy that contain the patch to my PPA here:


Please test and leave feedback. Once it's been tested, I'll start the SRU procedures, although it may not be accepted.

Changed in chkrootkit (Ubuntu):
status: Confirmed → Incomplete
Jonathan Davies (jpds) wrote :

The package in the PPA works as expected.

Jonathan Davies (jpds) on 2010-06-02
Changed in chkrootkit (Ubuntu):
status: Incomplete → Confirmed
Marc Deslauriers (mdeslaur) wrote :

SRU Request:

Impact: chkrootkit tool reports false positives in hardy, and the option to ignore certain known false positives is only present in later versions. This impacts the usefulness of the tool.

This has been addressed by backporting the "-e" option from the newer release to let administrators set a whitelist.

A minimal debdiff is attached.

summary: - chkrootkit falsely flags files owned by Firefox 3 and Sun Java 6 valid
- packages
+ [SRU] chkrootkit falsely flags files owned by Firefox 3 and Sun Java 6
+ valid packages

Accepted chkrootkit into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in chkrootkit (Ubuntu Hardy):
status: New → Fix Committed
tags: added: verification-needed
Jean-Baptiste Lallement (jibel) wrote :

SRU Verification Hardy

I've verified that the version 0.47-1.1ubuntu0.2 in -proposed ignores files in the exclusion list with the -e option. My only concern is a documentation issue because the new option is not documented in the manpage. Could you please update it too ?

2 other comments but unrelated to the SRU since it's in Maverick too and should be reported upstream:
1. Misleading documentation: -e requires a list of files/dirs (only -e without argument is specified in --help and man)
2. When -e is used without argument, it displays a meaningless error 'shift: 2659: can't shift that many'

Jean-Baptiste Lallement (jibel) wrote :

Bug 597623 filed for the last 2 points.

Marc Deslauriers (mdeslaur) wrote :

Thanks for the verification Jean-Baptiste. I have uploaded 0.47-1.1ubuntu0.3 to -proposed with the suggested manpage change.

Martin Pitt (pitti) wrote :

Version 0.47-1.1ubuntu0.3 accepted into hardy-proposed which adds the manpage option. Please check and report back here. Thanks!

Verification-done in hardy with 0.47-1.1ubuntu0.3 in -proposed.
Many thanks for the update Marc.

tags: added: verification-done
removed: verification-needed
Martin Pitt (pitti) wrote :

According to the bug trail this is fixed in jaunty and above.

Changed in chkrootkit (Ubuntu):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package chkrootkit - 0.47-1.1ubuntu0.3

chkrootkit (0.47-1.1ubuntu0.3) hardy-proposed; urgency=low

  * debian/chkrootkit.1: Added -e option to manpage, as suggested by
    SRU verification. (LP: #575945)
 -- Marc Deslauriers <email address hidden> Wed, 23 Jun 2010 08:26:53 -0400

Changed in chkrootkit (Ubuntu Hardy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers