Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c
This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here
is a brief analysis:
Consider sv_body() in server.c
2237 con=SSL_new(ctx);
Here a new context is initialized. From ssl_lib.c:295, this also causes the
krb context to be initialized via
295 s-kssl_ctx = kssl_ctx_new();
So SSL_new basically also allocates memory for con-kssl
Later in sv_body() at line 2252:
2252 if ((kctx = kssl_ctx_new()) != NULL)
2253 {
2254 SSL_set0_kssl_ctx(con, kctx);
This causes con-kssl_ctx to be rewritten by kctx, in doing so 56 bytes of
previously allocated memory is lost
and hence the memory leak for each connection made.
On Thu, Jan 15, 2015 at 6:55 PM, Huzaifa Sidhpurwala via RT r...@openssl.org
wrote:
Here is how to test it:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt
-subj \
/CN=localhost -nodes -batch -sha256
valgrind --leak-check=full openssl s_server -key localhost.key -cert \
localhost.crt -accept 4433
./poc.py
Every run of poc.py causes 56 byte memory leak:
==11278== HEAP SUMMARY:
==11278== in use at exit: 910,716 bytes in 20,383 blocks
==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes
allocated
==11278==
==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of
823
==11278==at 0x4C2745D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-
amd64-linux.so)
==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308)
==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790)
==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295)
==11278==by 0x436387: sv_body (s_server.c:2004)
==11278==by 0x44AC30: do_server (s_socket.c:324)
==11278==by 0x439C36: s_server_main (s_server.c:1901)
==11278==by 0x419377: do_cmd (openssl.c:489)
==11278==by 0x41906D: main (openssl.c:381)
==11278==
==11278== LEAK SUMMARY:
==11278==definitely lost: 56 bytes in 1 blocks
==11278==indirectly lost: 0 bytes in 0 blocks
==11278== possibly lost: 0 bytes in 0 blocks
==11278==still reachable: 910,660 bytes in 20,382 blocks
==11278== suppressed: 0 bytes in 0 blocks
==11278== Reachable blocks (those to which a pointer was found) are not
shown.
==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11278==
==11278== For counts of detected and suppressed errors, rerun with: -v
==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Acknowledgement Text Required: Yes
Community Trackers Required : Yes
Ticket Response Required : Yes
poc.py is attached
On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT
r...@openssl.org
wrote:
Hi,
I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
bytes for each connection request.
Patch is attached.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3660] Memory leak in s_server.c
Hi, I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 bytes for each connection request. Patch is attached. patch Description: Binary data ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c
Here is how to test it: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \ /CN=localhost -nodes -batch -sha256 valgrind --leak-check=full openssl s_server -key localhost.key -cert \ localhost.crt -accept 4433 ./poc.py Every run of poc.py causes 56 byte memory leak: ==11278== HEAP SUMMARY: ==11278== in use at exit: 910,716 bytes in 20,383 blocks ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes allocated ==11278== ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of 823 ==11278==at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so) ==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308) ==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790) ==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295) ==11278==by 0x436387: sv_body (s_server.c:2004) ==11278==by 0x44AC30: do_server (s_socket.c:324) ==11278==by 0x439C36: s_server_main (s_server.c:1901) ==11278==by 0x419377: do_cmd (openssl.c:489) ==11278==by 0x41906D: main (openssl.c:381) ==11278== ==11278== LEAK SUMMARY: ==11278==definitely lost: 56 bytes in 1 blocks ==11278==indirectly lost: 0 bytes in 0 blocks ==11278== possibly lost: 0 bytes in 0 blocks ==11278==still reachable: 910,660 bytes in 20,382 blocks ==11278== suppressed: 0 bytes in 0 blocks ==11278== Reachable blocks (those to which a pointer was found) are not shown. ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==11278== ==11278== For counts of detected and suppressed errors, rerun with: -v ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Acknowledgement Text Required: Yes Community Trackers Required : Yes Ticket Response Required : Yes poc.py is attached On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT r...@openssl.org wrote: Hi, I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 bytes for each connection request. Patch is attached. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev #!/usr/bin/python import socket # a SSL 3.0 Client Hello with no ciphers and default compression method (null) s = bytearray(b\x16\x03\x00\x00+\x01\x00\x00\'\x03\x00\x00\x00\x00\x00\x00 + b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 + b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00) sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((127.0.0.1, 4433)) sock.sendall(s) sock.close() ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c
Here is how to test it: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \ /CN=localhost -nodes -batch -sha256 valgrind --leak-check=full openssl s_server -key localhost.key -cert \ localhost.crt -accept 4433 ./poc.py Every run of poc.py causes 56 byte memory leak: ==11278== HEAP SUMMARY: ==11278== in use at exit: 910,716 bytes in 20,383 blocks ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes allocated ==11278== ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of 823 ==11278==at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so) ==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308) ==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790) ==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295) ==11278==by 0x436387: sv_body (s_server.c:2004) ==11278==by 0x44AC30: do_server (s_socket.c:324) ==11278==by 0x439C36: s_server_main (s_server.c:1901) ==11278==by 0x419377: do_cmd (openssl.c:489) ==11278==by 0x41906D: main (openssl.c:381) ==11278== ==11278== LEAK SUMMARY: ==11278==definitely lost: 56 bytes in 1 blocks ==11278==indirectly lost: 0 bytes in 0 blocks ==11278== possibly lost: 0 bytes in 0 blocks ==11278==still reachable: 910,660 bytes in 20,382 blocks ==11278== suppressed: 0 bytes in 0 blocks ==11278== Reachable blocks (those to which a pointer was found) are not shown. ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==11278== ==11278== For counts of detected and suppressed errors, rerun with: -v ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Acknowledgement Text Required: Yes Community Trackers Required : Yes Ticket Response Required : Yes poc.py is attached On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT r...@openssl.org wrote: Hi, I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 bytes for each connection request. Patch is attached. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev #!/usr/bin/python import socket # a SSL 3.0 Client Hello with no ciphers and default compression method (null) s = bytearray(b\x16\x03\x00\x00+\x01\x00\x00\'\x03\x00\x00\x00\x00\x00\x00 + b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 + b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00) sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((127.0.0.1, 4433)) sock.sendall(s) sock.close() ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c
This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here
is a brief analysis:
Consider sv_body() in server.c
2237 con=SSL_new(ctx);
Here a new context is initialized. From ssl_lib.c:295, this also causes the
krb context to be initialized via
295 s-kssl_ctx = kssl_ctx_new();
So SSL_new basically also allocates memory for con-kssl
Later in sv_body() at line 2252:
2252 if ((kctx = kssl_ctx_new()) != NULL)
2253 {
2254 SSL_set0_kssl_ctx(con, kctx);
This causes con-kssl_ctx to be rewritten by kctx, in doing so 56 bytes of
previously allocated memory is lost
and hence the memory leak for each connection made.
On Thu, Jan 15, 2015 at 6:55 PM, Huzaifa Sidhpurwala via RT r...@openssl.org
wrote:
Here is how to test it:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt
-subj \
/CN=localhost -nodes -batch -sha256
valgrind --leak-check=full openssl s_server -key localhost.key -cert \
localhost.crt -accept 4433
./poc.py
Every run of poc.py causes 56 byte memory leak:
==11278== HEAP SUMMARY:
==11278== in use at exit: 910,716 bytes in 20,383 blocks
==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes
allocated
==11278==
==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of
823
==11278==at 0x4C2745D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-
amd64-linux.so)
==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308)
==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790)
==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295)
==11278==by 0x436387: sv_body (s_server.c:2004)
==11278==by 0x44AC30: do_server (s_socket.c:324)
==11278==by 0x439C36: s_server_main (s_server.c:1901)
==11278==by 0x419377: do_cmd (openssl.c:489)
==11278==by 0x41906D: main (openssl.c:381)
==11278==
==11278== LEAK SUMMARY:
==11278==definitely lost: 56 bytes in 1 blocks
==11278==indirectly lost: 0 bytes in 0 blocks
==11278== possibly lost: 0 bytes in 0 blocks
==11278==still reachable: 910,660 bytes in 20,382 blocks
==11278== suppressed: 0 bytes in 0 blocks
==11278== Reachable blocks (those to which a pointer was found) are not
shown.
==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11278==
==11278== For counts of detected and suppressed errors, rerun with: -v
==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Acknowledgement Text Required: Yes
Community Trackers Required : Yes
Ticket Response Required : Yes
poc.py is attached
On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT
r...@openssl.org
wrote:
Hi,
I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
bytes for each connection request.
Patch is attached.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #3414] OpenSSL: Status of official fix for CVE-2014-0198
On Tue, Jul 1, 2014 at 3:03 PM, Manjesh HS via RT r...@openssl.org wrote: Hi, My project is currently using OpenSSL-1.0.1g package and we are monitoring the security vulenrabilities being reported to this package. I would like to know the status of official fix for CVE-2014-0198 bug. Is this fixed in OpenSSL-1.0.1h version ? The below link does not list CVE-2014-0198, in the release notes of 1.0.1h version: https://www.openssl.org/news/openssl-1.0.1-notes.html But the below link lists CVE-2014-0198 that it is already fixed: https://www.openssl.org/news/vulnerabilities.html The above page clearly says: Fixed in OpenSSL 1.0.1h (Affected 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) What part of this is not clear?
Re: EVP_CIPHER_CTX_copy() segv with XTS
Hi Peter, Are you facing any issues similar to http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=3272 ? or are just commenting on the previous GCM fix? A quick look at the EVP_AES_XTS_CTX suggests that the only pointer in there is (*stream) which points to the function which is responsible for doing encryption/decryption and should be safe to copy to the new CTX On Mon, Jun 30, 2014 at 9:42 AM, Peter Waltenberg pwal...@au1.ibm.com wrote: This appears to be the same 'pattern' error as GCM. For XTS ctx- cipher_data contains pointers and the contents are aren't being fully duplicated by the copy. Peter __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP_CIPHER_CTX_copy() segv with XTS
On Mon, Jun 30, 2014 at 5:01 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Jun 30, 2014, Huzaifa Sidhpurwala wrote: Hi Peter, Are you facing any issues similar to http://rt.openssl.org/Ticket/Display.html?user=guestpass=guestid=3272 ? or are just commenting on the previous GCM fix? A quick look at the EVP_AES_XTS_CTX suggests that the only pointer in there is (*stream) which points to the function which is responsible for doing encryption/decryption and should be safe to copy to the new CTX GCM, CCM and XTS have similar problems in fact the GCM patch doesn't address these. Looking into a more complete fix now. Exactly, i was thinking of working on a patch to address this, should be done soon i suppose :) 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-1.0.0m on Fedora Core 16
On Fri, Jun 20, 2014 at 4:23 AM, Bernal, Daniel L daniel.l.ber...@intel.com wrote: I have built a 1.0.0m version of openSSL which I am looking to support on Fedora Core 16 (FC16). It configures, builds, and tests just fine on the platform but I notice that if I build an RPM based on the provided openssl.spec file it does not match what was installed by the currently installed 1.0.0j package. I then proceeded to create a binary package based on the openSSL 1.0.0j source package and it does not create a binary package like what is currently installed as 1.0.0j on my FC16 system. This leads me to believe that the currently installed openssl-1.0.0j-1.i686.rpm is a specially created version for FC16. Looking for advice on how to proceed to minimize the amount of regression testing I needs to do on this older FC16 unsupported platform. Regardless I need to upgrade to 1.0.0m on my FC16 platform. TIA, I am confused, are you saying that your 1.0.0m build does not match 1.0.0j build? I think they should be API compatible, so your apps should not really break, if that is what you are asking!
Re: [openssl.org #3305] Cppcheck report
If anyone is interested in committing, i created a pull request with my patch at: https://github.com/openssl/openssl/pull/139 Regards, Huzaifa Sidhpurwala On Wed, Jun 18, 2014 at 3:40 PM, Huzaifa Sidhpurwala via RT r...@openssl.org wrote: Resending this with the correct To: field, so that it would append this to the RT ticket. Regards, Huzaifa Sidhpurwala On Wed, Jun 18, 2014 at 3:18 PM, Huzaifa Sidhpurwala sidhpurwala.huza...@gmail.com wrote: The enclosed patch addresses all the issues discussed above. On Wed, Jun 18, 2014 at 2:38 PM, Kurt Cancemi via RT r...@openssl.org wrote: Hello, The attached patch removes a duplicate or check (the first problem listed in this ticket). Regards, Kurt Cancemi
Re: [openssl.org #3305] Cppcheck report
If anyone is interested in committing, i created a pull request with my patch at: https://github.com/openssl/openssl/pull/139 Regards, Huzaifa Sidhpurwala On Wed, Jun 18, 2014 at 3:40 PM, Huzaifa Sidhpurwala via RT r...@openssl.org wrote: Resending this with the correct To: field, so that it would append this to the RT ticket. Regards, Huzaifa Sidhpurwala On Wed, Jun 18, 2014 at 3:18 PM, Huzaifa Sidhpurwala sidhpurwala.huza...@gmail.com wrote: The enclosed patch addresses all the issues discussed above. On Wed, Jun 18, 2014 at 2:38 PM, Kurt Cancemi via RT r...@openssl.org wrote: Hello, The attached patch removes a duplicate or check (the first problem listed in this ticket). Regards, Kurt Cancemi __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3410] [patch] Make sure the return BIGNUM from BN_sqr cannot be negative under any condition
Hi All,
I was looking at the bugs reported in openssl bignum implementation at:
http://seclists.org/fulldisclosure/2013/Dec/8
Most of them are false positives or abuse of the API/internal bignum
structure.
I have put some details here:
https://bugzilla.redhat.com/show_bug.cgi?id=1038999
There is only one which looks like a minor issue to me and i have an
attached a patch to correct it.
Consider the code-snippet below:
BIGNUM *z,*o;
BN_CTX *ctx = BN_CTX_new();
z = BN_new();
o = BN_new();
BN_zero(z);
BN_one(o);
BN_set_negative(o, 1);
BN_sqr(o, z, ctx);
printf(%s\n, BN_bn2hex(o));
I know its wrong to mangle 'o' before passing it to BN_sqr, but just
in case someone does this,
this patch should address the problem.
commit 84a8e4cdb1a49808c44fc2ae3a1d5ef5c125c2a3
Author: Huzaifa Sidhpurwala huzai...@redhat.com
Date: Thu Jun 19 12:33:39 2014 +0530
Make sure BN_sqr can never return a negative number,
even though the output BN is mangled
diff --git a/crypto/bn/bn_sqr.c b/crypto/bn/bn_sqr.c
index 270d0cd..7b98e1c 100644
--- a/crypto/bn/bn_sqr.c
+++ b/crypto/bn/bn_sqr.c
@@ -77,6 +77,7 @@ int BN_sqr(BIGNUM *r, const BIGNUM *a, BN_CTX *ctx)
if (al = 0)
{
r-top=0;
+ r-neg=0; /* just to make sure */
return 1;
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3410] AutoReply: [patch] Make sure the return BIGNUM from BN_sqr cannot be negative under any condition
Created a pull request at:
https://github.com/openssl/openssl/pull/140
On Thu, Jun 19, 2014 at 1:08 PM, The default queue via RT r...@openssl.org
wrote:
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
[patch] Make sure the return BIGNUM from BN_sqr cannot be
negative under any condition,
a summary of which appears below.
There is no need to reply to this message right now. Your ticket has been
assigned an ID of [openssl.org #3410].
Please include the string:
[openssl.org #3410]
in the subject line of all future correspondence about this issue. To do
so,
you may reply to this message.
Thank you,
r...@openssl.org
-
Hi All,
I was looking at the bugs reported in openssl bignum implementation at:
http://seclists.org/fulldisclosure/2013/Dec/8
Most of them are false positives or abuse of the API/internal bignum
structure.
I have put some details here:
https://bugzilla.redhat.com/show_bug.cgi?id=1038999
There is only one which looks like a minor issue to me and i have an
attached a patch to correct it.
Consider the code-snippet below:
BIGNUM *z,*o;
BN_CTX *ctx = BN_CTX_new();
z = BN_new();
o = BN_new();
BN_zero(z);
BN_one(o);
BN_set_negative(o, 1);
BN_sqr(o, z, ctx);
printf(%s\n, BN_bn2hex(o));
I know its wrong to mangle 'o' before passing it to BN_sqr, but just
in case someone does this,
this patch should address the problem.
commit 84a8e4cdb1a49808c44fc2ae3a1d5ef5c125c2a3
Author: Huzaifa Sidhpurwala huzai...@redhat.com
Date: Thu Jun 19 12:33:39 2014 +0530
Make sure BN_sqr can never return a negative number,
even though the output BN is mangled
diff --git a/crypto/bn/bn_sqr.c b/crypto/bn/bn_sqr.c
index 270d0cd..7b98e1c 100644
--- a/crypto/bn/bn_sqr.c
+++ b/crypto/bn/bn_sqr.c
@@ -77,6 +77,7 @@ int BN_sqr(BIGNUM *r, const BIGNUM *a, BN_CTX *ctx)
if (al = 0)
{
r-top=0;
+ r-neg=0; /* just to make sure */
return 1;
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3305] Cppcheck report
The enclosed patch addresses all the issues discussed above.
On Wed, Jun 18, 2014 at 2:38 PM, Kurt Cancemi via RT r...@openssl.org wrote:
Hello,
The attached patch removes a duplicate or check (the first problem listed
in this ticket).
Regards,
Kurt Cancemi
diff --git a/crypto/store/str_lib.c b/crypto/store/str_lib.c
index f1dbcbd..4de1d34 100644
--- a/crypto/store/str_lib.c
+++ b/crypto/store/str_lib.c
@@ -667,7 +667,7 @@ EVP_PKEY *STORE_get_public_key(STORE *s, OPENSSL_ITEM attributes[],
object = s-meth-get_object(s, STORE_OBJECT_TYPE_PUBLIC_KEY,
attributes, parameters);
- if (!object || !object-data.key || !object-data.key)
+ if (!object || !object-data.key)
{
STOREerr(STORE_F_STORE_GET_PUBLIC_KEY,
STORE_R_FAILED_GETTING_KEY);
diff --git a/fips/aes/fips_aesavs.c b/fips/aes/fips_aesavs.c
index fecaf99..ca303e8 100644
--- a/fips/aes/fips_aesavs.c
+++ b/fips/aes/fips_aesavs.c
@@ -918,6 +918,7 @@ int main(int argc, char **argv)
if (proc_file(rfn, rspfile))
{
printf( Processing failed for: %s \n, rfn);
+ fclose(fp);
return 1;
}
}
diff --git a/ssl/d1_pkt.c b/ssl/d1_pkt.c
index 611fc8d..da41dea 100644
--- a/ssl/d1_pkt.c
+++ b/ssl/d1_pkt.c
@@ -758,11 +758,9 @@ int dtls1_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
if (!ssl3_setup_buffers(s))
return(-1);
-/* XXX: check what the second ' type' is about */
- if ((type (type != SSL3_RT_APPLICATION_DATA)
- (type != SSL3_RT_HANDSHAKE) type) ||
- (peek (type != SSL3_RT_APPLICATION_DATA)))
- {
+ if ((type type != SSL3_RT_APPLICATION_DATA type != SSL3_RT_HANDSHAKE) ||
+ (peek (type != SSL3_RT_APPLICATION_DATA))) {
+ {
SSLerr(SSL_F_DTLS1_READ_BYTES, ERR_R_INTERNAL_ERROR);
return -1;
}
diff --git a/ssl/ssl_task.c b/ssl/ssl_task.c
index b5ce44b..e8c04da 100644
--- a/ssl/ssl_task.c
+++ b/ssl/ssl_task.c
@@ -306,14 +306,14 @@ int doit(io_channel chan, SSL_CTX *s_ctx )
}
if ( length RPC_HDR_SIZE ) {
printf(Error in main loop get size: %d\n, length );
- break;
link_state = 3;
+ break;
}
if ( msg.channel != 'A' ) {
printf(Error in main loop, unexpected channel: %c\n,
msg.channel );
- break;
link_state = 3;
+ break;
}
if ( msg.function == 'G' ) {
link_state = 1;
Re: [openssl.org #3305] Cppcheck report
Resending this with the correct To: field, so that it would append this to
the RT ticket.
Regards,
Huzaifa Sidhpurwala
On Wed, Jun 18, 2014 at 3:18 PM, Huzaifa Sidhpurwala
sidhpurwala.huza...@gmail.com wrote:
The enclosed patch addresses all the issues discussed above.
On Wed, Jun 18, 2014 at 2:38 PM, Kurt Cancemi via RT r...@openssl.org
wrote:
Hello,
The attached patch removes a duplicate or check (the first problem listed
in this ticket).
Regards,
Kurt Cancemi
diff --git a/crypto/store/str_lib.c b/crypto/store/str_lib.c
index f1dbcbd..4de1d34 100644
--- a/crypto/store/str_lib.c
+++ b/crypto/store/str_lib.c
@@ -667,7 +667,7 @@ EVP_PKEY *STORE_get_public_key(STORE *s, OPENSSL_ITEM attributes[],
object = s-meth-get_object(s, STORE_OBJECT_TYPE_PUBLIC_KEY,
attributes, parameters);
- if (!object || !object-data.key || !object-data.key)
+ if (!object || !object-data.key)
{
STOREerr(STORE_F_STORE_GET_PUBLIC_KEY,
STORE_R_FAILED_GETTING_KEY);
diff --git a/fips/aes/fips_aesavs.c b/fips/aes/fips_aesavs.c
index fecaf99..ca303e8 100644
--- a/fips/aes/fips_aesavs.c
+++ b/fips/aes/fips_aesavs.c
@@ -918,6 +918,7 @@ int main(int argc, char **argv)
if (proc_file(rfn, rspfile))
{
printf( Processing failed for: %s \n, rfn);
+ fclose(fp);
return 1;
}
}
diff --git a/ssl/d1_pkt.c b/ssl/d1_pkt.c
index 611fc8d..da41dea 100644
--- a/ssl/d1_pkt.c
+++ b/ssl/d1_pkt.c
@@ -758,11 +758,9 @@ int dtls1_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
if (!ssl3_setup_buffers(s))
return(-1);
-/* XXX: check what the second ' type' is about */
- if ((type (type != SSL3_RT_APPLICATION_DATA)
- (type != SSL3_RT_HANDSHAKE) type) ||
- (peek (type != SSL3_RT_APPLICATION_DATA)))
- {
+ if ((type type != SSL3_RT_APPLICATION_DATA type != SSL3_RT_HANDSHAKE) ||
+ (peek (type != SSL3_RT_APPLICATION_DATA))) {
+ {
SSLerr(SSL_F_DTLS1_READ_BYTES, ERR_R_INTERNAL_ERROR);
return -1;
}
diff --git a/ssl/ssl_task.c b/ssl/ssl_task.c
index b5ce44b..e8c04da 100644
--- a/ssl/ssl_task.c
+++ b/ssl/ssl_task.c
@@ -306,14 +306,14 @@ int doit(io_channel chan, SSL_CTX *s_ctx )
}
if ( length RPC_HDR_SIZE ) {
printf(Error in main loop get size: %d\n, length );
- break;
link_state = 3;
+ break;
}
if ( msg.channel != 'A' ) {
printf(Error in main loop, unexpected channel: %c\n,
msg.channel );
- break;
link_state = 3;
+ break;
}
if ( msg.function == 'G' ) {
link_state = 1;
Re: [openssl.org #3305] Cppcheck report
Resending this with the correct To: field, so that it would append this to
the RT ticket.
Regards,
Huzaifa Sidhpurwala
On Wed, Jun 18, 2014 at 3:18 PM, Huzaifa Sidhpurwala
sidhpurwala.huza...@gmail.com wrote:
The enclosed patch addresses all the issues discussed above.
On Wed, Jun 18, 2014 at 2:38 PM, Kurt Cancemi via RT r...@openssl.org
wrote:
Hello,
The attached patch removes a duplicate or check (the first problem listed
in this ticket).
Regards,
Kurt Cancemi
diff --git a/crypto/store/str_lib.c b/crypto/store/str_lib.c
index f1dbcbd..4de1d34 100644
--- a/crypto/store/str_lib.c
+++ b/crypto/store/str_lib.c
@@ -667,7 +667,7 @@ EVP_PKEY *STORE_get_public_key(STORE *s, OPENSSL_ITEM attributes[],
object = s-meth-get_object(s, STORE_OBJECT_TYPE_PUBLIC_KEY,
attributes, parameters);
- if (!object || !object-data.key || !object-data.key)
+ if (!object || !object-data.key)
{
STOREerr(STORE_F_STORE_GET_PUBLIC_KEY,
STORE_R_FAILED_GETTING_KEY);
diff --git a/fips/aes/fips_aesavs.c b/fips/aes/fips_aesavs.c
index fecaf99..ca303e8 100644
--- a/fips/aes/fips_aesavs.c
+++ b/fips/aes/fips_aesavs.c
@@ -918,6 +918,7 @@ int main(int argc, char **argv)
if (proc_file(rfn, rspfile))
{
printf( Processing failed for: %s \n, rfn);
+ fclose(fp);
return 1;
}
}
diff --git a/ssl/d1_pkt.c b/ssl/d1_pkt.c
index 611fc8d..da41dea 100644
--- a/ssl/d1_pkt.c
+++ b/ssl/d1_pkt.c
@@ -758,11 +758,9 @@ int dtls1_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
if (!ssl3_setup_buffers(s))
return(-1);
-/* XXX: check what the second ' type' is about */
- if ((type (type != SSL3_RT_APPLICATION_DATA)
- (type != SSL3_RT_HANDSHAKE) type) ||
- (peek (type != SSL3_RT_APPLICATION_DATA)))
- {
+ if ((type type != SSL3_RT_APPLICATION_DATA type != SSL3_RT_HANDSHAKE) ||
+ (peek (type != SSL3_RT_APPLICATION_DATA))) {
+ {
SSLerr(SSL_F_DTLS1_READ_BYTES, ERR_R_INTERNAL_ERROR);
return -1;
}
diff --git a/ssl/ssl_task.c b/ssl/ssl_task.c
index b5ce44b..e8c04da 100644
--- a/ssl/ssl_task.c
+++ b/ssl/ssl_task.c
@@ -306,14 +306,14 @@ int doit(io_channel chan, SSL_CTX *s_ctx )
}
if ( length RPC_HDR_SIZE ) {
printf(Error in main loop get size: %d\n, length );
- break;
link_state = 3;
+ break;
}
if ( msg.channel != 'A' ) {
printf(Error in main loop, unexpected channel: %c\n,
msg.channel );
- break;
link_state = 3;
+ break;
}
if ( msg.function == 'G' ) {
link_state = 1;
Openssl ECDSA vulnerable to Flush-Reload cache attacks?
Hi All, Wondering openssl was contacted when the following paper was released: http://eprint.iacr.org/2014/140.pdf This seems similar to http://eprint.iacr.org/2013/448.pdf which affected GPG software, was assigned a CVE id and was fixed up GPG upstream. Regards, Huzaifa
Security of RC4 in TLS
Hi, There are some recent research articles about attack against RC4 in TLS. Some of these attacks were well known earlier, like biases in the first 256 numbers generated from the RC4 PRG, the newer research combines this with statistical procedure to extract plaintext from ciphertext. I searched the openssl-dev achieves, but it seems that there is not public discussion going around this yet. Any idea if openssl is contemplating making changes to the RC4 protocol to make it safer. Of-course a long/medium term solution could be to switch to AEAD ciphersuites (AES-GCM for example). However in the short term there could be other solutions like - Adding random numbers of bytes to initial requests. - Fragmenting initial request into 1 byte fields so that the first 254 numbers are consumed. Reference: http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html http://www.isg.rhul.ac.uk/tls/ Regards, Huzaifa Sidhpurwala __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
