Hi,
Sorry I hadn't noticed your response.
I have created a fairly simple demonstration. In doing so I realise you
may need to manipulate two integers to create the problem.. But this
triggers the issue.
// To cause the overrun we need to manipulate two integers that then cross
a 64 bit boundary.
// In addition they need to be positioned such that they cross a boundary
in the lookup table within
// RoundupSizeTable table in integer.cpp..
//------------------------------
// static const unsigned int RoundupSizeTable[] = {2, 2, 2, 4, 4, 8, 8, 8,
8};
//
//static inline size_t RoundupSize(size_t n)
//{
// if (n<=8)
// return RoundupSizeTable[n];
// else if (n<=16)
// return 16;
// else if (n<=32)
// return 32;
// else if (n<=64)
// return 64;
// else
// return size_t(1) << BitPrecision(n-1);
//}
//-------------------------------
// With the following number we will downsize from 5 lots of 64 bits to 4,
making the lookup
// in roundup table cross from 8 to 4.
std::uint8_t bitstream[] =
{ 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
CryptoPP::Integer bigint1(bitstream, sizeof(bitstream));
CryptoPP::Integer bigint2(bitstream, sizeof(bitstream));
// Bit shift to top bits are zeroised, this means that the CountWords
algorithm will later ignore leading zero bytes.
// I figure you could probably also use substract here, anything that does
not reallocate the reg buffer.
bigint1 >>= 1;
bigint2 >>= 1;
// Now perform one of the vulnerable manipulations.
// It is within this operator that a new integer is allocated with the
reduced buffer size, but
// the full length of one of the original integers is copied into the
buffer.
auto result = bigint2 & bigint1;
Hope this helps, let me know if I can help any further.
Cheers,
Tony.
On Friday, 8 October 2021 at 05:32:17 UTC+1 Jeffrey Walton wrote:
> On Fri, Oct 8, 2021 at 12:02 AM Jeffrey Walton <nolo...@gmail.com> wrote:
> >
> > On Thu, Oct 7, 2021 at 5:11 AM Tony Stead <ths...@gmail.com> wrote:
> > >
> > > I have been using the Integer class for some big number operations and
> seem to have found a buffer overflow in at least the Integer::And routine,
> I have not yet inspected any more..
> > >
> > > ...
> > > The issue is casued in the temporary result variable. When result
> copies t or this in its constructor, it calculates the minimum size
> required to fit the current number in t or this. If the top order bits of t
> or this have gone zero it will allocate less bytes than the size of t or
> this. However the following AndWords routine performs a copy using the size
> of the original number, either t or this.
> > >
> > > Changing the value to result.reg.size() appears to fix the issue at
> least for my use case.
> >
> > Thanks Tony.
> >
> > Do you have a reproducer? I'd like to look at it.
> >
> > We have test cases setup and they are run under the sanitizers. I
> > don't recall seeing a finding. We might be missing a test case for it,
> > however.
>
> By the way, here's the test data we use for testing the integer
> operations. It was generated using Java, so you should get the same
> result between Crypto++ and Java. You can find the Java program at
> http://github.com/weidai11/cryptopp/issues/336.
>
> https://github.com/weidai11/cryptopp/blob/master/validat2.cpp#L34
>
> Jeff
>
--
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/cryptopp-users/dfb81497-a629-400d-90d9-8479c838f04an%40googlegroups.com.
