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 () webweaving 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(); }