After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728213 - Segmenation Fault with self signed certificate
Segmenation Fault with self signed certificate
Status: RESOLVED FIXED
Product: xmlsec
Classification: Other
Component: xmlsec-openssl
CVS (HEAD)
Other Linux
: Normal normal
: ---
Assigned To: Aleksey Sanin
Aleksey Sanin
Depends on:
Blocks:
 
 
Reported: 2014-04-14 21:22 UTC by Nick Cloward
Modified: 2014-05-22 22:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Files To reproduce bug. (4.89 KB, application/zip)
2014-04-14 21:22 UTC, Nick Cloward
Details

Description Nick Cloward 2014-04-14 21:22:40 UTC
Created attachment 274306 [details]
Files To reproduce bug.

When trying to decrypt some xml with a self signed certificate that includes the x509 certificate inside the <EncryptedKey> element it throws a Segmentation fault error.  I have included some test certs and files to reproduce the issue.  This was using OpenSSl.

System Information:

  - Current xmlsec source from git://git.gnome.org/xmlsec, 1.2.19, and 1.2.14.
  - Ubuntu Trusty Tahr (development branch) (GNU/Linux 3.13.0-21-generic x86_64)

Here are specific steps to reproduce it:

  - Put the private and public key in your machines cert location such as /etc/ssl/certs/.
  - Run c_rehash to generate the hashed symlinks (Not doing this will not reproduce the issue):
      sudo c_rehash /etc/ssl/certs/
  - Try to decrypt the provided encrypted xml document with:
      xmlsec1 --decrypt --privkey-pem /etc/ssl/certs/dev_key.pem --crypto openssl enc_data.xml
  - Results in Segmenation Fault
      Segmentation fault (core dumped)
  - Remove hash symlinks from c_rehash
      sudo rm /etc/ssl/certs/1b72ea22.0 /etc/ssl/certs/84a33109.0
  - Results after removed symlinks from c_rehash
      func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=360:obj=x509-store:subj=X509_verify_cert:error=4:crypto library function failed:subj=/C=US/ST=Utah/L=Salt Lake City/O=Test Cert/CN=TestCert;err=18;msg=self signed certificate
      func=xmlSecOpenSSLX509StoreVerify:file=x509vfy.c:line=408:obj=x509-store:subj=unknown:error=71:certificate verification failed:err=18;msg=self signed certificate
      <?xml version="1.0" encoding="UTF-8"?>
      <Envelope xmlns="urn:envelope">
        <Data>
        Hello, World!
        </Data>
      </Envelope>

Additional Information:

I have been able to track it down to the private key object not containing a "d" value as rsa->d when the rsa object is passed to OpenSSL (around openssl/kt_rsa.c:775).  It looks like its trying to use the public key from the included certificate to decrypt which would not have the "d" value due to it being a public key.  Removing the symlinks created by c_rehash will fix it due to xmlsec looking for an exact copy of the self signed cert to see if its valid.  If it cannot find a copy everything works. It looks returns the key context (around keys.c:1359) if it finds a valid self signed cert and continues if it did not find it.

Thoughts:

I think the resolution would be to check if the cert is valid private key when decrypting for a private key and if its invalid then return an error message and continue on as if the cert was not found?  At least anything it should not seg fault.  The other thing I am wondering about is the template for encrypting valid with only an X509Data element under the KeyInfo?  I haven't found anything that says it allows it nor disallows it.

Other Commands:

- Create a self signed cert and key:

    openssl genrsa -out dev_key.pem 2048
    openssl req -new -x509 -key dev_key.pem -out dev_cert.pem -days 1095

- Encrypt it With the Included Template:

    xmlsec1 --encrypt --pubkey-cert-pem dev_cert.pem --xml-data data.xml --output enc_data.xml --session-key aes-128 template.xml
Comment 1 Aleksey Sanin 2014-05-22 22:24:37 UTC
The bug was caused by incorrect public/private key detection in xmlSecOpenSSLKeyDataRsaGetType() in the presence of crypto engine. Plus the RSAX crypto engine should actually check for nulls just in case.

Anyway, fixed in commit 07172bd459c329ad6a41fbe9a34a6b64d1d2f32b and tested by Nick.