Forthcoming OpenSSL Releases
Hello, The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 3.0.6 and 1.1.1r. These releases will be made available on Tuesday 11th October 2022 between 1300-1700 UTC. OpenSSL 3.0.6 is a security-fix release. The highest severity issue fixed in OpenSSL 3.0.6 is Low: https://www.openssl.org/policies/secpolicy.html OpenSSL 1.1.1 is a bug-fix release. There are no security issues fixed in this release. Yours The OpenSSL Project Team OpenPGP_0xD9C4D26D0E604491.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: BIO_flush Segmentation Fault Issue
Thanks. I wrote some simple tests to exercise this and it worked correctly. I was just not seeing how. Jay On 10/3/2022 11:26 PM, Tomas Mraz wrote: Your analysis is correct. However the library is still correct in regards to refcounting even for an SSL BIO in the chain. The reason is that the decrement of refcount of the BIOs underlying the SSL BIO is handled through the actual freeing of the SSL BIO. If the refcount for the SSL BIO in the chain freed by BIO_free_all() drops to zero, it will, in ssl_free() call in bio_ssl.c, free the underlying SSL * object. And if the refcount of that SSL object drops to zero it will call BIO_free_all() on the underlying wbio and rbio. Which means also the chained BIOs underlying the SSL BIO will have their refcount dropped and they will be properly freed. Tomas Mraz, OpenSSL On Mon, 2022-10-03 at 09:35 -0700, Jay Foster wrote: Your response makes sense. I am a bit puzzled by the BIO reference counting. For example BIO_new() (or BIO_new_socket() which calls BIO_new()) produces a BIO with a reference count of 1. BIO_free() drops 1 reference and if the reference count is 0, frees the BIO. BIO_push() connects the BIO to the BIO chain. No references are directly changed. However, the BIO_CTRL_PUSH command is sent to the BIO. For the SSL BIO, this results in a call to SSL_set_bio() and adding 1 to the next_bio reference (socket BIO). BIO_pop() calls BIO_CTRL_POP and disconnects the BIO from the BIO chain. For the SSL BIO, the BIO_CTRL_POP subtracts one from the next_bio reference (undoing BIO_push()). The problem case is calling BIO_free_all() on the BIO chain. BIO_free_all() does not use BIO_pop(). It simply detaches each BIO from the chain, and calls BIO_free() for it. If the next_bio reference count is > 1 (which it will be for the SSL BIO next_bio), it stops unlinking and freeing BIOs. This seems asymmetrical with respect to the BIO reference counting, and leaks the next_bio (socket BIO in this case). What am I missing here? Jay On 9/29/2022 11:50 PM, Tomas Mraz wrote: The SSL BIO should have the rbio from the SSL object as the next BIO. If you create the SSL BIO and then BIO_push() the TCP socket BIO into the SSL BIO, it will work correctly. Otherwise, you can just fix the next BIO of the SSL BIO by using BIO_up_ref(socketbio); BIO_set_next(sslbio, socketbio); The SSL BIO should always have a next BIO if properly initialized. Tomas Mraz, OpenSSL On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote: I have an application that constructs a chain of BIOs. Sometimes this chain also includes an SSL BIO. Years ago, I ran into a problem that caused BIO_flush() to segfault on the SSL BIO. This turned out to happen because the SSL BIO is added using SSL_set_bio() instead of BIO_push(). SSL_set_bio() results in the SSL BIO always having a NULL bio_next value, so BIO_flush then crashes dereferencing this NULL pointer when it calls BIO_copy_next_retry() on the SSL BIO (see BIO_CTRL_FLUSH in ssl/bio_ssl.c). This was reported as ticket 2615 years ago. My question is, how could calling BIO_flush() on a BIO chain with an SSL BIO ever work? Is there a way to add the SSL BIO using BIO_push() instead of SSL_set_bio()? Jay
Re: BIO_flush Segmentation Fault Issue
Your analysis is correct. However the library is still correct in regards to refcounting even for an SSL BIO in the chain. The reason is that the decrement of refcount of the BIOs underlying the SSL BIO is handled through the actual freeing of the SSL BIO. If the refcount for the SSL BIO in the chain freed by BIO_free_all() drops to zero, it will, in ssl_free() call in bio_ssl.c, free the underlying SSL * object. And if the refcount of that SSL object drops to zero it will call BIO_free_all() on the underlying wbio and rbio. Which means also the chained BIOs underlying the SSL BIO will have their refcount dropped and they will be properly freed. Tomas Mraz, OpenSSL On Mon, 2022-10-03 at 09:35 -0700, Jay Foster wrote: > Your response makes sense. I am a bit puzzled by the BIO reference > counting. For example > > BIO_new() (or BIO_new_socket() which calls BIO_new()) produces a > BIO with a reference count of 1. > BIO_free() drops 1 reference and if the reference count is 0, > frees > the BIO. > > BIO_push() connects the BIO to the BIO chain. No references are > directly changed. However, the BIO_CTRL_PUSH command is sent to the > BIO. For the SSL BIO, this results in a call to SSL_set_bio() and > adding 1 to the next_bio reference (socket BIO). > BIO_pop() calls BIO_CTRL_POP and disconnects the BIO from the > BIO > chain. For the SSL BIO, the BIO_CTRL_POP subtracts one from the > next_bio reference (undoing BIO_push()). > > The problem case is calling BIO_free_all() on the BIO chain. > BIO_free_all() does not use BIO_pop(). It simply detaches each BIO > from > the chain, and calls BIO_free() for it. If the next_bio reference > count > is > 1 (which it will be for the SSL BIO next_bio), it stops > unlinking > and freeing BIOs. This seems asymmetrical with respect to the BIO > reference counting, and leaks the next_bio (socket BIO in this case). > > What am I missing here? > Jay > > > On 9/29/2022 11:50 PM, Tomas Mraz wrote: > > The SSL BIO should have the rbio from the SSL object as the next > > BIO. > > If you create the SSL BIO and then BIO_push() the TCP socket BIO > > into > > the SSL BIO, it will work correctly. > > > > Otherwise, you can just fix the next BIO of the SSL BIO by using > > > > BIO_up_ref(socketbio); > > BIO_set_next(sslbio, socketbio); > > > > The SSL BIO should always have a next BIO if properly initialized. > > > > Tomas Mraz, OpenSSL > > > > On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote: > > > I have an application that constructs a chain of BIOs. Sometimes > > > this > > > chain also includes an SSL BIO. Years ago, I ran into a problem > > > that > > > caused BIO_flush() to segfault on the SSL BIO. This turned out > > > to > > > happen because the SSL BIO is added using SSL_set_bio() instead > > > of > > > BIO_push(). SSL_set_bio() results in the SSL BIO always having a > > > NULL > > > bio_next value, so BIO_flush then crashes dereferencing this NULL > > > pointer when it calls BIO_copy_next_retry() on the SSL BIO (see > > > BIO_CTRL_FLUSH in ssl/bio_ssl.c). > > > > > > This was reported as ticket 2615 years ago. > > > > > > My question is, how could calling BIO_flush() on a BIO chain with > > > an > > > SSL > > > BIO ever work? Is there a way to add the SSL BIO using > > > BIO_push() > > > instead of SSL_set_bio()? > > > > > > Jay > > > > -- Tomáš Mráz, OpenSSL