Re: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

2016-08-18 Thread Brian Morton via RT 
Very helpful, thanks!  So that's not an actual issue.

Which do you think is more pressing from your project's perspective:
removing BUF_MEM dependency on int, or streaming decode for smime?  While
certainly non-trivial, the latter is certainly more isolated for a
newcomer.  On the other hand, the former may be more pressing overall.  I
don't know what kind of challenges it presents in other tools to have a 32
bit mem buffer size limit.

On Thu, Aug 18, 2016 at 12:15 PM, Stephen Henson via RT 
wrote:

> On Thu Aug 18 14:01:03 2016, bmor...@mortoninsights.com wrote:
> > Ok, so this might be a separate issue. Please let me know what you think
> > and I can file. The issue is pretty much irrelevant since you can't
> > decrypt anything over 1.5G.
> >
> > Try this:
> >
> > bmorton@athens:~$ dd if=/dev/urandom of=sample.txt bs=512K count=6144
> > 6144+0 records in
> > 6144+0 records out
> > 3221225472 bytes (3.2 GB) copied, 205.387 s, 15.7 MB/s
> > bmorton@athens:~$ openssl smime -encrypt -binary -text -aes256 -in
> > sample.txt -out sample.txt.enc -outform DER mysqldump-secure.pub.pem
> > bmorton@athens:~$ ls -lh | grep sample
> > -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt
> > -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:56 sample.txt.enc
> > bmorton@athens:~$ cat sample.txt | openssl smime -encrypt -binary -text
> > -aes256 -out sample.txt.enc -outform DER mysqldump-secure.pub.pem
> > bmorton@athens:~$ ls -lh | grep sample
> > -rw-rw-r-- 1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt
> > -rw-rw-r-- 1 bmorton bmorton 1.9G Aug 18 09:59 sample.txt.enc
> >
>
> Try it with the -stream option.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>
>


-- 
Brian Morton
Morton Software Insights
404-667-1095
bmor...@mortoninsights.com


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
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 #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

2016-08-18 Thread Brian Morton via RT 
Ok, so this might be a separate issue.  Please let me know what you think
and I can file.  The issue is pretty much irrelevant since you can't
decrypt anything over 1.5G.

Try this:

bmorton@athens:~$ dd if=/dev/urandom of=sample.txt bs=512K count=6144
6144+0 records in
6144+0 records out
3221225472 bytes (3.2 GB) copied, 205.387 s, 15.7 MB/s
bmorton@athens:~$ openssl smime -encrypt -binary -text -aes256 -in
sample.txt -out sample.txt.enc -outform DER mysqldump-secure.pub.pem
bmorton@athens:~$ ls -lh | grep sample
-rw-rw-r--  1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt
-rw-rw-r--  1 bmorton bmorton 1.9G Aug 18 09:56 sample.txt.enc
bmorton@athens:~$ cat sample.txt | openssl smime -encrypt -binary -text
-aes256 -out sample.txt.enc -outform DER mysqldump-secure.pub.pem
bmorton@athens:~$ ls -lh | grep sample
-rw-rw-r--  1 bmorton bmorton 3.0G Aug 18 09:48 sample.txt
-rw-rw-r--  1 bmorton bmorton 1.9G Aug 18 09:59 sample.txt.enc

On Thu, Aug 18, 2016 at 9:36 AM, Stephen Henson via RT 
wrote:

> On Thu Aug 18 00:40:21 2016, bmor...@mortoninsights.com wrote:
> >
> > Regardless of input size (2GB or 30GB) to the smime application, the
> > resulting encrypted file is only 1.9GB on disk. Unless smime format
> > has
> > some very serious compression, it looks like it is silently truncating
> > input. A 32 bit integer dependency in the read buffer might explain
> > that.
> > Is it related, or should I file that separately?
> >
>
> That's strange. It shouldn't do that. The encoding operations should work
> with
> (almost) arbitrary size input when streaming as there is no int dependency
> and
> no need to hold the complete structure in memory.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>
>


-- 
Brian Morton
Morton Software Insights
404-667-1095
bmor...@mortoninsights.com


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
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 #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

2016-08-17 Thread Brian Morton via RT 
Thank you Steve (and Rich) for your insights so far.  It looks like BUF_MEM
is the structure in question?  If so, that might also explain the odd
behavior with smime encrypting which makes this issue sort of moot.  Even
if I could fix this, the encrypted files I've created so far would be
truncated I think.

I guess the safety check is to ensure that the structure works correctly
with other functions that put the result into an int type internally?

https://github.com/openssl/openssl/blob/3ce2fdabe6e33952bf3011acf5b68107e6352603/crypto/buffer/buffer.c#L19

Regardless of input size (2GB or 30GB) to the smime application, the
resulting encrypted file is only 1.9GB on disk.  Unless smime format has
some very serious compression, it looks like it is silently truncating
input.  A 32 bit integer dependency in the read buffer might explain that.
Is it related, or should I file that separately?

Brian

On Wed, Aug 17, 2016 at 6:54 PM, Stephen Henson via RT 
wrote:

> On Wed Aug 17 18:16:41 2016, bmor...@mortoninsights.com wrote:
> > That doesn't sound like an ideal case for a bugfix. Any other creative
> > ideas on how to fix this one? Some suggestions I read previously included
> > adding support for streaming decode to avoid such a large memory
> > allocation. This may not easily be feasible because of needing to verify
> > signatures on the message.
> >
>
> A streaming decode is one option but this is far from a trivial
> undertaking,
> Verifying signatures would be handled on the fly but you'll only know the
> signature is valid after all content has been processed of course.
>
> > If not, I'll try out the size_t change.
> >
>
> This is a significant job too. There is a major knock on effect with
> several
> APIs so it's not just a case of changing a few structures or we'd have
> done it
> already. It is planned for a future release though.
>
> As RIch mentioned one of the key structures has a dependency on int which
> is
> often 32 bits even on 64 bit systems.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
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 #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

2016-08-17 Thread Brian Morton via RT 
That doesn't sound like an ideal case for a bugfix.  Any other creative
ideas on how to fix this one?  Some suggestions I read previously included
adding support for streaming decode to avoid such a large memory
allocation.  This may not easily be feasible because of needing to verify
signatures on the message.

If not, I'll try out the size_t change.

On Wed, Aug 17, 2016 at 2:02 PM, Salz, Rich via RT  wrote:

> Try it, it will be a huge invasive change.
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>
>


-- 
Brian Morton
Morton Software Insights
404-667-1095
bmor...@mortoninsights.com


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
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 #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

2016-08-17 Thread Salz, Rich via RT 
Try it, it will be a huge invasive change.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
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 #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

2016-08-17 Thread Salz, Rich 
Try it, it will be a huge invasive change.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

2016-08-17 Thread Brian Morton via RT 
Hi Rich,

This is a 64 bit kernel on AMD64 architecture.  Do I need ints bigger than
that?  Any reason not to patch the code with size_t?  I could craft such a
change for a ticket if desired.

Thanks,

Brian

On Wed, Aug 17, 2016 at 1:28 PM, Rich Salz via RT  wrote:

> You'll need to move to a machine with bigger int's. The code currently uses
> int, not size_t.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>
>


-- 
Brian Morton
Morton Software Insights
404-667-1095
bmor...@mortoninsights.com


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

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