[uclibc-ng-devel] uClibc-ng and uClibc memset bug, ARM

Lucian Cojocar lucian.cojocar at vu.nl
Thu May 26 01:06:40 CEST 2016

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]:

	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
	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.


[2]disas.S (attached)
[3]qemu.log (attached)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: qemu.log
Type: text/x-log
Size: 3269 bytes
Desc: qemu.log
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20160526/58343a78/attachment.bin>
-------------- next part --------------
0003df70 <memset>:
   3df70:	  e1a03000 	  mov	r3, r0
   3df74:	  e3520008 	  cmp	r2, #8
   3df78:	  ba000016 	  blt	3dfd8 <memset+0x68>
   3df7c:	  e1811401 	  orr	r1, r1, r1, lsl #8
   3df80:	  e1811801 	  orr	r1, r1, r1, lsl #16
   3df84:	  e3130003 	  tst	r3, #3
   3df88:	  14c31001 	  strbne	 r1, [r3], #1
   3df8c:	  12422001 	  subne	  r2, r2, #1
   3df90:	  1afffffb 	  bne	3df84 <memset+0x14>
   3df94:	  e1a0c001 	  mov	ip, r1
   3df98:	  e3520008 	  cmp	r2, #8
   3df9c:	  ba00000d 	  blt	3dfd8 <memset+0x68>
   3dfa0:	  e8a31002 	  stmia	  r3!, {r1, ip}
   3dfa4:	  e2422008 	  sub	r2, r2, #8
   3dfa8:	  e3520008 	  cmp	r2, #8
   3dfac:	  ba000009 	  blt	3dfd8 <memset+0x68>
   3dfb0:	  e8a31002 	  stmia	  r3!, {r1, ip}
   3dfb4:	  e2422008 	  sub	r2, r2, #8
   3dfb8:	  e3520008 	  cmp	r2, #8
   3dfbc:	  ba000005 	  blt	3dfd8 <memset+0x68>
   3dfc0:	  e8a31002 	  stmia	  r3!, {r1, ip}
   3dfc4:	  e2422008 	  sub	r2, r2, #8
   3dfc8:	  e3520008 	  cmp	r2, #8
   3dfcc:	  a8a31002 	  stmiage	r3!, {r1, ip}
   3dfd0:	  a2422008 	  subge	  r2, r2, #8
   3dfd4:	  aaffffef 	  bge	3df98 <memset+0x28>
   3dfd8:	  e1b02002 	  movs	   r2, r2
   3dfdc:	  01a0f00e 	  moveq	  pc, lr
   3dfe0:	  e2622007 	  rsb	r2, r2, #7
   3dfe4:	  e08ff102 	  add	pc, pc, r2, lsl #2
   3dfe8:	  e1a00000 	  nop		   	   ; (mov r0, r0)
   3dfec:	  e4c31001 	  strb	   r1, [r3], #1
   3dff0:	  e4c31001 	  strb	   r1, [r3], #1
   3dff4:	  e4c31001 	  strb	   r1, [r3], #1
   3dff8:	  e4c31001 	  strb	   r1, [r3], #1
   3dffc:	  e4c31001 	  strb	   r1, [r3], #1
   3e000:	  e4c31001 	  strb	   r1, [r3], #1
   3e004:	  e4c31001 	  strb	   r1, [r3], #1
   3e008:	  e1a0f00e 	  mov	pc, lr
   3e00c:	  e320f000 	  nop	{0}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20160526/58343a78/attachment.sig>

More information about the devel mailing list