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
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-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
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-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
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
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
[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.org #3416] PATCH: EVP_EncryptionInit and AES-NI note
Hi All, Since we are talking about AES implementation in OpenSSL, Andy and myself wrote a blog about it (well its actually about this paper claiming that AES is vulnerable to timing attacks but nicely describes how AES is implemented in OpenSSL) https://securityblog.redhat.com/2014/07/02/its-all-a-question-of-time-aes-timing-attacks-on-openssl/ On Thu, Jul 3, 2014 at 5:23 AM, noloa...@gmail.com via RT wrote: > > Since this may in future cover much more than just AES-NI... > Good observation Doctor, done. Attached is the updated text. > > diff --git a/doc/crypto/EVP_EncryptInit.pod > b/doc/crypto/EVP_EncryptInit.pod > index f6e4396..8d7636c 100644 > --- a/doc/crypto/EVP_EncryptInit.pod > +++ b/doc/crypto/EVP_EncryptInit.pod > @@ -433,7 +433,10 @@ for AES. > > Where possible the B interface to symmetric ciphers should be used in > preference to the low level interfaces. This is because the code then > becomes > -transparent to the cipher used and much more flexible. > +transparent to the cipher used and much more flexible. Additionally, the > +B interface will ensure the use of platform specific cryptographic > +acceleration such as AES-NI (the low level interfaces do not provide the > +guarantee). > > PKCS padding works by adding B padding bytes of value B to make the > total > length of the encrypted data a multiple of the block size. Padding is > always > > * > > On Wed, Jul 2, 2014 at 12:08 PM, Stephen Henson via RT > wrote: > > On Wed Jul 02 07:12:19 2014, noloa...@gmail.com wrote: > >> Questions on AES-NI and how to enable them have come up twice recently > >> on the stack exchanges (like stack overflow). > >> > >> This patch documents use of the AES-NI instruction by way of the EVP_* > >> interface. > >> > > > > Since this may in future cover much more than just AES-NI I'd suggest we > say > > something like "platform specific cryptographic acceleration such as > AES-NI". > >
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 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
Ah c2fd5d79ffc4fc9d120a0faad579ce96473e6a2f already addresses this! On Mon, Jun 30, 2014 at 9:48 PM, Huzaifa Sidhpurwala < sidhpurwala.huza...@gmail.com> wrote: > On Mon, Jun 30, 2014 at 5:01 PM, Dr. Stephen Henson > 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=guest&pass=guest&id=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: EVP_CIPHER_CTX_copy() segv with XTS
On Mon, Jun 30, 2014 at 5:01 PM, Dr. Stephen Henson 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=guest&pass=guest&id=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: EVP_CIPHER_CTX_copy() segv with XTS
Hi Peter, Are you facing any issues similar to http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=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 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: OpenSSL-1.0.0m on Fedora Core 16
On Fri, Jun 20, 2014 at 4:23 AM, Bernal, Daniel L 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 #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
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
> 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
[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
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
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 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 > > 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
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 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 > > 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
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
> 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
> 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
The enclosed patch addresses all the issues discussed above.
On Wed, Jun 18, 2014 at 2:38 PM, Kurt Cancemi via RT 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
Re: [openssl-dev] Security of RC4 in TLS
Bonjour! On Fri, Mar 15, 2013 at 3:39 PM, Erwann Abalea wrote: > Bonjour, > In my understanding, after a fast read of RFC5246, this won't work. > > If RC4 is finally considered weak (at last), just don't use it anymore. Do > you use DES on your server? I guess no. Thanks for a quick reply. Perhaps i was not clear. I am not worried about _my_ server. I just noticed some work being done in other SSL/TLS open source library about this issue, and hence the question. There is also some discussion at: https://news.ycombinator.com/item?id=5364807 I guess the OpenSSL solution is to not use RC4 then? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
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
