Crafted certificate can cause network exploitable exec/dos (Siemens Business Services Trust Center Root-CA V1.1.1) -- anniversary

[Dirk-Willem van Gulik <dirkx () webweaving org>]

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:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/