Bug 383131 (CVE-2007-6131) - CVE-2007-6131 scanbuttond: unsafe usage of temporary files in buttonpressed.sh
Summary: CVE-2007-6131 scanbuttond: unsafe usage of temporary files in buttonpressed.sh
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2007-6131
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Parag AN(पराग)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-14 19:22 UTC by Michal Jaegermann
Modified: 2019-09-29 12:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-28 06:13:14 UTC
Embargoed:


Attachments (Terms of Use)
the most pressing security fixes (1.50 KB, patch)
2007-11-23 05:28 UTC, Michal Jaegermann
no flags Details | Diff

Description Michal Jaegermann 2007-11-14 19:22:44 UTC
Description of problem:

scanbuttond, as packaged, runs as a root owned process.  Despite of
that in /etc/scanbuttond/buttonpressed.sh one can find

TMPFILE="/tmp/scan.pnm"
TMPJPGFILE="/tmp/scan.jpg"

Not even a need to race to guess those file names and that script,
executed by scanbuttond, writes there.  Security implications are
obvious and 'mktemp' exists for a reason.  As things stand now there
is not even a feeble attempt to remove possibly existing files/links
before trying to write to those.

Moreover 'cleanup' function is not trapped which means that there
will be leftovers on an abnormal exit.  At least something of
that sort should be present

trap 'cleanup; exit'  TERM INT QUIT KILL EXIT

before any of temporaries are created.

On the top of all the above it is highly doubtful that this script
should be run by root as one of system services.  Do you really want
to try to run on a root behalf things like
editcmd() {
    gimp $TMPFILE
}
or send some email with attachments?   I guess that one of simple
possible solutions would be to add a startup file in /etc/profile.d/
which would check for a presence of $DISPLAY (does not seem to much
point of running that otherwise in general - at least without writing
quite a different script) and that other instance of scanbuttond is not
already running and launch that for a user.  Other possibilty which
comes to mind is to register a startup as one of seesions scripts.

Version-Release number of selected component (if applicable):
scanbuttond-0.2.3-10.fc7

Comment 1 Parag AN(पराग) 2007-11-22 09:49:05 UTC
thanks for your feedback and questions.
Actually I don't have any scanner now with me. For some work I was needed this
package in Fedora so I added it. Then I got some other work and lost my interest
in this package as I also not got any kind of feedback for this package from
anyone. 
But good to see your feedback. Will work on that.

Comment 2 Michal Jaegermann 2007-11-23 05:28:54 UTC
Created attachment 267351 [details]
the most pressing security fixes

The most urgent security horrors should be taken care by the following
trivial patch.	Before that patch you can overwrite with this script
any file on a system.  Nice!

This is not doing anything for that detail that scripts here are
running with a wrong owner as 'root' is surely not that.  Also instead
of hardwiring names of some programs, say for a particular mail user
agent, facilities like xdg-open or xdg-email should be used instead.

Comment 3 Tomas Hoger 2007-11-23 20:19:38 UTC
Wow, this sounds scary...

I do not have scanner to play with to verify these issues.  Parag, Michal, can
scanbuttond be run under unprivileged user and still work correctly (asking
mainly with respect to device files permissions)?

Have you verified whether apps like gimp or thunderbird can really be started
from scanbuttond?  I suspect that may be prevented by unset DISPLAY for example.
 However, starting those apps under root user and allowing unprivileged user to
control them has also significant security impact.


Comment 4 Michal Jaegermann 2007-11-23 23:02:41 UTC
> Parag, Michal, can
> scanbuttond be run under unprivileged user and still work correctly

Well, I do not have a scanner of that type either.  I looked at
scanbuttond as a workaround for bugs in USB support which made
a scanner of a friend to "warm up" all the time.  It mostly worked
in that role.  That friend does not care about buttons.  Try
http://www.google.com/linux?hl=en&q=%22scanner+warming+up%22+snapscan&btnG=Search&meta=
for some problem samples. Also
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/85488

Actually scanbuttond to service buttons _has to_ run with an id
of a console owner (the same way as xsane does).  You definitely
do not want for root to edit your pictures (after all an ownership
will be wrong) or send your mail. Using root too feed something
from a scanner to your printer also does not sound like a good
proposition.  With a correct configuration a scanner device is
read-write for a console owner so this is not a problem.

As a session program scanbuttond should work, although I have no
idea how to make a package to register it that way or how to deal
with KDE.  You cannot use the current /etc/rc.d/init.d/scanbuttond
to start it that way, though, as this tries to write to
/var/lock/subsys/scanbuttond and that is priviledged.

Comment 5 Tomas Hoger 2007-11-27 11:44:27 UTC
This issue was assigned CVE id CVE-2007-6131.

buttonpressed.sh in scanbuttond 0.2.3 allows local users to overwrite
arbitrary files via a symlink attack on the (1) scan.pnm and (2)
scan.jpg temporary files.

Comment 6 Tomas Hoger 2007-11-27 17:01:01 UTC
After some more test it seems that problem with gimp or thunderbird started
under root is prevented by unset DISPLAY, if scanbuttond is started during
system boot-up.

(In reply to comment #4)
> As a session program scanbuttond should work, although I have no
> idea how to make a package to register it that way or how to deal
> with KDE.  You cannot use the current /etc/rc.d/init.d/scanbuttond
> to start it that way, though, as this tries to write to
> /var/lock/subsys/scanbuttond and that is priviledged.

I'm not sure what is the best and desktop environment / window manager
independent way of starting it as a session program.  Adding script to
/etc/X11/xinit/xinitrc.d/ may be one of the options.  It should also be
investigated how to correctly deal with multiple X sessions / fast user switching.



Comment 7 Tomas Hoger 2007-11-28 09:48:51 UTC
Using /etc/xdg/autostart/ and ~/.config/autostart/ should probably be considered:

http://standards.freedesktop.org/autostart-spec/autostart-spec-0.5.html

(Not sure how it's supported in non-KDE and non-GNOME window managers.)


Comment 8 Parag AN(पराग) 2007-12-17 04:50:42 UTC
as I don't have scanner now and not getting time to work on this issue I will be
happy to see any one co-maintaining this package and will be happy him to fix
this issue.

Comment 9 Bug Zapper 2008-05-14 15:03:33 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Michal Jaegermann 2008-05-14 15:43:07 UTC
> This message is a reminder that Fedora 7 is nearing the end of life.

I see the same

TMPFILE="/tmp/scan.pnm"
TMPJPGFILE="/tmp/scan.jpg"

in scanbuttond-0.2.3-12.fc9 with a "Build Date: Sat 09 Feb 2008 09:00:08 AM MST".
Should a "Product" tag on this report be changed to "Security Response"?

Comment 11 Tomas Hoger 2008-05-16 17:57:00 UTC
Moving to Security Response to prevent further harm from BugZappers.

Comment 12 Parag AN(पराग) 2010-01-28 06:13:14 UTC
Retired this package from Fedora rawhide/13 now. Sorry to say but I have no time to test changes needed here.


Note You need to log in before you can comment on or make changes to this bug.