Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[David Benjamin via RT]

On Sun, Jul 31, 2016 at 6:18 PM Michel via RT  wrote:

> > I was able to trigger a crash simply by chaining an encrypt BIO with a
> memory BIO containing a large plaintext and then stream 100 bytes out of it
> at a time. BIO_read would consistently return 128 and, by the time the
> function returned, the stack was thoroughly clobbered.
>
> I am surprised. I should have been [un-?]lucky for once.
> FWIW, here is what I did :
> I have some files containing about 1 of variable length lines (range is
> from about 60 to 260 bytes).
> File size is about 900 Kb to 1.5 Mb.
> Files can be cleartext or encrypted (in this case they can be optionaly
> base64 encoded).
> So I have a software that chain as follow :
> File bio ->
> Base64 bio (opt) ->
> Cipher bio (opt) ->
> Memory bio.
>
> For my test I read and wrote each case using 2 different ciphers : aes-128
> and camelia-192.
> Everything looks good : no crash, no data lost or damaged, no memory leak
> and no stack overwritten.
>
> I certainly misunderstand something, but I will be happy to test again my
> use case if it can be of any help.
>

(I'm not entirely sure which direction the arrows are meant to be going.)

You need the read to not be a multiple of 16 to trigger the issue. (Well,
that's the simplest trigger. I also got decrypt BIOs to trigger with
outl=128 because EVP_DecryptUpdate always holds back the final block.) Also
if your code will secretly tolerate the cipher BIO returning more data than
outl, you won't notice. But the API contract of BIO_read is that it will
not return more than outl bytes of data.

Reads of size 100 into a buffer of size 100 will do the trick:

outl = 100 =>
buf_len = 128 =>
i = 128 (assuming we got a full read) =>
we ask EVP_CipherUpdate to decrypt 128 bytes =>
128 bytes of output into out =>
buffer overflow

David

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Michel via RT]

> I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.

I am surprised. I should have been [un-?]lucky for once.
FWIW, here is what I did :
I have some files containing about 1 of variable length lines (range is
from about 60 to 260 bytes).
File size is about 900 Kb to 1.5 Mb.
Files can be cleartext or encrypted (in this case they can be optionaly
base64 encoded).
So I have a software that chain as follow : 
File bio -> 
Base64 bio (opt) ->
Cipher bio (opt) ->
Memory bio.

For my test I read and wrote each case using 2 different ciphers : aes-128
and camelia-192.
Everything looks good : no crash, no data lost or damaged, no memory leak
and no stack overwritten.

I certainly misunderstand something, but I will be happy to test again my
use case if it can be of any help.

Regards,

Michel.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Michel]

> I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.

I am surprised. I should have been [un-?]lucky for once.
FWIW, here is what I did :
I have some files containing about 1 of variable length lines (range is
from about 60 to 260 bytes).
File size is about 900 Kb to 1.5 Mb.
Files can be cleartext or encrypted (in this case they can be optionaly
base64 encoded).
So I have a software that chain as follow : 
File bio -> 
Base64 bio (opt) ->
Cipher bio (opt) ->
Memory bio.

For my test I read and wrote each case using 2 different ciphers : aes-128
and camelia-192.
Everything looks good : no crash, no data lost or damaged, no memory leak
and no stack overwritten.

I certainly misunderstand something, but I will be happy to test again my
use case if it can be of any help.

Regards,

Michel.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL 1.1.0 release dates

[Matt Caswell]

FYI, we have recently updated our release strategy for version 1.1.0:
https://www.openssl.org/policies/releasestrat.html

The change is to add the following two dates:

- 4th August 2016, 1.1.0 beta 3 release
- 25th August 2016, 1.1.0 public release

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4530] [BUG] OpenSSL crash on Windows 10

[Andy Polyakov via RT]

Hi,

> Hi, our team have been experiencing a crash in some production
> machines (which I cannot reproduce in development machines) caused by
> the libeay32 module in 64 bits Windows 10 machines.
> 
> I was able to create a simple "crash application" and was able to get
> the dump of the crash along with PDB files for both the libeay32.dll
> and the sample application.
> 
> The exception code being thrown is 0xC005 (invalid memory access)
> and occurs inside sha1_block_data_order_shaext(), sha1-x86_64.asm,
> line 1435. The version used was 1.0.2g (but older versions also crash
> - the latest dev version from github crash as well).

Oh! Your machines don't seem like something everybody has :-) I mean
SHAEXT-capable CPUs are rare... Anyway, please verify attached patch.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4530
Please log in as guest with password guest if prompted

diff --git a/crypto/sha/asm/sha1-x86_64.pl b/crypto/sha/asm/sha1-x86_64.pl
index e8f61ab..97baae3 100755
--- a/crypto/sha/asm/sha1-x86_64.pl
+++ b/crypto/sha/asm/sha1-x86_64.pl
@@ -380,9 +380,9 @@ $code.=<<___;
 .align 16
 .Loop_shaext:
dec $num
-   lea 0x40($inp),%rax # next input block
+   lea 0x40($inp),%r8  # next input block
paddd   @MSG[0],$E
-   cmovne  %rax,$inp
+   cmovne  %r8,$inp
movdqa  $ABCD,$ABCD_SAVE# offload $ABCD
 ___
 for($i=0;$i<20-4;$i+=2) {
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[David Benjamin via RT]

Hey folks,

I do not believe this fix works and introduces buffer overflows.

Looking at this change:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=abdb460d8abe68fedcf00b52d2ba4bf4b7c1725c

It makes EVP_CipherUpdate write to out directly. While not unreasonable
(this BIO probably should never buffer more than a block and otherwise use
the buffer passed in), one must take care to never output more than outl
bytes. There are a number of problems here:

1. The logic to compute buf_len above rounds outl *up* to a multiple of
EVP_MAX_BLOCK_LENGTH. Thus, if outl > buf_len and BIO_read returns the full
buf_len bytes, EVP_CipherUpdate, may write up to buf_len bytes and exceed
outl.

2. If the EVP_CIPHER_CTX contains a partial block buffered, even if outl ==
buf_len, we may *still* output more than outl bytes. For instance, the BIO
may be connected to a pipe and BIO_read return less than buf_len. That will
feed a partial block into the EVP_CIPHER_CTX and, the next time around, we
output more data than expected.

3. Actually, #2 even means the EVP_CIPHER overlapping buffers check is
wrong. The true requirement is not "if the buffers alias, then in == out",
but "if the buffers alias, then out + ctx->num == in". EVP_CIPHER's block
cipher handling is a very leaky abstraction.

I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.

#3 suggests a very minimal fix. Revert the direct output codepath (not
wrong, but I think the BIO needs a complete rewrite with a block-size
buffer for that sort of thing anyway). Then, instead of reading BUF_OFFSET
bytes in at the BIO_read call, read ctx->num bytes in. Then go and fix the
EVP_CIPHER overlap check so it handles the ctx->num != 0 case correctly.

NB: I'm unclear on what the BUF_OFFSET offset was originally for. The
comment just says to read the EVP_Cipher documentation, but there is no pod
file for EVP_Cipher. I am assuming it was to get around this partial block
problem, but perhaps I'm missing something and my suggestion is also wrong.

Hope this helps,

David

PS: Should the new codepath have been setting ctx->cont? The others do.
Though it looks like it might be a no-op when set to 1? I'm not sure.

PPS: This sort of streaming stuff is quite hairy. Like the poly1305
streaming bits, it would make sense to write some tests here. Get a long
plaintext/ciphertext vector or two (I'd test both a block cipher and a
stream cipher) and make sure everything behaves correctly against various
interesting read patterns. Both when the outl pattern varies and when the
inner BIO_read return pattern varies.

On Sun, Jul 31, 2016 at 1:53 PM Rich Salz via RT  wrote:

> Resolved by Andy's fix. Closing.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Rich Salz via RT]

Resolved by Andy's fix. Closing.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Michel]

Not speaking for Greg, but for me, it is now working fine again.
Thanks Andy !

-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Rich
Salz via RT
Envoyé : dimanche 31 juillet 2016 15:58
À : ghud...@mit.edu
Cc : openssl-dev@openssl.org
Objet : [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to
overlapping regions check

Does current master work? I think Andy checked in a fix.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Michel via RT]

Not speaking for Greg, but for me, it is now working fine again.
Thanks Andy !

-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Rich
Salz via RT
Envoyé : dimanche 31 juillet 2016 15:58
À : ghud...@mit.edu
Cc : openssl-dev@openssl.org
Objet : [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to
overlapping regions check

Does current master work? I think Andy checked in a fix.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Building current master fails when option no-nextprotoneg is used

[Salz, Rich]

> Just to let you know that today's master fails to build when option 
> no-nextprotoneg is used.

This will be fixed shortly; the fix is being reviewed.  Thanks.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Andy Polyakov via RT]

> Does current master work? I think Andy checked in a fix.

Rich was few minutes ahead. Now it's committed. Provided test case was
verified to work. Thanks for report.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Rich Salz via RT]

Does current master work? I think Andy checked in a fix.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4046] Fix xmm6 register clobbering in crypto/bn/asm/x86_64-mont5.pl:bn_power5() under Win64

[Andy Polyakov via RT]

Hi,

> i had some problems on Win64 using BIO_do_handshake/BIO_should_retry in a 
> loop. The compiler optimizer placed a local variable value in the xmm6 
> register.
> The content of this register was destroyed after calling BIO_do_handshake. I 
> debugged this and found that the xmm6/xmm7 registers were not restored.
> I fixed this with following diff for openssl-1.0.2d / x86_64-mont5.pl 
> (bn_power5 and bn_from_mont8x):
> 
> 1013a1014,1020
>> ___
>> $code.=<<___ if ($win64);
>> movaps   -88(%rsi),%xmm6
>> movaps   -72(%rsi),%xmm7
>> ___
>> $code.=<<___;
>>
> 2005a2013,2019
>> ___
>> $code.=<<___ if ($win64);
>> movaps   -88(%rsi),%xmm6
>> movaps   -72(%rsi),%xmm7
>> ___
>> $code.=<<___;
>>
> 
> The fix in bn_from_mont8x was not necessary for me but i think the lines are 
> also missing there.

This resolved itself it the course of fixing other problems. Thanks for
report!



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4046
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4569] Enhancement request: Macros for x86 capability bits

[Andy Polyakov via RT]

> For x86, define macros for capability bits (like for arm and pcc), according 
> to https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html:

As discussed in RT#4568 and RT#4570, these are internal interfaces and
there is no intention to expose it to user, except through setting
environment variable. Even that is recommended for specific test and
debugging scenarios rather than for production use. And since macros are
of no help when setting environment variable, suggestion is declined.




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4569
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev