<div dir="ltr"><div><div><div><div><div>Greetings.<br><br>I'm trying to help solve a bug in third party software (opendcp) when using libxmlsec to sign and generate files.<br><br>An introduction on the bug can be seen here: <a href="https://code.google.com/p/opendcp/issues/detail?id=136">https://code.google.com/p/opendcp/issues/detail?id=136</a><br>
<br></div>Basically, when using a 64 bit debian system, trying to sign the xml file ends up on a segmentation fault in libcrypto with a long stack (seen there) of xmlsec calls.<br><br></div>So far I've come to this spot in the program's code:<br>
<br>key = xmlSecCryptoAppKeyLoadMemory((unsigned char *)opendcp_private_key, strlen((char *)opendcp_private_key), xmlSecKeyDataFormatPem, NULL, NULL, NULL);<br><br></div>key is defined thus:<br>xmlSecKeyPtr key;<br><br>
</div>debugging this with gdb, on the 32 bit system, when I enter xmlSecOpenSSLAppKeyLoadMemory it looks the same in both 64 and 32 bits. <br><br>Inside the keys, specially <a href="http://key.value.id">key.value.id</a> (for example) looks perfectly sane by the moment I reach line 213 of src/openssl/app.c: (as per gdb: print *<a href="http://key.value.id">key.value.id</a>):<br>
<br></div>32bit:<br><br><div>{klassSize = 88, objSize = 16, name = 0xb7d6a4ba "rsa", usage = 28, href = 0xb7d6a480 "<a href="http://www.w3.org/2000/09/xmldsig#RSAKeyValue">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a>", <br>
dataNodeName = 0xb7d6a4ae "RSAKeyValue", dataNodeNs = 0x81a2a40 "<a href="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2000/09/xmldsig#</a>", initialize = 0xb7d8f21e <xmlSecOpenSSLKeyDataRsaInitialize>, <br>
duplicate = 0xb7d8f0fc <xmlSecOpenSSLKeyDataRsaDuplicate>, finalize = 0xb7d8f05d <xmlSecOpenSSLKeyDataRsaFinalize>, generate = 0xb7d9009e <xmlSecOpenSSLKeyDataRsaGenerate>, <br> getType = 0xb7d90d4b <xmlSecOpenSSLKeyDataRsaGetType>, getSize = 0xb7d90a79 <xmlSecOpenSSLKeyDataRsaGetSize>, getIdentifier = 0, <br>
xmlRead = 0xb7d8f8f3 <xmlSecOpenSSLKeyDataRsaXmlRead>, xmlWrite = 0xb7d90474 <xmlSecOpenSSLKeyDataRsaXmlWrite>, binRead = 0, binWrite = 0, <br> debugDump = 0xb7d90c44 <xmlSecOpenSSLKeyDataRsaDebugDump>, debugXmlDump = 0xb7d90b3d <xmlSecOpenSSLKeyDataRsaDebugXmlDump>, reserved0 = 0x0, reserved1 = 0x0}<br>
<br></div><div>64bit:<br><br>{klassSize = 168, objSize = 32, name = 0x7ffff711ee9a "rsa", usage = 28, href = 0x7ffff711ee60 "<a href="http://www.w3.org/2000/09/xmldsig#RSAKeyValue">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a>", <br>
dataNodeName = 0x7ffff711ee8e "RSAKeyValue", dataNodeNs = 0x7772c0 "<a href="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2000/09/xmldsig#</a>", initialize = 0x7ffff7348f62 <xmlSecOpenSSLKeyDataRsaInitialize>, <br>
duplicate = 0x7ffff7348e4f <xmlSecOpenSSLKeyDataRsaDuplicate>, finalize = 0x7ffff7348dcf <xmlSecOpenSSLKeyDataRsaFinalize>, <br> generate = 0x7ffff7349caa <xmlSecOpenSSLKeyDataRsaGenerate>, getType = 0x7ffff734a844 <xmlSecOpenSSLKeyDataRsaGetType>, <br>
getSize = 0x7ffff734a5bc <xmlSecOpenSSLKeyDataRsaGetSize>, getIdentifier = 0, xmlRead = 0x7ffff7349561 <xmlSecOpenSSLKeyDataRsaXmlRead>, <br> xmlWrite = 0x7ffff734a00c <xmlSecOpenSSLKeyDataRsaXmlWrite>, binRead = 0, binWrite = 0, debugDump = 0x7ffff734a750 <xmlSecOpenSSLKeyDataRsaDebugDump>, <br>
debugXmlDump = 0x7ffff734a65c <xmlSecOpenSSLKeyDataRsaDebugXmlDump>, reserved0 = 0x0, reserved1 = 0x0}<br><br></div><div>But now, after lines <br><br>214: BIO_free(bio);<br><br></div><div>and <br><br>215: return(key);<br>
<br></div><div>On 32 bit the key pointer returned from the function call contains the same, sane info:<br><br>{klassSize = 88, objSize = 16, name = 0xb7d6a4ba "rsa", usage = 28, href = 0xb7d6a480 "<a href="http://www.w3.org/2000/09/xmldsig#RSAKeyValue">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a>", <br>
dataNodeName = 0xb7d6a4ae "RSAKeyValue", dataNodeNs = 0x81a2a40 "<a href="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2000/09/xmldsig#</a>", initialize = 0xb7d8f21e <xmlSecOpenSSLKeyDataRsaInitialize>, <br>
duplicate = 0xb7d8f0fc <xmlSecOpenSSLKeyDataRsaDuplicate>, finalize = 0xb7d8f05d <xmlSecOpenSSLKeyDataRsaFinalize>, generate = 0xb7d9009e <xmlSecOpenSSLKeyDataRsaGenerate>, <br> getType = 0xb7d90d4b <xmlSecOpenSSLKeyDataRsaGetType>, getSize = 0xb7d90a79 <xmlSecOpenSSLKeyDataRsaGetSize>, getIdentifier = 0, <br>
xmlRead = 0xb7d8f8f3 <xmlSecOpenSSLKeyDataRsaXmlRead>, xmlWrite = 0xb7d90474 <xmlSecOpenSSLKeyDataRsaXmlWrite>, binRead = 0, binWrite = 0, <br> debugDump = 0xb7d90c44 <xmlSecOpenSSLKeyDataRsaDebugDump>, debugXmlDump = 0xb7d90b3d <xmlSecOpenSSLKeyDataRsaDebugXmlDump>, reserved0 = 0x0, reserved1 = 0x0}<br>
<br></div><div>But the pointer in the 64 bit system contains something entirely crazy in <a href="http://key.value.id">key.value.id</a>:<br><br>{klassSize = 137438953640, objSize = 140737338535578, name = 0x1c <Address 0x1c out of bounds>, usage = 4145147488, href = 0x7ffff711ee8e "RSAKeyValue", <br>
dataNodeName = 0x7772c0 "<a href="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2000/09/xmldsig#</a>", dataNodeNs = 0x7ffff7348f62 "USH\203\354\030H\211\375H\205\377t'H\213\037H\205\333t\037\201;\247", <br>
initialize = 0x7ffff7348e4f <xmlSecOpenSSLKeyDataRsaDuplicate>, duplicate = 0x7ffff7348dcf <xmlSecOpenSSLKeyDataRsaFinalize>, <br> finalize = 0x7ffff7349caa <xmlSecOpenSSLKeyDataRsaGenerate>, generate = 0x7ffff734a844 <xmlSecOpenSSLKeyDataRsaGetType>, <br>
getType = 0x7ffff734a5bc <xmlSecOpenSSLKeyDataRsaGetSize>, getSize = 0, getIdentifier = 0x7ffff7349561 <xmlSecOpenSSLKeyDataRsaXmlRead>, <br> xmlRead = 0x7ffff734a00c <xmlSecOpenSSLKeyDataRsaXmlWrite>, xmlWrite = 0, binRead = 0, binWrite = 0x7ffff734a750 <xmlSecOpenSSLKeyDataRsaDebugDump>, <br>
debugDump = 0x7ffff734a65c <xmlSecOpenSSLKeyDataRsaDebugXmlDump>, debugXmlDump = 0, reserved0 = 0x0, reserved1 = 0x0}<br><br></div><div>At first i suspected the call on line 214: BIO_free(bio); of havign troubles because the work space was being freed before the key pointer being returned (I do not know nothing of openssl and BIO calls as a library, sorry). but this should fail always, not work in one architecture and not the other.<br>
<br></div><div>And in opendcp (you can check in the same repository where the ticket I linked is. this file: <a href="https://code.google.com/p/opendcp/source/browse/libopendcp/opendcp_xml_sign.c">https://code.google.com/p/opendcp/source/browse/libopendcp/opendcp_xml_sign.c</a> line 385) I check the returned key pointer as soon as it's returned (by line 386). So nothing else was run on that pointer by that time in theory.<br>
<br></div><div>I can't grasp how or why this ocurrs. But this unchains a chain of events that ends up causing a segfault which I posted there under the name Lars. (second or third post).... <br><br></div><div>Versions I'm using:<br>
<br></div><div>xmlsec: 1.2.19 (this happens too with debian's default 1.2.18, I compiled 1.2.19 to enable debug symbols and have source).<br></div><div>openssl: 1.0.1e-2+deb7u4 (Basically 1.0.1e patched to close heartbleed).<br>
</div><div>gcc: 4.7.2-1<br><br></div><div>Everything is adm64 arch. The workign i386 versions of the libraries are exactly the same versions as the 64 bit ones (including my own compiled xmlsec with the same confiure flags).<br>
<br></div><div>Any feedback is highly welcome.<br><br></div><div>Lars.<br></div></div>