Saturday, February 26, 2011

pcscd now uses libudev instead of libhal

pcsc-lite first started (in the previous century) when only serial readers were in use. The serial readers are configured using the /etc/reader.conf file. The problem is that the configuration is static and can't be used with a USB reader.

History of USB plug-n-play mechanism


To detect the insertion or removal of a USB reader different mechanisms have been used in the last 10 years.

Linux


hotplug_linux.c: introduced at least in (or before) version 1.0.2beta2 (20 Dec, 2001).

The problem is that the code is Linux specific.

libusb


hotplug_libusb.c: introduced in version 1.2.0-rc1 (26 August, 2003). From the changelog:
- src/hotplug_libusb.c: Add support of libusb. Allow to use USB readers on
*BSD or any plateform supported by libusb. Thanks to Toni Andjelkovic for
the great job.
The problem of libusb is that pcscd is constantly polling the USB bus to detect reader hotplug.

libhal


hotplug_libhal.c: introduced in version 1.4.100 (23 March 2008). From the changelog:

- add libhal support to avoid polling the USB bus.  libusb is still
  supported but libhal is now the default

The problem is that libhal has been deprecated upstream in May 2008 (2 months after pcscd started using it). Some distributions are actively migrating out of libhal. See Debian bug #587979
"pcscd: uses deprecated HAL" for example. And the wiki page "HALRemoval".

libudev


hotplug_libudev.c: introduced in version 1.6.8 (not yet released as of February 2011).

It looks like libudev is a good choice for the future. I don't know if it is supported by other systems than GNU/Linux. I removed the support of libhal but support of libusb is still present.

Mac OS X


Mac OS X has its own hotplug mechanism in hotplug_macosx.c. Apple maintains its own forked version of pcsc-lite. So I do not plan to change anything Mac OS X specific in pcsc-lite.

Conclusion


The hotplug mechanism is a fast moving target on GNU/Linux. I hope libudev will last at least a few months before I have to move to something else.

Flattr this

Wednesday, February 23, 2011

New version of libccid: 1.4.2

I just released a new version of libccid.

Changelog

1.4.2 - 22 February 2011, Ludovic Rousseau

  • Add support of Feitian SCR310 reader (also known as 301v2), ACS
    APG8201 PINhandy 1, Oberthur ID-ONE TOKEN SLIM v2, new Neowave
    Weneo token, Vasco DIGIPASS KEY 860, Vasco DIGIPASS KEY 200,
    Xiring Leo v2, Xiring MyLeo, Aktiv Rutoken lite readers
  • Add back support of "bogus" Oz776, REINER SCT and BLUDRIVE II
  • Ease detection of OpenCT by pcsc-lite
  • disable use of interrupt card events for multi slots readers (the
    algorithm is bogus and can't be used)
  • fix minor problems detected by the clang tool
  • some minor bugs removed

New version of pcsc-lite: 1.6.7

I just released new version of pcsc-lite 1.6.7.

pcsc-lite-1.6.7: Ludovic Rousseau
22 February 2011
  • better Mac OS X support
  • Fix Alioth bug [#312960] "SCardDisconnect when other context has transaction"
  • add a API tracing feature in the client side (#define DO_TRACE)
  • allow the use of tracing and profiling features from different
    application threads
  • fix a problem with a multi-slots reader
  • fix minor problems detected by the clang tool
  • some other minor improvements and bug corrections

The next version of pcsc-lite should use libudev instead of the deprecated libhal.

Monday, February 7, 2011

pcsc-lite: arbitrary code execution

LWN published a message about "pcsc-lite: arbitrary code execution":

pcsc-lite: arbitrary code execution


Package(s):pcsc-lite CVE #(s):CVE-2010-4531
Created:January 14, 2011 Updated:February 3, 2011
Description: From the Red Hat bugzilla:
A stack-based buffer overflow flaw was found in the way
PC/SC Lite smart card framework decoded certain attribute
values of the Answer-to-Reset (ATR) message, received back
from the card after connecting. A local attacker could
use this flaw to execute arbitrary code with the privileges
of the user running the pcscd daemon, via a malicious smart
card inserted to the system USB port.
Alerts:
Fedora FEDORA-2011-0164 2011-01-05
Fedora FEDORA-2011-0123 2011-01-05
Mandriva MDVSA-2011:015 2011-01-20
Debian DSA-2156-1 2011-01-31
openSUSE openSUSE-SU-2011:0092-1 2011-02-02
Pardus 2011-24 2011-02-02


The description of the bug is correct (this time). But I am not sure it would be possible to execute arbitrary code. The ATR is still limited to MAX_ATR_SIZE=33 bytes.

The bug was fixed on 3rd November 2010 in revision 5370 more than a month before MWR published a InfoSecurity Security Advisory PCSC-Lite: pcscd ATR Handler Buffer Overflow on 13th December 2010.

Debian 6.0 was released just yesterday. The pcscd package in this version contains the fix.


Flattr this

ccid: arbitrary code execution

LWN published a message about "ccid: arbitrary code execution":

ccid: arbitrary code execution


Package(s):ccid CVE #(s):CVE-2010-4530
Created:January 14, 2011 Updated:February 3, 2011
Description: From the Red Hat bugzilla:
An integer overflow, leading to array index error was found
in the way USB CCID (Chip/Smart Card Interface Devices) driver
processed certain values of card serial number. A local attacker
could use this flaw to execute arbitrary code, with the privileges
of the user running the pcscd daemon, via a malicious smart card
with specially-crafted value of its serial number, inserted to
the system USB port.
Alerts:
Fedora FEDORA-2011-0162 2011-01-05
Fedora FEDORA-2011-0143 2011-01-05
Mandriva MDVSA-2011:014 2011-01-20
openSUSE openSUSE-SU-2011:0092-1 2011-02-02
Pardus 2011-22 2011-02-02

The description of the problem is not exact. The problem is present in file ccid/src/ccid_serial.c and only impacts the GemPC Twin connected to a serial port.

The bug was fixed on 5th November 2010 in revisions 5381 and 5382, more than a month before MWR published a InfoSecurity Security Advisory PCSC-Lite: libccid Buffer Overflow on 13th December 2010.

Debian 6.0 was released just yesterday. The libccid package in this version contains the fix. Debian did not released a Debian Security Advisory because the bug is minor.


Flattr this