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.
Adding upstream...
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.
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.
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.
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.
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.
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.
(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.
Today is the release of F-11. Do we have a 0-day update ready to go?
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
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.
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
Update posted to rawhide. and requested for F-11.
It may not be necessary if the directories are removed on shutdown. Thanks.
Why is this bug still private when it is already public? http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-June/003741.html
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.