[openssl.org #2905] Double locking bug added in openssl-1.0.0h crypto/asn1/x_pubkey.c
The following code added in 1.0.0h causes CRYPTO_LOCK_EVP_PKEY lock to be
requested twice with no intervening unlock when there is a race between 2 or
more threads to create the EVP_PKEY associated with the X509_PUBKEY. The second
lock request occurs in EVP_PKEY_free().
crypto/asn1/x_pubkey.c:174
/* Check to see if another thread set key-pkey first */
CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY);
if (key-pkey)
{
EVP_PKEY_free(ret);
ret = key-pkey;
}
else
key-pkey = ret;
CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY);
CRYPTO_add(ret-references, 1, CRYPTO_LOCK_EVP_PKEY);
In the case where the user supplied locking mechanism uses non-recursive
mutexes, this will cause the second lock request (within the call to
EVP_PKEY_free) to either deadlock or simply fail (if deadlock checking has been
implemented).
In the case where the second lock fails, the CRYPTO_LOCK_EVP_PKEY will be
unlocked on return from EVP_PKEY_free and the call to CRYPTO_w_unlock is a
no-op.
I have attached a patch file which should apply cleanly to 1.0.0h/i/j (`patch
-p0 patch.txt` from the openssl base directory). The patch moves the call to
EVP_PKEY_free outside the CRYPTO_LOCK_EVP_PKEY locking section - though I'm in
two minds as to whether a better fix wouldn't be just to remove the new calls
to CRYPTO_x_lock/unlock as these appear to be used to protect access to
key-pkey which isn't deemed necessary elsewhere in the same function and
wasn't deemed necessary in the original code prior to 1.0.0h.
MARKITSERV DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses. MarkitSERV accepts no liability for any damage caused by
any virus transmitted by this email, makes no warranty as to the accuracy or
completeness of this email and hereby disclaims any liability of any kind for
the information contained herein. For full details about MarkitSERV, its
offerings and legal terms and conditions, please see MarkitSERV's website at
http://www.markitserv.com.
--- crypto/asn1/x_pubkey.c 2012-02-28 14:47:25.0 +
+++ /d/dev/openssl/crypto/asn1/x_pubkey.c 2012-10-30 16:18:15.571215400
+
@@ -133,6 +133,7 @@
EVP_PKEY *X509_PUBKEY_get(X509_PUBKEY *key)
{
EVP_PKEY *ret=NULL;
+EVP_PKEY *freeval=NULL;
if (key == NULL) goto error;
@@ -175,13 +176,15 @@
CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY);
if (key-pkey)
{
- EVP_PKEY_free(ret);
+freeval = ret;
ret = key-pkey;
}
else
key-pkey = ret;
CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY);
CRYPTO_add(ret-references, 1, CRYPTO_LOCK_EVP_PKEY);
+if (freeval)
+EVP_PKEY_free(freeval);
return ret;
[openssl.org #2906] enhancement: test suite won't work when parent directories have spaces
This is an enhancement request for the test suite. I ran the tests from a directory /Users/dillo/scratch/updated libraries/openssl-1.0.1c and the tests failed. Once I changed a parent directory name to remove its space character, the script worked and all tests passed. Version: 1.0.1c Platform: OS X 10.8.2 Generate and certify a test certificate via the 'ca' program CA certificate filename (or enter to create) Making CA certificate ... ../apps/CA.sh: line 130: /Users/dillo/scratch/updated: No such file or directory ../apps/CA.sh: line 132: /Users/dillo/scratch/updated: No such file or directory make[1]: *** [test_ca] Error 1 make: *** [tests] Error 2 This is an enhancement request for the test suite.I ran the tests from a directory /Users/dillo/scratch/updated libraries/openssl-1.0.1c and the tests failed. Once I changed a parent directory name to remove its space character, the script worked and all tests passed. Version: 1.0.1cPlatform: OS X 10.8.2Generate and certify a test certificate via the ca programCA certificate filename (or enter to create)Making CA certificate ./apps/CA.sh: line 130: /Users/dillo/scratch/updated: No such file or directory ../apps/CA.sh: line 132: /Users/dillo/scratch/updated: No such file or directorymake[1]: *** [test_ca] Error 1make: *** [tests] Error 2
[openssl.org #2907] Unresolved external referenced in function _EC_GF2m_simple_method when linking 1.0.1c w/ fips-ecp-2.0.2
When attempting to build openssl-1.0.1c in fips compliant mode, the file crypto/ec/ec2_smpl.c attempts to return the results of function fips_ec_gf2m_simple_method(). This function is not defined in either projects. When attempting to build openssl-1.0.1c in fips compliant mode, the file crypto/ec/ec2_smpl.c attempts to return the results of function fips_ec_gf2m_simple_method(). This function is not defined in either projects.
[openssl.org #2907] Unresolved external referenced in function _EC_GF2m_simple_method when linking 1.0.1c w/ fips-ecp-2.0.2
[lee.bayd...@gmail.com - Mon Nov 05 14:57:30 2012]: When attempting to build openssl-1.0.1c in fips compliant mode, the file crypto/ec/ec2_smpl.c attempts to return the results of function fips_ec_gf2m_simple_method(). This function is not defined in either projects. Did you compile the FIPS capable OpenSSL with the no-ec2m option? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2904] genpkey ignores -outform DER
[vpodz...@redhat.com - Tue Oct 30 17:34:05 2012]: Description of problem: Running $ openssl genpkey -genparam -outform DER -out dh_params.der -algorithm DH generates data in the PEM format instead of the requested DER format. Version-Release number of selected component (if applicable): openssl-1.0.0j-2.fc17.i686 Steps to Reproduce: 1. run command from the description 2. run 'file dh_params.der' Actual results: ASCII text Expected results: data Additional info: Deprecated (according to openssl(1)) command $ openssl dhparam -outform DER -out dh_params.der works as expected. When the pkey utilities (and associated functions) are presented with a file they have to automatically decide which algorithm to use. This is fine for public and private key formats which include the algorithm OID in the associated structures (SubjectPublicKeyInfo or PKCS#8) or the PEM headers for older private key formats. In the case of parameters there isn't a DER format that includes the algorithm type as an OID, just the PEM format where the algorithm to use is part of the headers. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2905] Double locking bug added in openssl-1.0.0h crypto/asn1/x_pubkey.c
--On Monday, November 05, 2012 2:55 PM +0100 Richard Skinner via RT r...@openssl.org wrote: The following code added in 1.0.0h causes CRYPTO_LOCK_EVP_PKEY lock to be requested twice with no intervening unlock when there is a race between 2 or more threads to create the EVP_PKEY associated with the X509_PUBKEY. The second lock request occurs in EVP_PKEY_free(). crypto/asn1/x_pubkey.c:174 Duplicate of RT #2866? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2907] Unresolved external referenced in function _EC_GF2m_simple_method when linking 1.0.1c w/ fips-ecp-2.0.2
I resolved this issue. When building OpenSSL for FIPS, in addition to adding the fips parameter to the Configure command, you must also add the --with-fipslibdir and --with-fipsdir switches so the necessary files can be located. If you do not, the compiles report no error, but the link fails as indicated. -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: Monday, November 05, 2012 10:44 AM To: lee.bayd...@gmail.com Cc: openssl-dev@openssl.org Subject: [openssl.org #2907] Unresolved external referenced in function _EC_GF2m_simple_method when linking 1.0.1c w/ fips-ecp-2.0.2 [lee.bayd...@gmail.com - Mon Nov 05 14:57:30 2012]: When attempting to build openssl-1.0.1c in fips compliant mode, the file crypto/ec/ec2_smpl.c attempts to return the results of function fips_ec_gf2m_simple_method(). This function is not defined in either projects. Did you compile the FIPS capable OpenSSL with the no-ec2m option? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2904] genpkey ignores -outform DER
On Mon, 2012-11-05 at 17:44 +0100, Stephen Henson via RT wrote: [vpodz...@redhat.com - Tue Oct 30 17:34:05 2012]: Description of problem: Running $ openssl genpkey -genparam -outform DER -out dh_params.der -algorithm DH generates data in the PEM format instead of the requested DER format. Version-Release number of selected component (if applicable): openssl-1.0.0j-2.fc17.i686 Steps to Reproduce: 1. run command from the description 2. run 'file dh_params.der' Actual results: ASCII text Expected results: data Additional info: Deprecated (according to openssl(1)) command $ openssl dhparam -outform DER -out dh_params.der works as expected. When the pkey utilities (and associated functions) are presented with a file they have to automatically decide which algorithm to use. This is fine for public and private key formats which include the algorithm OID in the associated structures (SubjectPublicKeyInfo or PKCS#8) or the PEM headers for older private key formats. In the case of parameters there isn't a DER format that includes the algorithm type as an OID, just the PEM format where the algorithm to use is part of the headers. Steve. I'm sorry, but I still don't get why: $ openssl genpkey -genparam -outform DER -out dh_params.der -algorithm DER cannot work the same way as: $ openssl dhparam -outform DER -out dh_params.der And if it really can't, at least some note in the genpkey(1) man page would be nice. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Encrypt/Decrypt in place ?
Can the same pointer safely be used for the input and output buffers in
encrypt and decrypt operations ?
i.e. is something like AES_encrypt(out,out,key) guaranteed not to rewrite
the input before it's been processed ?
The following IMPLIES this is safe but lingering doubts remain.
(from crypto/aes/aes_core.c)
/*
* Encrypt a single block
* in and out can overlap
*/
void AES_encrypt(const unsigned char *in, unsigned char *out, const
AES_KEY *key) {
Note: I'm interested in the general case. AES was just used as an example
of the type of operation and it's the example I found which implied this
works.
Alternatively do any test cases exist that'd fail if someone provided asm
which broke this behaviour ?.
Checking the source code only goes so far, it'd be really hard to verify
all the asm modules.
We could write our own tests for this, but it'd be preferable that the
OpenSSL behaviour was known to preserve this feature - patching some random
asm module to 'fix' a break of this in the future wouldn't be trivial.
Thanks
Peter
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
