Hello, On Dec 16, 2010, at 8:46 PM, Andreas Jellinghaus wrote: > http://www.h-online.com/open/news/item/When-a-smart-card-can-root-your- > computer-1154829.html > > http://www.heise.de/security/meldung/Wenn-die-Smartcard-den-Rechner- > rootet-1154599.html > > Heise reports a security issue found in OpenSC. As far as I can see > the code was added in 2004 to the starcos driver with the bug and > has found it's way cut&pasted into other drivers later.
While the possibility for the overflow is obvious (and demonstrated) I'm not so sure about the real life applicability of the attack vector: - It is not a "software only, remote hole" - It requires physical access to the target system - It requires executing a process with privileges (root) to gain privileged rights directly from this vulnerability - Using PKCS#11 means that the calling process needs to be privileged, see below - It requires a specially crafted smart card that fakes itself as a suitable card for card-starcos.c, card-acos5.c or card-atrust-acos.c (not so simple for a random attacker) - It needs to be triggered, by calling sc_card_ctl(SC_CARDCTL_GET_SERIALNR) somehow - The common users of SC_CARDCTL_GET_SERIALNR are: - src/tools/opensc-tool.c:print_serial() when used with "opensc-tool --serial" (calls SC_CARDCTL_GET_SERIALNR directly) - requires manual triggering by a logged in user - src/pkcs15init/pkcs15-lib.c:sc_pkcs15init_add_app() (calls SC_CARDCTL_GET_SERIALNR directly) - called from src/tools/pkcs15-init.c() (requires manual triggering from a logged in user via the pkcs15-init command) - called from src/pkcs11/framework-pkcs15init.c:pkcs15init_initialize() (callable via PKCS#11) - src/pkcs15init/pkcs15-lib.c:sc_pkcs15init_get_serial() (calls SC_CARDCTL_GET_SERIALNR directly) - called from src/pkcs11/framework-pkcs15init.c:pkcs15init_create_tokens() (callable via PKCS#11) The interesting thing to note is that src/pkcs11/framework-pkcs15init.c is broken (abandoned? I've written about it before) and my preliminary tests show that it never gets initialized for cards that actually do have an initi driver. I tried with a Feitian card but the mechanism for framework registration is the same for all cards. So the only other possibilities for triggering via PKCS#11 would be callers of SC_CARDCTL_GET_SERIALNR in drivers: pkcs15-esinit.c: expects an entersafe card before calling SC_CARDCTL_GET_SERIALNR (and seems to be a file that is totally unnecessary) pkcs15-gemsafeGPK.c: expects Gemsafe pkcs15-piv.c: expects PIV pkcs15-starcert.c: vulnerable, expects STARCOS SPK 2.3 pkcs15-tcos.c: expects a TCOS card pkcs15-westcos.c: expects a westcos card (that has cooler vulnerabilities (plaintext RSA private keys) than a buffer overflow...) To be automatically triggered (and with privileges other than the current user) a process using OpenSC PKCS#11, something like pam_pkcs11 (which will run as ... root?) or system-wide OpenVPN should be already present on the host. To make the code be triggered via PKCS#11, it seems like a rogue card that fakes itself as a StarCOS SPK 2.3 is required. The claim that on Windows this will result in automatic Administrator privileges is IMHO not true, unless the caller (PKCS#11 applications) would already be running with Administrator privileges. OpenSC currently only provides a PKCS#11 module for Windows, so starting an application with the target privileges on the machine is required to get privileges with this code. Things to consider: - Acos5 is actually not supported. Having an unused, "don't know for sure" or partial, not maintained driver in the codebase can be a potential risk. - Copy-paste is bad, both for maintainability and security . - I would no be surprised if crafted rogue cards would be able to trigger other buffer overflows which are not as obvious. - Careful review of patches and commits can only do good. - Open source is good, as it allows to detect such bugs. Most proprietary smart card drivers (and reader drivers in that matter) come as binary blobs... - While smart cards provide protection for private keys in potentially hostile environments, the overall physical security of your environment matters a lot - I would say that if your possible attacker is sophisticated enough to create a rogue card, together with everything else that is necessary to successfully exploit this vector, you are a target that should take physical security seriously enough to prevent unauthorized physical access. - If your computer software is compromised, even a pinpad will not protect from hackers abusing your system and using crypto can be moot, with or without smart cards. - But if your physical security is compromised, It would be easier to just steal your computer or plant a hardware backdoor or smash your hard disks. - If your setup is vulnerable to physical attacks, upgrade. But the same way smart cards make authentication stronger by requiring two factors, it makes attacks harder, as it requires two factors: specific software and specific hardware. - I did not create an immediate announcement after fixing it because of the above reasons, but maybe it would be useful now? Other thoughts? -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
