| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * Licensed under the Apache License 2.0 (the "License").  You may not use | 
					
						
							|  |  |  |  * this file except in compliance with the License.  You can obtain a copy | 
					
						
							|  |  |  |  * in the file LICENSE in the source distribution or at | 
					
						
							|  |  |  |  * https://www.openssl.org/source/license.html
 | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include <stdio.h>
 | 
					
						
							|  |  |  | #include <openssl/err.h>
 | 
					
						
							|  |  |  | #include <openssl/x509_vfy.h>
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include "testutil.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static const char *chain; | 
					
						
							| 
									
										
										
										
											2024-02-27 22:22:58 +08:00
										 |  |  | static const char *crl; | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  | 
 | 
					
						
							|  |  |  | static int test_load_cert_file(void) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
											  
											
												Add X509_STORE_get1_objects
X509_STORE_get0_objects returns a pointer to the X509_STORE's storage,
but this function is a bit deceptive. It is practically unusable in a
multi-threaded program. See, for example, RUSTSEC-2023-0072, a security
vulnerability caused by this OpenSSL API.
One might think that, if no other threads are mutating the X509_STORE,
it is safe to read the resulting list. However, the documention does not
mention that other logically-const operations on the X509_STORE, notably
certifcate verifications when a hash_dir is installed, will, under a
lock, write to the X509_STORE. The X509_STORE also internally re-sorts
the list on the first query.
If the caller knows to call X509_STORE_lock and X509_STORE_unlock, it
can work around this. But this is not obvious, and the documentation
does not discuss how X509_STORE_lock is very rarely safe to use. E.g.
one cannot call any APIs like X509_STORE_add_cert or
X509_STORE_CTX_get1_issuer while holding the lock because those
functions internally expect to take the lock. (X509_STORE_lock is
another such API which is not safe to export as public API.)
Rather than leave all this to the caller to figure out, the API should
have returned a shallow copy of the list, refcounting the values. Then
it could be internally locked and the caller can freely inspect the
result without synchronization with the X509_STORE.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23224)
											
										 
											2023-12-11 14:47:25 +08:00
										 |  |  |     int ret = 0, i; | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  |     X509_STORE *store = NULL; | 
					
						
							|  |  |  |     X509_LOOKUP *lookup = NULL; | 
					
						
							|  |  |  |     STACK_OF(X509) *certs = NULL; | 
					
						
							| 
									
										
											  
											
												Add X509_STORE_get1_objects
X509_STORE_get0_objects returns a pointer to the X509_STORE's storage,
but this function is a bit deceptive. It is practically unusable in a
multi-threaded program. See, for example, RUSTSEC-2023-0072, a security
vulnerability caused by this OpenSSL API.
One might think that, if no other threads are mutating the X509_STORE,
it is safe to read the resulting list. However, the documention does not
mention that other logically-const operations on the X509_STORE, notably
certifcate verifications when a hash_dir is installed, will, under a
lock, write to the X509_STORE. The X509_STORE also internally re-sorts
the list on the first query.
If the caller knows to call X509_STORE_lock and X509_STORE_unlock, it
can work around this. But this is not obvious, and the documentation
does not discuss how X509_STORE_lock is very rarely safe to use. E.g.
one cannot call any APIs like X509_STORE_add_cert or
X509_STORE_CTX_get1_issuer while holding the lock because those
functions internally expect to take the lock. (X509_STORE_lock is
another such API which is not safe to export as public API.)
Rather than leave all this to the caller to figure out, the API should
have returned a shallow copy of the list, refcounting the values. Then
it could be internally locked and the caller can freely inspect the
result without synchronization with the X509_STORE.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23224)
											
										 
											2023-12-11 14:47:25 +08:00
										 |  |  |     STACK_OF(X509_OBJECT) *objs = NULL; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     if (!TEST_ptr(store = X509_STORE_new()) | 
					
						
							|  |  |  |         || !TEST_ptr(lookup = X509_STORE_add_lookup(store, X509_LOOKUP_file())) | 
					
						
							|  |  |  |         || !TEST_true(X509_load_cert_file(lookup, chain, X509_FILETYPE_PEM)) | 
					
						
							|  |  |  |         || !TEST_ptr(certs = X509_STORE_get1_all_certs(store)) | 
					
						
							|  |  |  |         || !TEST_int_eq(sk_X509_num(certs), 4) | 
					
						
							|  |  |  |         || !TEST_ptr(objs = X509_STORE_get1_objects(store)) | 
					
						
							|  |  |  |         || !TEST_int_eq(sk_X509_OBJECT_num(objs), 4)) | 
					
						
							|  |  |  |         goto err; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     for (i = 0; i < sk_X509_OBJECT_num(objs); i++) { | 
					
						
							|  |  |  |         const X509_OBJECT *obj = sk_X509_OBJECT_value(objs, i); | 
					
						
							|  |  |  |         if (!TEST_int_eq(X509_OBJECT_get_type(obj), X509_LU_X509)) | 
					
						
							|  |  |  |             goto err; | 
					
						
							|  |  |  |     } | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-02-27 22:22:58 +08:00
										 |  |  |     if (crl != NULL && !TEST_true(X509_load_crl_file(lookup, crl, X509_FILETYPE_PEM))) | 
					
						
							|  |  |  |         goto err; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												Add X509_STORE_get1_objects
X509_STORE_get0_objects returns a pointer to the X509_STORE's storage,
but this function is a bit deceptive. It is practically unusable in a
multi-threaded program. See, for example, RUSTSEC-2023-0072, a security
vulnerability caused by this OpenSSL API.
One might think that, if no other threads are mutating the X509_STORE,
it is safe to read the resulting list. However, the documention does not
mention that other logically-const operations on the X509_STORE, notably
certifcate verifications when a hash_dir is installed, will, under a
lock, write to the X509_STORE. The X509_STORE also internally re-sorts
the list on the first query.
If the caller knows to call X509_STORE_lock and X509_STORE_unlock, it
can work around this. But this is not obvious, and the documentation
does not discuss how X509_STORE_lock is very rarely safe to use. E.g.
one cannot call any APIs like X509_STORE_add_cert or
X509_STORE_CTX_get1_issuer while holding the lock because those
functions internally expect to take the lock. (X509_STORE_lock is
another such API which is not safe to export as public API.)
Rather than leave all this to the caller to figure out, the API should
have returned a shallow copy of the list, refcounting the values. Then
it could be internally locked and the caller can freely inspect the
result without synchronization with the X509_STORE.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23224)
											
										 
											2023-12-11 14:47:25 +08:00
										 |  |  |     ret = 1; | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												Add X509_STORE_get1_objects
X509_STORE_get0_objects returns a pointer to the X509_STORE's storage,
but this function is a bit deceptive. It is practically unusable in a
multi-threaded program. See, for example, RUSTSEC-2023-0072, a security
vulnerability caused by this OpenSSL API.
One might think that, if no other threads are mutating the X509_STORE,
it is safe to read the resulting list. However, the documention does not
mention that other logically-const operations on the X509_STORE, notably
certifcate verifications when a hash_dir is installed, will, under a
lock, write to the X509_STORE. The X509_STORE also internally re-sorts
the list on the first query.
If the caller knows to call X509_STORE_lock and X509_STORE_unlock, it
can work around this. But this is not obvious, and the documentation
does not discuss how X509_STORE_lock is very rarely safe to use. E.g.
one cannot call any APIs like X509_STORE_add_cert or
X509_STORE_CTX_get1_issuer while holding the lock because those
functions internally expect to take the lock. (X509_STORE_lock is
another such API which is not safe to export as public API.)
Rather than leave all this to the caller to figure out, the API should
have returned a shallow copy of the list, refcounting the values. Then
it could be internally locked and the caller can freely inspect the
result without synchronization with the X509_STORE.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23224)
											
										 
											2023-12-11 14:47:25 +08:00
										 |  |  | err: | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  |     OSSL_STACK_OF_X509_free(certs); | 
					
						
							| 
									
										
											  
											
												Add X509_STORE_get1_objects
X509_STORE_get0_objects returns a pointer to the X509_STORE's storage,
but this function is a bit deceptive. It is practically unusable in a
multi-threaded program. See, for example, RUSTSEC-2023-0072, a security
vulnerability caused by this OpenSSL API.
One might think that, if no other threads are mutating the X509_STORE,
it is safe to read the resulting list. However, the documention does not
mention that other logically-const operations on the X509_STORE, notably
certifcate verifications when a hash_dir is installed, will, under a
lock, write to the X509_STORE. The X509_STORE also internally re-sorts
the list on the first query.
If the caller knows to call X509_STORE_lock and X509_STORE_unlock, it
can work around this. But this is not obvious, and the documentation
does not discuss how X509_STORE_lock is very rarely safe to use. E.g.
one cannot call any APIs like X509_STORE_add_cert or
X509_STORE_CTX_get1_issuer while holding the lock because those
functions internally expect to take the lock. (X509_STORE_lock is
another such API which is not safe to export as public API.)
Rather than leave all this to the caller to figure out, the API should
have returned a shallow copy of the list, refcounting the values. Then
it could be internally locked and the caller can freely inspect the
result without synchronization with the X509_STORE.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23224)
											
										 
											2023-12-11 14:47:25 +08:00
										 |  |  |     sk_X509_OBJECT_pop_free(objs, X509_OBJECT_free); | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  |     X509_STORE_free(store); | 
					
						
							|  |  |  |     return ret; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-02-27 22:22:58 +08:00
										 |  |  | OPT_TEST_DECLARE_USAGE("cert.pem [crl.pem]\n") | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  | 
 | 
					
						
							|  |  |  | int setup_tests(void) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |     if (!test_skip_common_options()) { | 
					
						
							|  |  |  |         TEST_error("Error parsing test options\n"); | 
					
						
							|  |  |  |         return 0; | 
					
						
							|  |  |  |     } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     chain = test_get_argument(0); | 
					
						
							|  |  |  |     if (chain == NULL) | 
					
						
							|  |  |  |         return 0; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2024-02-27 22:22:58 +08:00
										 |  |  |     crl = test_get_argument(1); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2023-12-01 00:57:45 +08:00
										 |  |  |     ADD_TEST(test_load_cert_file); | 
					
						
							|  |  |  |     return 1; | 
					
						
							|  |  |  | } |