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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <E9D72019-2008-4AB1-9AE6-4782C4D4CC3A@webweaving.org>
Date: Tue, 12 Feb 2013 17:41:24 +0100
From: Dirk-Willem van Gulik <dirkx@...weaving.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Crafted certificate can cause network exploitable
	exec/dos (Siemens Business Services Trust Center Root-CA
	V1.1.1) -- anniversary

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.

Download attachment "test-siemens-fail.zip" of type "application/zip" (6284 bytes)

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