Multiple buffer overflow flaws were found in the way PC/SC Smart Card daemon sanitized message data sent by client by message demarshalling. Local, authenticated user could use this flaw to escalate their privileges.
Created attachment 416970 [details] Patch against pcsc-lite-1.4.102
This issue affects the version of the pcsc-lite package, as shipped with Red Hat Enterprise Linux 5. This issue affects the versions of the pcsc-lite package, as shipped with Fedora releases of 11 and 12.
Patch in comment #4 addresses multiple possible overflows: - SCARD_STATUS - this should only cause bogus values to be returned, but not overwrite status_struct mszReaderNames[] and pbAtr[] members due to the other checks in SCardStatus - SCARD_TRANSMIT, SCARD_CONTROL, SCARD_GET_ATTRIB - this can possibly lead to overwrites, if card reader returns large enough data in response to the request, upper limit specifying buffer length is provided by client / attacker. - SCARD_SET_ATTRIB - this can lead to overread. - SCARD_TRANSMIT_EXTENDED, SCARD_CONTROL_EXTENDED - there are multiple possible overwrites here, some are fully controlled by attacker (size and content of the overflow). One of those attacker-controlled overflows is demonstrated by MWR Lab reproducer. This attack vector is mitigated on RHEL5 by FORTIFY_SOURCE, reducing impact to crash.
Upstream commits: http://svn.debian.org/wsvn/pcsclite/?sc=1&rev=4208 http://svn.debian.org/wsvn/pcsclite/?sc=1&rev=4334 Issues should be fixed in upstream version 1.5.4.
pcscd in RHEL5 and Fedora runs as user root, but is confined in a restricted SELinux domain (pcscd_t).
Public now via Debian DSA-2059-1: http://www.debian.org/security/2010/dsa-2059
pcsc-lite-1.5.2-4.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/pcsc-lite-1.5.2-4.fc12
pcsc-lite-1.5.2-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/pcsc-lite-1.5.2-3.fc11
pcsc-lite-1.5.2-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
pcsc-lite-1.5.2-4.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
MITRE assigned another two CVE names to this issue: CVE-2009-4901 and CVE-2009-4902. The descriptions are a bit confusing, but by the sounds of them, CVE-2009-4901 and CVE-2010-0407 affect us, and CVE-2009-4902 is due to the incorrect fix for CVE-2010-0407 (which we had not previously fixed, so would not affect us). Name: CVE-2009-4901 The MSGFunctionDemarshall function in winscard_svc.c in the PC/SC Smart Card daemon (aka PCSCD) in MUSCLE PCSC-Lite before 1.5.4 might allow local users to cause a denial of service (daemon crash) via crafted SCARD_SET_ATTRIB message data, which is improperly demarshalled and triggers a buffer over-read, a related issue to CVE-2010-0407. Name: CVE-2009-4902 Buffer overflow in the MSGFunctionDemarshall function in winscard_svc.c in the PC/SC Smart Card daemon (aka PCSCD) in MUSCLE PCSC-Lite 1.5.4 and earlier might allow local users to gain privileges via crafted SCARD_CONTROL message data, which is improperly demarshalled. NOTE: this vulnerability exists because of an incorrect fix for CVE-2010-0407. Name: CVE-2010-0407 Multiple buffer overflows in the MSGFunctionDemarshall function in winscard_svc.c in the PC/SC Smart Card daemon (aka PCSCD) in MUSCLE PCSC-Lite before 1.5.4 allow local users to gain privileges via crafted message data, which is improperly demarshalled.
Installed 'pcsc-lite-1.4.4-2.el5_5' and performed smart card regression tests such as token enroll/format/pin reset etc., looks good.
(In reply to comment #15) > MITRE assigned another two CVE names to this issue: CVE-2009-4901 and > CVE-2009-4902. The descriptions are a bit confusing, but by the sounds of > them, CVE-2009-4901 and CVE-2010-0407 affect us, and CVE-2009-4902 is due to > the incorrect fix for CVE-2010-0407 (which we had not previously fixed, so > would not affect us). Yes, these assignments are somewhat confusing. Issue was originally reported and fixed upstream in 2009 (as mentioned in comment #7), but they were only recognized as security fix in 2010, when CVE-2010-0407 was assigned to all these issues. Later on Mitre assigned CVE-2009-4901 for one of the issues originally under CVE-2010-0407, apparently due to different impact (see comment #6). CVE-2009-4902 was also assigned for an incomplete fix for CVE-2010-0407 (sic, different years make it even more confusing) in the upstream commit (see comment #7), even though it's not clear if such incomplete fix was ever used in any upstream or vendor release. Our updates addressing CVE-2010-0407 will include complete fix that does not introduce CVE-2009-4902. Statement CVE-2009-4902: Not vulnerable. This issue did not affect the versions of pcsc-lite as shipped with Red Hat Enterprise Linux 5.
FYI: this security fix breaks Aladdin's pkiclient 5.0 on at least Fedora 12: With pcsc-lite-libs 1.5.2-3 installed I can use pkcs11-tool --module /lib64/libeToken.so.5 -L without errors. With pcsc-lite-libs 1.5.2-4 I get: pkcs11-tool --module /lib64/libeToken.so.5 -L Available slots: Slot 0 AKS ifdh 00 00 error: PKCS11 function C_GetTokenInfo failed: rv = CKR_DATA_LEN_RANGE (0x21) Aborting.
(In reply to comment #21) > FYI: this security fix breaks Aladdin's pkiclient 5.0 on at least Fedora 12: The best I can tell, this seem to be some Aladdin's proprietary software. So you'd likely need to help us get info on what's failing and how to get this resolved.
To be more specific, you can get bit more info by installing pcsc-lite-debuginfo (and gdb) and doing: # gdb -p <pcscd pid> (gdb) break MSGFunctionDemarshall (gdb) handle SIGPIPE pass nostop noprint (gdb) continue $ <run command that fails> Use next in gdb to find check that fails and print to inspect values to see which check is failing.
Wait a bit, this check does not look ok to me: if (gsStr->cbAttrLen <= sizeof(gsStr->pbAttr)) It was changed to: if (gsStr.cbAttrLen > sizeof(gsStr.pbAttr)) in: http://svn.debian.org/wsvn/pcsclite/?sc=1&rev=4434
(In reply to comment #21) > FYI: this security fix breaks Aladdin's pkiclient 5.0 on at least Fedora 12: Can you check this scratch build to see if you still see the same problem? http://koji.fedoraproject.org/koji/taskinfo?taskID=2285297
SCardControl() returns SCARD_E_INSUFFICIENT_BUFFER unless the receiving buffer is less than 4 bytes. This is because the code is: if ((ctStr->cbRecvLength > sizeof(ctStr->cbRecvLength)) instead of: if ((ctStr->cbRecvLength > sizeof(ctStr->pbRecvBuffer)) ctStr->cbRecvLength is a uint32_t so sizeof returns 4. ctStr->pbRecvBuffer is the buffer. So (nearly) any code that use SCardControl() will get an error. SCardControl() is used in particular with pinpad readers. To know if the reported problem is the one I describe you should start pcscd in debug mode. See http://pcsclite.alioth.debian.org/ccid.html#support
(In reply to comment #27) > So (nearly) any code that use SCardControl() will get an error. > SCardControl() is used in particular with pinpad readers. Thanks for clarification, Ludovic! New scratch build with this second correction: http://koji.fedoraproject.org/koji/taskinfo?taskID=2286727
> Wait a bit, this check does not look ok to me: > if (gsStr->cbAttrLen <= sizeof(gsStr->pbAttr)) > > It was changed to: > if (gsStr.cbAttrLen > sizeof(gsStr.pbAttr)) That's because the version of winscard_svc.c has change gsStr from a pointer to a stack structure. The compiler would catch this error as in once case gsStr is a control_struct * and in the other it's just a control_struct.
(In reply to comment #30) > > Wait a bit, this check does not look ok to me: > > if (gsStr->cbAttrLen <= sizeof(gsStr->pbAttr)) > > > > It was changed to: > > if (gsStr.cbAttrLen > sizeof(gsStr.pbAttr)) > > That's because the version of winscard_svc.c has change gsStr from a pointer to > a stack structure. The compiler would catch this error as in once case gsStr is > a control_struct * and in the other it's just a control_struct. Ok, my comment was bad / confusing, I realized shorty after posting it. Relevant change is from <= (i.e. rejecting all queries where specified attribute length is valid and not exceeding pbAttr size) to > (i.e. rejecting requests with excessive cbAttrLen length value). Upstream change from struct pointer to struct made my comment confusing. What we want to use should be: if (gsStr->cbAttrLen > sizeof(gsStr->pbAttr))
Created attachment 428529 [details] F12 patch interdiff Changes I applied on top of existing pcsc-lite-CVE-2010-0407.patch in the scratch build referenced above.
(In reply to comment #28) > (In reply to comment #27) > > So (nearly) any code that use SCardControl() will get an error. > > SCardControl() is used in particular with pinpad readers. > > Thanks for clarification, Ludovic! > > New scratch build with this second correction: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2286727 I've just downloaded and test the scratch build: problem fixed. Thanks!
Thanks! I merged the patch from comment #33 into the pcsc-lite-CVE-2010-0407.patch and built an update for F-12.
New build for F-12 with the updated patch is now in updates-testing: http://admin.fedoraproject.org/updates/pcsc-lite-1.5.2-5.fc12
pcsc-lite-1.5.2-5.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0533 https://rhn.redhat.com/errata/RHSA-2010-0533.html
This issue has been addressed in following products: Red Hat Certificate System 7.3 Via RHSA-2010:0602 https://rhn.redhat.com/errata/RHSA-2010-0602.html
The patch pcsc-lite-1.5.2-overflow.patch in pcsc-lite-1.5.2-6.el6.src.rpm breaks SCardGetAttrib on Red Hat Enterprise Linux 6. It will always return SCARD_E_INSUFFICIENT_BUFFER regardless of buffer size. Case 1. If buffer is less than or equal to MAX_BUFFER_SIZE the patched in check in MSGFunctionDemarshall will fail with SCARD_E_INSUFFICIENT_BUFFER. case SCARD_GET_ATTRIB: gsStr = ((getset_struct *) msgStruct->data); rv = MSGCheckHandleAssociation(gsStr->hCard, dwContextIndex); if (rv != 0) return rv; /* avoids buffer overflow */ if (gsStr->cbAttrLen <= sizeof(gsStr->pbAttr)) { gsStr->rv = SCARD_E_INSUFFICIENT_BUFFER ; break; } Case 2. If buffer is larger than MAX_BUFFER_SIZE the call fail in winscard_clnt.c:SCardGetSetAttrib instead. The result is SCARD_E_INSUFFICIENT_BUFFER. (This case is not affected by the patch) Case 3. If buffer is set to NULL to query required buffer size. SCardGetSetAttrib will set buffer size to MAX_BUFFER_SIZE and the call will fail as in case 1. Not sure if this is the right bug to report this in or what the buffer size check is supposed to achieve but it will definitely make SCardGetAttrib defunct.
(In reply to comment #43) > The patch pcsc-lite-1.5.2-overflow.patch in pcsc-lite-1.5.2-6.el6.src.rpm > breaks SCardGetAttrib on Red Hat Enterprise Linux 6. It will always return > SCARD_E_INSUFFICIENT_BUFFER regardless of buffer size. This is now corrected in Red Hat Enterprise Linux 6.4 via RHSA-2013:0525, see bug 891852. > Not sure if this is the right bug to report this in or what the buffer size > check is supposed to achieve but it will definitely make SCardGetAttrib > defunct. Separate bug against affected component should be done to avoid having the report overlooked as happened in this case.