[VulnWatch] The ScrollKeeper Root Trap

From: Spybreak (spybreak@host.sk)
Date: 09/02/02

Date: Mon, 2 Sep 2002 14:02:12 +0200 (CEST)
From: Spybreak <spybreak@host.sk>
To: <vulnwatch@vulnwatch.org>

Release date : September 2 2002
Author : Spybreak (spybreak@host.sk)
Package : Scrollkeeper
Version : 0.3.4, 0.3.11
Severity : Medium to High
Vendor homepage : scrollkeeper.sourceforge.net
Status : vendor contacted
Problem : Insecure creation of tempfiles in /tmp
Local : yes
Remote : no


ScrollKeeper is a system for managing document metadata. Its primary function
is to act as a card catalog for documents, keeping track of what documents
are available, where they can be found, and various attributes of the
documents such as their language, format, subject, version, and position in
a contents list. It also manages other metadata such as document indices.

ScrollKeeper acts as a middle layer between applications and help browsers.
When applications install documentation, the documentation is registered
with ScrollKeeper. Any ScrollKeeper-aware help browser on the system can then
access this information. In this way, ScrollKeeper is a compatibility layer
which allows any help browser to interface to all the documentation on
a system, provided the package which ships the documentation registers it
with ScrollKeeper.


The ScrolKeeper package contains a program named scrollkeeper-get-cl
that is called through other auxilliary programs by ScrollKeeper-aware
browsers to get a category tree.

The content list is then passed to the requestor through tempfiles in the
/tmp directory.

Unfortunately, there are no security checks when the content list is
written. Since the files are written with the rights of the requestor,
her files can be overwritten or new files created.


Example of root exploitation for ScrollKeeper 0.3.4 on Red Hat 7.3,
default install:

First, scrollkeeper-get-cl is called everytime the Nautilus browser is
started. Second, to start the Nautilus browser on the X startup is
a default behavior on RH 7.3.

The ScrollKeeper cycles through five temporary filenames (slots) of the
form /tmp/scrollkeeper-tempfile.{0,1,2,3,4} and uses the first one that
does not exist or the oldest one.
As we have little control over what is written into the tempfiles, we have
to exploit the fact, that we can create a file with name we choose,
anywhere on the filesystem.

Link like this does the work:

ln -s /etc/log.d/scripts/logfiles/xferlog/'`useradd -rou0 -g0 -p "" cuckoo`'

Remember, Logwatch is our friend, still.
In fact, our scrollkeeper-tempfile.x slot will be the one used by
ScrollKeeper, if x has a value 0 or 1, or the previous slots have an
ascending c-times. It's because our symlink pointing to a nonexisting
file is always considered to be an empty slot, since stat is used for
status checking instead of lstat.

Two problems arise:

a) lack of free slots
b) we need a privileged user to make an X session


a) since the ScrollKeeper does not any cleanup of these files
   it can be a problem but tmpwatch is our friend too, everything depends
   on the X login activity; many admins clean their /tmp dir by custom
   scripts on every system startup
b) using X window system as root is a really silly behavior,
   but it happens too often; the /var/log/wtmp* files and a quick
   check on the presence of some X-Files ;-) in the /tmp directory
   may give a clue about such behavior


Upgrade to the latest, patched version.


The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2002-0662 to this issue.

Public key: