Date: Wed, 20 Mar 2013 14:54:37 GMT
From: Dirk-Willem van Gulik <dirkx@...weaving.org>
To: full-disclosure@...ts.grok.org.uk
Subject: CVE-2013-1867: tokend (Apple,
	Gemalto) - privacy leak & arbitrary file creation (OSX,
	All versions)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tokend is a module for OS X CDSA/Keychain subsystem for accessing smart
cards. It acts as a bridge between the apple KeyChain and PKCS#11 libraries
for smartcards, hardware security modules, cryptographic accelerators and
various other security devices. It shipped with OSX up until and including
10.6[1]. It is also known as the Gemalto Tokend.

It is no longer part of the base install from 10.7 (Lion) onwards. However
an open source version lives on[2]. This version is commonly installed in
enterprise installations, research and defence; often in conjunction with
OpenSC[3]. OpenSC or derivatives may also come bundled as part of a SSO
installation or with chipcard-readers their drivers.

As is common in such bridges to a relatively slow medium (chipcards in
readers on serial/USB); tokend relies on a cache.

This cache is kept in /var/db/TokenCache. This directory is root owned and
its content only readable by root. It contains directories on a per token
basis. The name for this directory is constructed using the label and the
serial number. These can contain arbitrary UTF8 strings up to 64 and 32
bytes long[4].

This makes it possible for an attacker to construct token labels that may
cause the overwriting (by a root process) of somewhat arbitrary directories
(and in some cases files) on the file system (somewhat limited by a length
constraint on the token-label) upon insertion. Symbolic links are followed
without ado. As tokend generally runs at all time - such insertion can be
done even when the user is logged out or the screen locked.

CVE: CVE-2013-1867

Impact
- ------
1) An attacker with physical access to a reader can create/corrupt a wide
range of directories on the file system.

2) An attacker with physical access to a legitimate smart card (holder) can
substitute/reprogram an existing card to do such when the legitimate 
holder inserts the doctored card at some later point[6].

3) As errors are logged to a public-readable log file - some information
about which token was inserted at what time leaks inadvertently. This 
has issues in certain setting[7]. Such leakage can also be 'caused' 
by making the cache directory or disk in-accessible/full.

4) In certain (possibly common) circumstances the attacker can cause one card
to (re)use the cache of another card[7].

5) The attack can be executed with an existing chipcard, already in use
within the organisation; or with virtually any other chipcard (including
blank unprogrammed chipcards) provided that at least one of the token
plugins is able to read the card.

6) Above also applies to so called 'USB Token's; which are technically
chipcards hardwired (or in the form of a small physical form factor
SIM card) into a reader in a convenient USB thumb-drive style enclosure.

Versions affected
- -----------------
All builds of tokend where installed build from the open source repository
as of March 2013. TokenD is installed on OSX 10.6 and older by default. 

Various chipcard and security products install a version of it as 
part of their driver suite. PKCS#11 distributions of a wide range of 
vendors are known to allow such labels.

A telltale sign of this type of use is entries in syslog matching:

  com.apple.SecurityServer[22]: reader XXX inserted token "RR" (XXX) 
	subservice DD using driver com.gemalto.tokend

where XXX are the labels on the chipcard.

Failed exploits may show up as (with XXX the name of the bundle):

	XXX [41975]: error writing cache file: /var/db/TokenCache/....

followed by errors such as 'No such file or directory', 'Permission
denied' etc. A well executed exploit will not leave such traces. 

Even though an existing installation may not use tokend or may use a 
plugin that filters/curtails the label - the insertion of a different 
brand of label may still be used to bypass that specific vendor's 
protection.

Mitigation
- ----------
1) Limit physical access; make personnel aware of the risks of inserting a
'rogue' card or loosing control of a card temporarily and using 
it subsequently. Note however that most installations allow the reprogamming
of an already inserted card its (outer) label without root access.

2) Apply the attached patch.

3) Consider pruning the installed security agent bundles and PKCS#11
bundles to an absolute minimum.

Long term Solution
- ------------------
There is currently no vendor support for tokend - and we've not been able
to find a maintaineri. Not did we any reaction from the author (Gemalto N.V. 
HQ is unable to find a security officer) or its current publisher (Apple)).

Timeline & Credits
- ------------------
Discovered by Dirk-Willem van Gulik (dirkx@...weaving.org) as part of the
Artemis/EU project HighProfile. Fix below in consultation with Martin 
Paljak of OpenSC.

Bootnote
- --------
Note that this opensource tokend[2] package is a common (and pretty much
the only known) basis for third party/proprietary vendors to base their 
drivers on when it comes to interacting with the keychain. Therefore
it is not unlikely that other such keychain/pkcs11/pkcs15 bridges and
drivers exhibit very similar issues. A telltale sign of this is 
the existence of directories with the card-label in locations 
such as /var/db, /etc or /usr/share. In fact, a search for any file-
or directory names that matches part of the label of the chipcard
or any of its tokens is propably a concern. See CVE-2013-1866 for 
related information.


Footnotes:
- ---------
1: http://lists.apple.com/archives/fed-talk/2011/Jul/msg00099.html 

2: http://www.opensource.apple.com/source/Tokend/ 

3: https://www.opensc-project.org/opensc 

4: Although some implementations inadvertently stick/limit to table 3 of 
the spec[4] - but the actual range is CK_UTF8CHAR (page 39, p40 of [5]).

5: PKCS #11 v2.20: Cryptographic Token Interface Standard, RSA Laboratories, 
28 June 2004 <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf>.

6: It is common for end-user cards to be shipped in read-only state. 
However it is not uncommon that cards issued can be re-labed with the 
same end-users tools that allow for a PIN change; especially if one 
is willing to re-initialize the card. Common card setups do not require 
the SO/PUK for this - i.e. the card is left 'open' at user level, as 
the cards label is may be seen as outside the card protected area,
e.g. if the card allows for end user PIN changes.

7: E.g. in setttings where the permissions hierarchy is relatively
flat and/or largely relies on identification (with the card carrying
little implied authorization information).

8: E.g. in enterprise settings where such information is shared by syslog.

Patch:
Index: Tokend/Tokend/Token.cpp
- -===================================================================
- --- Tokend/Tokend/Token.cpp	(revision 157)
+++ Tokend/Tokend/Token.cpp	(working copy)
@@ -33,9 +33,11 @@
#include "RecordHandle.h"
#include "Schema.h"
#include <memory>
+#include <sstream>
#include <security_cdsa_utilities/cssmaclpod.h>
#include <security_utilities/unix++.h>
#include <security_utilities/logging.h>
//
// SPI wrapper macros
@@ -799,10 +801,25 @@
std::string Token::cachedObjectPath(CSSM_DB_RECORDTYPE relationId,
 	const std::string &name) const
{
- -	char buffer[9];
- -	sprintf(buffer, "%X", relationId);
- -
- -	return mCacheDirectory + "/" + buffer + "-" + name;
+    unsigned char md[ CC_SHA1_DIGEST_LENGTH ];
+    
+    // the name is in effect the label - and can be set to nefarious things
+    // such as '../../etc/foobar'; or alternatively get logged in the log
+    // file all to easily. So we use a sha1 instead.
+    //
+    CC_SHA1_CTX ctx;
+    CC_SHA1_Init(&ctx);
+    CC_SHA1_Update(&ctx, &relationId, sizeof(relationId));
+    CC_SHA1_Update(&ctx, name.c_str(), name.length());
+    CC_SHA1_Final(md, &ctx);
+    
+    std::ostringstream out;
+    out <<  mCacheDirectory << "/";
+    for (std::size_t i=0; i < CC_SHA256_DIGEST_LENGTH; i++) {
+        out << std::hex << md[i];
+    };
+    
+    return out.str();
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQCVAwUBUUnNnDGmPZbsFAuBAQKHuwP5AXMvDnovRO4ift1HFQGdC8eL1syKJ5jW
HESC4iaKlAfFC8sPX3Lp4/yPavLxKWXnAM4pXZDpI0LPTp0QNXFbcGn21aJr1eIP
6vsv5++GTlKYqwHUAcm3WflHmQF8AqnVcUqB+f4oxfe4skP0lfeTPvcft+JR0njV
tk5zADt2pw4=
=VaEY
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists