Bug 503211 - pcscd creates a world writable directory
pcscd creates a world writable directory
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: pcsc-lite (Show other bugs)
11
All Linux
urgent Severity medium
: ---
: ---
Assigned To: Bob Relyea
Fedora Extras Quality Assurance
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-29 12:36 EDT by Tomas Mraz
Modified: 2009-06-19 09:34 EDT (History)
5 users (show)

See Also:
Fixed In Version: 1.5.2-2.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-19 09:34:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Mraz 2009-05-29 12:36:04 EDT
I've run sectool on a F11 machine and it found that there is a world writable /var/run/pcscd.events subdirectory.

ls -ld /var/run/pcscd.events/
drwx-wx-wx. 2 root root 4096 2009-05-29 14:50 /var/run/pcscd.events/

I suppose it was created by pcscd.

This is clearly a security problem, please fix it.
Comment 3 Bob Relyea 2009-05-29 16:47:28 EDT
Adding upstream...
Comment 4 Ludovic Rousseau 2009-05-30 07:47:18 EDT
This directory is world writable by design.

I need a way for a client to wait for events. Events are sent by the pcscd daemon and in one case by another thread of the same client application.
To do that the client creates a pipe in /var/run/pcscd.events/
 and blocks on a select() call. pcscd can write one byte to the pipe to unblock the client. pcscd then removes the pipe.

If you have a better/safer and portable way to do that I am ready to change my code.
Comment 5 Tomas Mraz 2009-06-01 02:32:40 EDT
You can either create the pipe in /tmp or you could use dbus.
There is no need to create a special world writable subdirectory for that.
Comment 6 Ludovic Rousseau 2009-06-01 03:19:06 EDT
Why is it a security problem in /var/run/pcscd but not in /tmp?

dbus is not really an option since I want to be able to run pcsc-lite on *BSD, Solaris, Mac OS X.
Comment 7 Tomas Mraz 2009-06-01 04:15:42 EDT
The problem is not creating the pipes (if it is done properly) but that the daemon is creating a world-writable directory without consent of the administrator and without a sticky bit set.

Another possibility is to create a unix socket in the daemon (with the listen/accept) and clients can connect to it. Then the clients will not have to create inodes anywhere.
Comment 8 Ludovic Rousseau 2009-06-01 05:22:14 EDT
With SVN revision 4237 the directory is created with the sticky bit.
http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-June/003741.html

I will think about using unix sockets. Thanks.
Comment 9 Steve Grubb 2009-06-01 08:48:12 EDT
when this gets re-packaged, the specfile should own the directory /var/run/pcscd.events/ and explicitly set the permissions to 1733 so that anyone who doesn't do the 0day update right away gets the permissions corrected.

A note for the upstream developers, in winscard_clnt.c, there is a call to mkfifo that is not checked to see if it succeeds and then a write without checking to see if what was opened was really a fifo. Everywhere else a check is made before trusting the pipe with data. Thanks.
Comment 10 Ludovic Rousseau 2009-06-02 02:47:53 EDT
(In reply to comment #9)
> A note for the upstream developers, in winscard_clnt.c, there is a call to
> mkfifo that is not checked to see if it succeeds

Corrected in SVN revision 4238.

> and then a write without
> checking to see if what was opened was really a fifo. Everywhere else a check
> is made before trusting the pipe with data. Thanks.  

I don't think that check is needed. It is not a write but a read. If mkfifo(3) succeeds then the created file is a pipe.

An intruder may change the file between mkfifo() and open() to something else. But I don't see how to get more priviledges with that:
- the process executing the code in winscard_clnt.c has, in general, no priviledge
- the process will call read() and unlink() on the file.
Comment 11 Steve Grubb 2009-06-09 07:46:49 EDT
Today is the release of F-11. Do we have a 0-day update ready to go?
Comment 12 Noura El hawary 2009-06-09 17:48:28 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Steve Grubb 2009-06-17 08:43:36 EDT
Reclassifying this bug to urgent. We are well past GA and there doesn't appear to be any updates on this bug. Patches are upstream and can be applied. At this point since we are so far from GA, there are likely to be many people with world writable directories without the sticky bit set. So the post install scripts should chmod the directory to make sure this is fixed.
Comment 14 Bob Relyea 2009-06-17 13:55:55 EDT
re comment 9:

Steve, is this necessary? The directory is removed when the daemon is shutdown, so simply restarting the daemon (or the system) would cause the permissions to be updated.

I've verified the directory gets changed by simply installing the package.

bob
Comment 15 Bob Relyea 2009-06-17 14:24:59 EDT
Update posted to rawhide. and requested for F-11.
Comment 16 Steve Grubb 2009-06-17 14:29:42 EDT
It may not be necessary if the directories are removed on shutdown. Thanks.
Comment 17 Eugene Teo (Security Response) 2009-06-17 21:13:25 EDT
Why is this bug still private when it is already public? http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-June/003741.html
Comment 18 Fedora Update System 2009-06-19 09:34:25 EDT
pcsc-lite-1.5.2-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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