[openssl.org #2167] [PATCH 1.0.1e] openssl/ssl/s3_pkt.c SSL multiple threads and SSL_MODE_RELEASE_BUFFERS

[Petter Reinholdtsen via RT]

Why is this issue still open?  Something wrong with the patch?

The problem described is assigned CVE-2010-5298 and further described in
URL: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5298 
and URL: https://security-tracker.debian.org/tracker/CVE-2010-5298 .

-- 
Happy hacking
Petter Reinholdtsen


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2167] [PATCH 1.0.1e] openssl/ssl/s3_pkt.c SSL multiple threads and SSL_MODE_RELEASE_BUFFERS

[Petter Reinholdtsen via RT]

[Petter Reinholdtsen]
 Why is this issue still open?  Something wrong with the patch?

I guess not, as I just noticed it was commited today in
URL: 
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=94d1f4b0f3d262edf1cf7023a01d5404945035d5
 .

Thank you.

This issue seem to be reported also in 
URL: https://rt.openssl.org/Ticket/Display.html?id=3265 , I guess
these tickets should be merged before closing.

-- 
Happy hacking
Petter Reinholdtsen


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2167] [PATCH 1.0.1e] openssl/ssl/s3_pkt.c SSL multiple threads and SSL_MODE_RELEASE_BUFFERS

[bensonkwok...@air-watch.com via RT]

I have found a problem with SSL_MODE_RELEASE_BUFFERS and with
multithreading when using version 1.0.1e.  This issue has already been
logged by someone at rt.openssl.org and the ticket # is 2167.

The issue is when the buffer is released by ssl3_release_read_buffer(),
there may still be data left in the buffer (s-s3-rbuf.left != 0). With
single threading, when another read occurs, the same buffer is reused
during a call to ssl3_setup_read_buffer() so the data is still there and
can be read and processed so it works fine. When running with multiple
threads, the buffer is shared in a pool and another thread may have gotten
that buffer already. If the call to ssl3_setup_read_buffer() returns a new
buffer, it assume the data is still there but will run into parsing error
with the record.

The fix I did was to check s-s3-rbuf.left and only call
ssl3_release_read_buffer() when s-s3-rbuf.left is zero.  This delays the
release of the buffer until all the data has processed.  The fix seems to
fix the issue.

Here is a patch of the changes:


--- s3_pkt_original.c   2013-02-11 10:26:04 -0500
+++ s3_pkt.c2013-09-18 10:15:47 -0400
@@ -1055,7 +1055,7 @@
{
s-rstate=SSL_ST_READ_HEADER;
rr-off=0;
-   if (s-mode  SSL_MODE_RELEASE_BUFFERS)
+   if (s-mode  SSL_MODE_RELEASE_BUFFERS  s-s3-rbuf.left
== 0)
ssl3_release_read_buffer(s);
}
}





Best Regards,

Benson Kwok
Development 
Www.air-watch.com

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org