chkrootkit kills random processes

Thanks for taking the time to report this bug and helping to make Ubuntu better. I have marked it as public, since it is not a private issue. Additionally, this has already been fixed in the development release (which has chkrootkit 0.48-5). Please feel free to report any other bugs you may find.

Hi Kees,

Thanks for your prompt attention. Just to clarify my possible misunderstanding, does "Status: New => Invalid" mean this won't get fixed in Hardy?

Hardy is supposed to be an "LTS" release and we plan to stick with it for a couple years, so this being already fixed in the development release (presumably Intrepid?) is wonderful but meanwhile what are Hardy users to do? Because random processes get killed (and we have already seen this happen to one of our user stations and one of our servers), I believe this should be considered a security issue in Hardy and fixed in Hardy.

(Perhaps you're already planning to do so, and I misunderstood the meaning of "Status: New => Invalid".)

Thanks.
Alexander

----- Original Message ----
From: Kees Cook <email address hidden>
To: <email address hidden>
Sent: Tuesday, October 7, 2008 11:40:20 AM
Subject: [Bug 279752] Re: chkrootkit kills random processes

Thanks for taking the time to report this bug and helping to make Ubuntu
better. I have marked it as public, since it is not a private issue.
Additionally, this has already been fixed in the development release
(which has chkrootkit 0.48-5). Please feel free to report any other
bugs you may find.

** Changed in: chkrootkit (Ubuntu)
     Assignee: (unassigned) => Kees Cook (kees)
       Status: New => Invalid

** Visibility changed to: Public

--
chkrootkit kills random processes
https://bugs.launchpad.net/bugs/279752
You received this bug notification because you are a direct subscriber
of the bug.

Status in “chkrootkit” source package in Ubuntu: Invalid

Bug description:
To test for Enye LKM, chkrootkit 0.47-1.1 blindly sends a signal to PID 12345 without regard as to what might be running at PID 12345, which might be a crucial daemon related to system security or system access. It is common to run chkrootkit on a regular basis as a cron job. Because of the potential to randomly kill an important process, this should be considered a security bug.

This has been fixed in Debian chkrootkit 0.47-2. See Debian bug report #421864, and also Debian bug report #457828.

I suggest Ubuntu make the same fix and get it into the security updates for hardy. Thanks!

Sorry for the confusion. This bug seems relatively minor and probably doesn't qualify for an SRU[1] for previous stable releases. If you need this bug fixed in a stable version of Ubuntu, please follow the instructions for getting a backported package via "How to request new packages" at https://help.ubuntu.com/community/UbuntuBackports#request-new-packages

[1] https://wiki.ubuntu.com/StableReleaseUpdates

Kees wrote:
> [...] This bug seems relatively minor

I respectfully disagree. Users expect a stable system to be, umm, stable. When applications randomly quit and cause data loss, this is hardly stable. Novice users concerned about security might blindly install chkrootkit based on a friend's tip, and system administrators responsible for lots of enduser systems might systematically install chkrootkit to keep an eye on things; in both cases, the goal is increased security; instead, there is increased risk.

How big is that risk? An assessment appears in the first report for Debian bug 457828:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457828

My own anecdotal evidence: we have been running Ubuntu Hardy with chkrootkit on about 40 systems for a couple months, and this bug has struck us at least twice.

Although it hasn't happened to me, imagine it were to kill sshd on a server to which you do not have physical access, or were to kill apache on a production webserver? What if it kills syslog or an intrusion detection system? Sure, the chance that a random process sitting at PID 12345 is also a security-related process is low; nonetheless, that chance is non-zero. This is why I suggested a fix go into ubuntu-security.

The chance of this bug simply hitting an application and causing user data loss or unexpected behavior is higher. So if you won't elect this for ubuntu-security, it seems it should at least go into ubuntu-updates. I base these thoughts on the following excerpt from https://help.ubuntu.com/community/UbuntuBackports :

-backports vs -proposed/-updates/-security
==============================
-Security offers patches for security vulnerabilities in Ubuntu packages. They
are managed by the Ubuntu Security Team and are designed to change the
behavior of the package as little as possible -- in fact, the minimum
required to resolve the security problem. As a result, they tend to be
very low-risk to apply and all users are urged to apply security
updates.
-Updates offers patches for serious bugs in Ubuntu packaging that do not affect
the security of the system. More directly, serious bugs are bugs that
can directly cause loss of user data or represent a severe deviance
from expected behavior. These updates are held up to similarly strict
quality assurance as -security, in that the patches must be the minimum
amount of change required to fix the bug. The fixes must be documented
and verified by QA testers before they are accepted. These should also
be low-risk to breakage and users are recommended to install them as a
part of a regular update, or pick updates to bugs that affect them.

> and probably
> doesn't qualify for an SRU for previous stable releases.

From https://wiki.ubuntu.com/StableReleaseUpdates I would say the following excerpts are appropriate here:

Why
===
Users of the official release, in contrast, expect a high degree of
stability. They use their Ubuntu system for their day-to-day work, and
problems they experience with it can be extremely disruptive. Many of
them are less experienced with Ubuntu and with Linux, and expect a
reliable system which does not require their intervention.

When
====
    * Bugs ...

(Note: I am the Debian maintainer for chkrootkit)

Hi Alexander, I have just built a fixed package for Hardy in my PPA:

  deb http://ppa.launchpad.net/fmarier/ubuntu hardy main

Could you try it out and let me know if you think it's fine.

I have attached a debdiff between the package that's in Hardy and the one I just built. As you can see, this is a trivial fix and I can't see it having any impact at all on the rest of the package.

Aside from the patch being safe, I think that this fix would qualify for a Stable Release Update since the problem that Alexander reported could lead to loss of user data depending on which process is actually killed by chkrootkit (for example, a mail server, open office, etc.).

This is fixed in the version of chkrootkit that's in intrepid, so it's only a problem for the current LTS release of Ubuntu.

I can see your point. If you can follow the security update procedure and produce a tested debdiff (or find someone to do this for you), this can get fixed and uploaded. I've added a Hardy task for it.

https://wiki.ubuntu.com/SecurityUpdateProcedures

On Tue, Oct 07, 2008 at 09:01:03PM -0000, Alexander Perlis wrote:
> I am instead suggesting that chkrootkit 0.47-1.1 in Hardy receive a
> security update just to fix this bug and make no other changes. This
> matches what happened in Debian stable, when 0.47.1.1 was replaced with
> 0.47-2.

As a side note, 0.47-2 got many other changes besides just the fix for
the Enye test. For a security update, the changes must be limited only
to the specific problem. SRUs are generally more appropriate for minor
version changes, but it will still require a debdiff and getting the
MOTU SRU team's approval.

@François: thanks! I'm happy to take this via -security, it's a very small fix. :)

I've (slightly adjusted the debdiff and) uploaded this to the security queue. It should be built and published shortly. Thanks!

My claim that this bug fix is the only change from Debian 0.47-1.1 to 0.47-2 was based on the Debian Changelog for 0.47-2. I didn't examine the source, and apologize if my report was misleading.

At any rate, thank you Francois for providing the diff, and thank you Kees for your attention and consideration to my attempt to persuade, and thank you especially for accepting the diff into security. Much appreciated!