Possible data truncation on receive in 1.8.14

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible data truncation on receive in 1.8.14

Marcin Cieslak-3
Hello,

My setup (FreeBSD+OmniKey 4040 PCMCIA+OpenCT IFD) started
having trouble after 1.8.14 upgrade (truncated responses
from the card terminal that didn't end with 90 00).

The problem turns out is that the receive buffer size
is now 65548 bytes on my platform,
and my configuration seem to return only
12 bytes with such a large buffer.

More details:

https://alioth.debian.org/tracker/index.php?func=detail&aid=315230&group_id=30105&atid=41008

The patch is attached:

https://alioth.debian.org/tracker/download.php/30105/410087/315230/6941/0001-SCardTransmit-Use-supplied-receive-buffer-length.patch

and also inline below.

All the best,

Marcin


From 31d3c31514a3da27b117bcfc5c0de781ed2ea1fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marcin=20Cie=C5=9Blak?= <[hidden email]>
Date: Fri, 13 Nov 2015 12:30:05 +0100
Subject: [PATCH] SCardTransmit: Use supplied receive buffer length

After 8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7
the receive buffer size is always
set to sizeof pbRecvBuffer, even if the client
supplies a smaller size.

For Ominkey 4040 PCMCIA connected via OpenCT
ifdhandler this value (65548) is too large, and
returns only 12 bytes of data.

Since we already checked for the buffer overflow
above, it is safe to use a client-supplied
receive buffer size.

Additionally log the receive buffer size used
in SCardTransmit.
---
 src/winscard.c     | 1 +
 src/winscard_svc.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/winscard.c b/src/winscard.c
index 67eb9b0..e18e5f5 100644
--- a/src/winscard.c
+++ b/src/winscard.c
@@ -1604,6 +1604,7 @@ LONG SCardTransmit(SCARDHANDLE hCard, const SCARD_IO_REQUEST *pioSendPci,
 
  /* the protocol number is decoded a few lines above */
  Log2(PCSC_LOG_DEBUG, "Send Protocol: T=%ld", sSendPci.Protocol);
+ Log2(PCSC_LOG_DEBUG, "Rcv buffer size: %ld", dwRxLength);
 
  tempRxLength = dwRxLength;
 
diff --git a/src/winscard_svc.c b/src/winscard_svc.c
index 75e4c8e..35607a4 100644
--- a/src/winscard_svc.c
+++ b/src/winscard_svc.c
@@ -636,7 +636,7 @@ static void ContextThread(LPVOID newContext)
  ioSendPci.cbPciLength = trStr.ioSendPciLength;
  ioRecvPci.dwProtocol = trStr.ioRecvPciProtocol;
  ioRecvPci.cbPciLength = trStr.ioRecvPciLength;
- cbRecvLength = sizeof pbRecvBuffer;
+ cbRecvLength = trStr.pcbRecvLength;
 
  trStr.rv = SCardTransmit(trStr.hCard, &ioSendPci,
  pbSendBuffer, trStr.cbSendLength, &ioRecvPci,
--
2.4.6

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Ludovic Rousseau
Hello,

2015-11-13 13:40 GMT+01:00 Marcin Cieslak <[hidden email]>:
Hello,

My setup (FreeBSD+OmniKey 4040 PCMCIA+OpenCT IFD) started
having trouble after 1.8.14 upgrade (truncated responses
from the card terminal that didn't end with 90 00).

I think you should have the same problem with older versions of pcsc-lite as well.

 

The problem turns out is that the receive buffer size
is now 65548 bytes on my platform,
and my configuration seem to return only
12 bytes with such a large buffer.

I don't know how a bigger buffer could have a truncation as effect.

Where exactly does the truncation occurs?

Bye

--
 Dr. Ludovic Rousseau

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Marcin Cieslak-3
On Fri, 13 Nov 2015, Ludovic Rousseau wrote:

> Hello,
>
> 2015-11-13 13:40 GMT+01:00 Marcin Cieslak <[hidden email]>:
>
> > Hello,
> >
> > My setup (FreeBSD+OmniKey 4040 PCMCIA+OpenCT IFD) started
> > having trouble after 1.8.14 upgrade (truncated responses
> > from the card terminal that didn't end with 90 00).
> >
>
> I think you should have the same problem with older versions of pcsc-lite
> as well.

Everything works fine until 8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7
It seems nobody ever used such a large receive buffer (in my
limited experience).

> > The problem turns out is that the receive buffer size
> > is now 65548 bytes on my platform,
> > and my configuration seem to return only
> > 12 bytes with such a large buffer.
> >
>
> I don't know how a bigger buffer could have a truncation as effect.
>
> Where exactly does the truncation occurs?

Need to identify: what pcscd is doing it passes buffer 65548 to the
IFD, but 12 bytes only are returned. Will investigate, might
be a bug in the ifd, CT API or somewhere else.

Marcin

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Marcin Cieslak-3
In reply to this post by Ludovic Rousseau
On Fri, 13 Nov 2015, Ludovic Rousseau wrote:

> > The problem turns out is that the receive buffer size
> > is now 65548 bytes on my platform,
> > and my configuration seem to return only
> > 12 bytes with such a large buffer.
> >
>
> I don't know how a bigger buffer could have a truncation as effect.
>
> Where exactly does the truncation occurs?

This happens when passing data to CT API:

        char CT_data(unsigned short ctn,        /* Terminal Number */
                     unsigned char *dad,        /* Destination */
                     unsigned char *sad,        /* Source */
                     unsigned short lc, /* Length of command */
                     unsigned char *cmd,        /* Command/Data Buffer */
                     unsigned short *lr,        /* Length of Response */
                     unsigned char *rsp /* Response */

The supplied buffer length on my system, 65548 (hex 0x1000c) gets
downcast to (unsigned short), which is 12.

CT-API will not accept a buffer longer than 64KB. (No wonder given its
origins).

I wish I wouldn't need to use that but my CCID PCMCIA reader is otherwise
not supported.

(By the way, for some broken application I have to "#define DISABLE_ON_DEMAND_POWER_ON"
but that's another story).

Marcin

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Ludovic Rousseau
2015-11-13 15:35 GMT+01:00 Marcin Cieslak <[hidden email]>:
On Fri, 13 Nov 2015, Ludovic Rousseau wrote:

> > The problem turns out is that the receive buffer size
> > is now 65548 bytes on my platform,
> > and my configuration seem to return only
> > 12 bytes with such a large buffer.
> >
>
> I don't know how a bigger buffer could have a truncation as effect.
>
> Where exactly does the truncation occurs?

This happens when passing data to CT API:

        char CT_data(unsigned short ctn,        /* Terminal Number */
                     unsigned char *dad,        /* Destination */
                     unsigned char *sad,        /* Source */
                     unsigned short lc, /* Length of command */
                     unsigned char *cmd,        /* Command/Data Buffer */
                     unsigned short *lr,        /* Length of Response */
                     unsigned char *rsp /* Response */

The supplied buffer length on my system, 65548 (hex 0x1000c) gets
downcast to (unsigned short), which is 12.

CT-API will not accept a buffer longer than 64KB. (No wonder given its
origins).

Maybe you can fix CT-API API to use "unsigned int" for a buffer size instead of "unsigned short".
 
I wish I wouldn't need to use that but my CCID PCMCIA reader is otherwise
not supported.

I don't think it is a CCID reader if it uses PCMCIA.
CCID is for USB (or USB over ExpressCard).
 
(By the way, for some broken application I have to "#define DISABLE_ON_DEMAND_POWER_ON"
but that's another story).

Yes, another story.
Please do not mix bug reports :-)

Bye

--
 Dr. Ludovic Rousseau

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Marcin Cieslak-3
On Fri, 13 Nov 2015, Ludovic Rousseau wrote:

> 2015-11-13 15:35 GMT+01:00 Marcin Cieslak <[hidden email]>:
>
> > This happens when passing data to CT API:
> >
> >         char CT_data(unsigned short ctn,        /* Terminal Number */
> >                      unsigned char *dad,        /* Destination */
> >                      unsigned char *sad,        /* Source */
> >                      unsigned short lc, /* Length of command */
> >                      unsigned char *cmd,        /* Command/Data Buffer */
> >                      unsigned short *lr,        /* Length of Response */
> >                      unsigned char *rsp /* Response */
> >
> > The supplied buffer length on my system, 65548 (hex 0x1000c) gets
> > downcast to (unsigned short), which is 12.
> >
> > CT-API will not accept a buffer longer than 64KB. (No wonder given its
> > origins).
> >
>
> Maybe you can fix CT-API API to use "unsigned int" for a buffer size
> instead of "unsigned short".

No, one can't. The CT-API specification says the length of response
is "IU16" - integer, unsigned, 16bit.

https://www.tuvit.de/cps/rde/xbcr/tuevit_de/CTAPI11EN.pdf

as far as I know most card readers produced or designed in Germany
use CT-API internally even if they expose PC/SC interface.

I seriously doubt such the readers accept larger buffer sizes.

8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7 is strange because
requested buffer size given by the client application is no
longer used(!), only maximal value is used.

Marcin

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: OmniKey 4040 PCMCIA CCID card terminal

Marcin Cieslak-3
In reply to this post by Ludovic Rousseau
On Fri, 13 Nov 2015, Ludovic Rousseau wrote:

> > I wish I wouldn't need to use that but my CCID PCMCIA reader is otherwise
> > not supported.
> >
>
> I don't think it is a CCID reader if it uses PCMCIA.
> CCID is for USB (or USB over ExpressCard).

Omnikey CardMan 4040 uses CCID high-level protocol over FIFO
implemented using 3 I/O registers
(data, status and data flow/sync control register).

Basically the data read/written are standard CCID commands,
identified by their first byte:

PC_TO_RDR_SETPARAMETER (0x61), PC_TO_RDR_ICCPOWERON (0x62)
CMD_PC_TO_RDR_XFRBLOCK (0x6F) etc. etc.

Basically the kernel driver does not really know the CCID
commands, it just passes the bytes from the character
device to the I/O ports and back.

Even the datasheet says the device is "USB 2.0" compatible
(which is nonsense), and lists "CCID" as well (which is kind
of true):

https://www.hidglobal.com/sites/hidglobal.com/files/resource_files/omnikey-4040-mobile-pcmcia-ds-en.pdf

OpenCT just attaches its CCID driver (ifd-ccid.c) to
a "pcmcia_block" device:

reader cm4040 {
        driver = ccid;
        device = pcmcia_block:/dev/cmx0;
};

where /dev/cmx0 is a character device offered by the kernel.

FreeBSD kernel driver:

https://www.freebsd.org/cgi/man.cgi?query=cmx&apropos=0&sektion=0&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html
https://svnweb.freebsd.org/base/head/sys/dev/cmx/

Linux kernel driver:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/pcmcia/cm4040_cs.c
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/pcmcia/cm4040_cs.h


Marcin

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Ludovic Rousseau
In reply to this post by Marcin Cieslak-3


2015-11-13 21:23 GMT+01:00 Marcin Cieslak <[hidden email]>:
On Fri, 13 Nov 2015, Ludovic Rousseau wrote:

> 2015-11-13 15:35 GMT+01:00 Marcin Cieslak <[hidden email]>:
>
> > This happens when passing data to CT API:
> >
> >         char CT_data(unsigned short ctn,        /* Terminal Number */
> >                      unsigned char *dad,        /* Destination */
> >                      unsigned char *sad,        /* Source */
> >                      unsigned short lc, /* Length of command */
> >                      unsigned char *cmd,        /* Command/Data Buffer */
> >                      unsigned short *lr,        /* Length of Response */
> >                      unsigned char *rsp /* Response */
> >
> > The supplied buffer length on my system, 65548 (hex 0x1000c) gets
> > downcast to (unsigned short), which is 12.
> >
> > CT-API will not accept a buffer longer than 64KB. (No wonder given its
> > origins).
> >
>
> Maybe you can fix CT-API API to use "unsigned int" for a buffer size
> instead of "unsigned short".

No, one can't. The CT-API specification says the length of response
is "IU16" - integer, unsigned, 16bit.

https://www.tuvit.de/cps/rde/xbcr/tuevit_de/CTAPI11EN.pdf

as far as I know most card readers produced or designed in Germany
use CT-API internally even if they expose PC/SC interface.

Well, maybe not fix CT-API but at least fix the driver you are using.
I guess you do not use CT-API if you use PC/SC.
CT-API is just an internal API.

I seriously doubt such the readers accept larger buffer sizes.

8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7 is strange because
requested buffer size given by the client application is no
longer used(!), only maximal value is used.

The size given by the client is used to report an error if the buffer is too small.
The test is performed _after_ the command has been sent to the cardreader + card.

I do not plan to change pcsc-lite just because CT-API is limited.

Regards,

--
 Dr. Ludovic Rousseau

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Marcin Cieslak-3
On Sat, 14 Nov 2015, Ludovic Rousseau wrote:

> > 8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7 is strange because
> > requested buffer size given by the client application is no
> > longer used(!), only maximal value is used.
> >
>
> The size given by the client is used to report an error if the buffer is
> too small.
> The test is performed _after_ the command has been sent to the cardreader +
> card.
>
> I do not plan to change pcsc-lite just because CT-API is limited.

It's a pity since pcsc-lite worked in this setup since 1.6.x or
maybe even earlier. I understand you strive for correctness over
robustness :)

It is also unfortunate that extended APDU size is slighly larger than
the CT-API limit and it's hard to tell if the extended APDU is supported,
but maybe if the client picks a small reply size a smaller buffer could
be used?

Marcin

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Possible data truncation on receive in 1.8.14

Marc Kleine-Budde
In reply to this post by Ludovic Rousseau
On 11/14/2015 10:34 PM, Ludovic Rousseau wrote:

> 2015-11-13 21:23 GMT+01:00 Marcin Cieslak <[hidden email]
> <mailto:[hidden email]>>:
>
>     On Fri, 13 Nov 2015, Ludovic Rousseau wrote:
>
>     > 2015-11-13 15:35 GMT+01:00 Marcin Cieslak <[hidden email] <mailto:[hidden email]>>:
>     >
>     > > This happens when passing data to CT API:
>     > >
>     > >         char CT_data(unsigned short ctn,        /* Terminal Number */
>     > >                      unsigned char *dad,        /* Destination */
>     > >                      unsigned char *sad,        /* Source */
>     > >                      unsigned short lc, /* Length of command */
>     > >                      unsigned char *cmd,        /* Command/Data Buffer */
>     > >                      unsigned short *lr,        /* Length of Response */
>     > >                      unsigned char *rsp /* Response */
>     > >
>     > > The supplied buffer length on my system, 65548 (hex 0x1000c) gets
>     > > downcast to (unsigned short), which is 12.
>     > >
>     > > CT-API will not accept a buffer longer than 64KB. (No wonder given its
>     > > origins).
>     > >
>     >
>     > Maybe you can fix CT-API API to use "unsigned int" for a buffer size
>     > instead of "unsigned short".
>
>     No, one can't. The CT-API specification says the length of response
>     is "IU16" - integer, unsigned, 16bit.
>
>     https://www.tuvit.de/cps/rde/xbcr/tuevit_de/CTAPI11EN.pdf
>
>     as far as I know most card readers produced or designed in Germany
>     use CT-API internally even if they expose PC/SC interface.
>
>
> Well, maybe not fix CT-API but at least fix the driver you are using.
> I guess you do not use CT-API if you use PC/SC.
> CT-API is just an internal API.
>
>     I seriously doubt such the readers accept larger buffer sizes.
>
>     8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7 is strange because
>     requested buffer size given by the client application is no
>     longer used(!), only maximal value is used.
>
>
> The size given by the client is used to report an error if the buffer is
> too small.
> The test is performed _after_ the command has been sent to the
> cardreader + card.
>
> I do not plan to change pcsc-lite just because CT-API is limited.
I face the same problem with the openct API. I'll prepare a RFC patch
that keeps the buffer overflow detection.

regards,
Marc

--
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle

signature.asc (465 bytes) Download Attachment