Certain certificates, among which the production certificate:
Siemens Business Services Trust Center Root-CA V1.1.1 [1,2]
have been found to be able to cause stack corruption when processed in some
(embedded) crypto libraries due to a somewhat unusual structure in the
attribute block.
An example of this is libsecurity prior to 10.7.4 on Mac OS X . Which would
SEGV when exposed to this certificate during routine operations (e.g. when
present in a chain on the server side). See CVE-2012-0654[3]. This is then
used as a DoS. Similar extended attribute structures exist in the certificates
of the Dutch Healthcare System (the implementation of the list of licensed
practitioners 'UZI-register')[4].
Note that a revocation by Siemens Business Services Trust Center (or its expiry
in June 2015) is not sufficient - a broken library may still mishandle it while
discovering expiry or CRL details - and one can still use a similar
bug-triggering structure to craft fresh ones and/or weaponized versions.
Attached is a simple example (and a copy of the cert) to allow verification of
local infrastructures. Or fetch it from [1].
Thanks,
Dw.
Timeline:
2011 Q3&4 issues with (turn-key) VPNs, (osx) https and chipcards observed
in the field. dos rather than weaponized payloads.
2012 Feb 2 issue tracked down to a specific certificate of Siemens Trust
services. No reaction from Siemens (contact details from CA policy document).
2012 Feb 9 Siemens Business Services Trust Center Root and affected
vendors informed. Does not affect OpenSSL. Likely weaponizable. Siemens AG
confirms Siemens Trust Centre informed.
2012 May issue confirmed fixed by apple in libsecurity; update
APPLE-SA-2012-05-09-1. No further responses vendors and/or Siemens CA.
2013 Feb this disclosure
--
Dirk-Willem van Gulik, dirkx(at)WebWeaving(dot)org, the Netherlands.
1: http://www.siemens.com/corp/en/index/digital_id.htm
2: http://www.siemens.com/corp/pool/pki/siemens_pki_ca_hierarchy.pdf
3: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0654
4: Which we've not observed 'abused' in the field. The issue in this specific
case is that rather than use a OID in the type-id field of OtherName - the
dutch system puts an OID in a string and is a bit careless with non-ascii
characters; assuming that those fields will only be read by 'software in the
know'; section 4.8 of "CA Model, Pasmodel, Certificaat- en CRL-profielen
ZorgCPS" - this creating pain for generic parsers. We've not been able to
narrow down the exact contruct in the Siemens cert.
Attachment:
test-siemens-fail.zip
Description: Zip archive
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/