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 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[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. Solution: - --------- The 0.13.0 build of 2013-03-19 (or later): https://www.opensc-project.org/downloads/macosx/ includes a full and complete fix. 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) Manually upgrade to a version of OpenSC.tokend later than commit: c013f819104280eac758d15a57d1aa4848c35654. 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. Footnotes: - ---------- 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 <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs-15v1_1.pdf> 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. Patches: - -------- https://github.com/OpenSC/OpenSC.tokend/commit/c013f819104280eac758d15a57d1aa4848c35654 https://github.com/OpenSC/OpenSC.tokend/commit/a62eca9f94f8a60b9fb21d513ae157e643c0c8cd 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)