[Spam] Re: uClibc-ng and uClibc memset bug, ARM

[Lucian Cojocar]

On 05/26/2016 01:45 AM, Rich Felker wrote:
> On Thu, May 26, 2016 at 01:06:40AM +0200, Lucian Cojocar wrote:
>> Hi all,
>>
>> in libc/string/arm/memset.S[0]. If the code is compiled with #undef
>> __thumb2__ and with #undef THUMB1_ONLY (this seems to be case for
>> Tomato[1] at least and for buildroot) then the code looks like this[2]:
>>
>> """
>> memset:
>> 	mov	a4, a1
>> 	cmp	a3, $8		@ at least 8 bytes to do?
>> 	blt	2f
>> 	orr	a2, a2, a2, lsl $8
>> 	orr	a2, a2, a2, lsl $16
>> ...
>> 2:
>> 	movs	a3, a3		@ anything left?
>> 	IT(t, eq)
>> 	BXC(eq, lr)		@ nope
>>
>>
>> 	rsb	a3, a3, $7
>> 	add	pc, pc, a3, lsl $2    <--- a3 can be larger than $7 here
>> 	mov	r0, r0
>> 	strb	a2, [a4], $1
>> 	strb	a2, [a4], $1
>> ...
>> """"
>>
>> The problem is that the 'BLT' instruction checks for *signed* values. So
>> if a3, length parameter of memset, is negative, then value added to the
>> PC will be large.
>>
>> In short, an attacker gains control of PC through the len parameter of
>> memset. The attack is a bit unrealistic, as it requires that the
>> application that uses uClibc allows a user to control a memory chunk
>> larger than 2GB.
>>
>> I only tested this on qemu-system-arm[3]. The code was just calling
>> memset(buf, 0xaa, 0xffff0000), memset, in this example[3] is @0x1003c.
>>
>> This bug is similar to CVE-2011-2702[4, 5]. Probably we should notify
>> oss-security and get a CVE for this as the impact is unknown.
> 
> This is only one of a HUGE number of things that go hopelessly wrong
> if an implementation allows single objects with sizes larger than
> PTRDIFF_MAX. A lot has been written on this topic recently. Regardless
> of how this one report is resolved, uClibc should ensure that no such
> objects can arise (by checking sizes in malloc, mmap, etc.).
> 
Is this defined by some standard (i.e. objects should be no larger than
than PTRDIFF_MAX)?

Lucian