what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

OpenSC.tokend Privacy Leak / File Creation

OpenSC.tokend Privacy Leak / File Creation
Posted Mar 21, 2013
Authored by Dirk-Willem van Gulik

OpenSC.tokend OS X module suffers from privacy leak and arbitrary file creation vulnerabilities.

tags | advisory, arbitrary, vulnerability, info disclosure
systems | apple, osx
advisories | CVE-2013-1866
SHA-256 | 602d9d00b3ecc95a349e687f708bdc0655d4cb1110af628d3b4a5bf21c04ed15

OpenSC.tokend Privacy Leak / File Creation

Change Mirror Download
Hash: SHA1

OpenSC.tokend (1,2) is a Tokend module for OS X CDSA/Keychain subsystem for
accessing smart cards. 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
chipcard, per token basis. The name for this directory is constructed using
the label of the card, its serial number and the label of the token. These
can contain arbitrary UTF8 strings up to 255 bytes long when exposed
directly through OpenSC.tokend (PKCS#15) its module as picked up by the
the securityd. (There is a related issue with OpenSC its pkcs#11 driver
via Gemalto/Apple's tokend plugin and then onto securityd; See CVE-2013-1867)

This makes it possible for an attacker to construct card labels or 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 card and 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-1866

- -------

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[5].

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[6].

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:
- ------------------

1) All builds prior to 15th of March 2013; all versions of OSX.

On affected systems syslog will generally show entries such as

com.apple.SecurityServer[829]: reader RRR inserted token "XX" (XXX)
subservice DD using driver com.apple.tokend.opensc

where XXX is a label on the chipcard.

A failed exploit attempt will appear as

OpenSC[PID]: error writing cache file: /var/db/TokenCache/...

follewed by errors such as 'Permission denied' or 'No such file or directory'.

Note that a perfectly executed exploit will not leave such traces.

- ---------

The 0.13.0 build of 2013-03-19 (or later):


includes a full and complete fix.

- -----------

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) Manually upgrade to a version of OpenSC.tokend later than commit:


3) Update using the attached patches.

4) Consider pruning the installed security agent bundles to an
absolute minimum.

Note that (as some proprietary vendors may suggest) that removing the
OpenSC #15 based plugin and relying on the Gemalto/Apple PKCS#11 'tokend'
bridge into securityd instead is subject to a similar issue as
described in CVE-2013-1867.

Note that (as some proprietary vendors may suggest) removing the OpenSC
plugins and PKCS#11 libs and switching to a different vendor is also
subject to the issue described in CVE-2013-1867 (as it happens one
layer 'higher').

Likewise even though an existing installation may not use tokend or
may use a vendors plugin that filters/curtails the label - the insertion
of a different brand of card may still be used to bypass that specific
vendor's protection when it gets picked up by a (previously possibly
dormant) plugin.

Long term solution
- ------------------

1) Upgrade OpenSC.tokend to a release post March 2013.

Timeline & Credits:
- -------------------

Discovered by Dirk-Willem van Gulik (dirkx@webweaving.org) as part of the
Artemis/EU project HighProfile. Fix applied to the release branch by
Martin Paljak.

- ----------

1: https://www.opensc-project.org/opensc/wiki/MacInstaller

2: https://github.com/OpenSC/OpenSC.tokend

3. Although some implementations inadvertently stick/limit this to
16 safe characters the actual range is is defined in 6.1.3 as UTF8 up
to pkcs15-ub-label charcters (255)[4]. So while arguably too accomodating,
driver authors are 'right' in passing dubious strings up.

4: PKCS #15 v1.1: Cryptographic Token Information Syntax Standard,
RSA Laboratories June 6, 2000

5: it is common for end-user cards to be shipped in read-only state.
However ti 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.

6: 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).

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

- --------


Index: OpenSC/OpenSCToken.cpp
@@ -32,8 +32,12 @@
#include "OpenSCRecord.h"
#include "OpenSCSchema.h"
#include <security_cdsa_client/aclclient.h>
+#include <CommonCrypto/CommonDigest.h>
#include <map>
#include <vector>
+#include <sstream>
+#include <iomanip>

using CssmClient::AclFactory;

@@ -257,22 +261,25 @@ uint32 OpenSCToken::probe(SecTokendProbeFlags flags,
score = scconf_get_int(conf_block, "score", score);
sc_debug(mScCtx, SC_LOG_DEBUG_NORMAL, " Get Score from config file: %d\n", score);
- - // Create a tokenUid
- - if (mScP15Card->tokeninfo->label != NULL)
- - strlcpy(tokenUid, mScP15Card->tokeninfo->label, TOKEND_MAX_UID);
- - if (mScP15Card->tokeninfo->serial_number != NULL)
- - strlcpy(tokenUid + strlen(tokenUid), mScP15Card->tokeninfo->serial_number,
- - TOKEND_MAX_UID - strlen(tokenUid));
- -
- - {
- - /* replace non ASCII chars by '_' */
- - int i;
- - unsigned char *c = (unsigned char *)tokenUid;
- -
- - for (i=0; tokenUid[i]; i++)
- - if (c[i] > 127)
- - tokenUid[i] = '_';
+ // Create a tokenUid - obscure the label somewhat as it is under
+ // control of the card issuer; and could contain naughtyness.
+ //
+ unsigned char md[CC_SHA1_DIGEST_LENGTH];
+ CC_SHA1_CTX ctx;
+ CC_SHA1_Init(&ctx);
+ CC_SHA1_Update(&ctx, mScP15Card->tokeninfo->label,
+ strlen(mScP15Card->tokeninfo->label));
+ CC_SHA1_Update(&ctx, mScP15Card->tokeninfo->serial_number,
+ strlen(mScP15Card->tokeninfo->serial_number));
+ CC_SHA1_Final(md, &ctx);
+ std::ostringstream out;
+ for (std::size_t i=0; i < MIN(TOKEND_MAX_UID/2,CC_SHA1_DIGEST_LENGTH); i++) {
+ out << std::setfill('0') << std::setw(2) << std::hex << (short) md[i];
+ strlcpy(tokenUid,out.str().c_str(),TOKEND_MAX_UID);
sc_debug(mScCtx, SC_LOG_DEBUG_NORMAL, " score = %d, tokenUid = \"%s\"\n", score, tokenUid);
Index: Tokend/Token.cpp
@@ -33,9 +33,12 @@
#include "RecordHandle.h"
#include "Schema.h"
#include <memory>
+#include <sstream>
+#include <iomanip>
#include <security_cdsa_utilities/cssmaclpod.h>
#include <security_utilities/unix++.h>
#include <security_utilities/logging.h>
+#include <CommonCrypto/CommonDigest.h>

// SPI wrapper macros
@@ -799,10 +802,25 @@ void Token::cacheObject(CSSM_DB_RECORDTYPE relationId, const std::string &name,
std::string Token::cachedObjectPath(CSSM_DB_RECORDTYPE relationId,
const std::string &name) const
- - char buffer[9];
- - sprintf(buffer, "%X", relationId);
+ 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 mask.
+ //
+ 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_SHA1_DIGEST_LENGTH; i++) {
+ out << std::setfill('0') << std::setw(2) << std::hex << (short) md[i];
+ }

- - return mCacheDirectory + "/" + buffer + "-" + name;
+ return out.str();

Cursor *Token::createCursor(const CSSM_QUERY *inQuery)

Version: GnuPG v1.4.13 (Darwin)
Comment: GPGTools - http://gpgtools.org


Login or Register to add favorites

File Archive:

June 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    18 Files
  • 2
    Jun 2nd
    0 Files
  • 3
    Jun 3rd
    0 Files
  • 4
    Jun 4th
    0 Files
  • 5
    Jun 5th
    0 Files
  • 6
    Jun 6th
    0 Files
  • 7
    Jun 7th
    0 Files
  • 8
    Jun 8th
    0 Files
  • 9
    Jun 9th
    0 Files
  • 10
    Jun 10th
    0 Files
  • 11
    Jun 11th
    0 Files
  • 12
    Jun 12th
    0 Files
  • 13
    Jun 13th
    0 Files
  • 14
    Jun 14th
    0 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    0 Files
  • 18
    Jun 18th
    0 Files
  • 19
    Jun 19th
    0 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By