uClibc-ng and uClibc memset bug, ARM
Lucian Cojocar
lucian.cojocar at vu.nl
Wed May 25 23:06:40 UTC 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]:
"""
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.
Thanks,
Lucian
[0]https://github.com/wbx-github/uclibc-ng/blob/master/libc/string/arm/memset.S#L70
[1]http://tomato.groov.pl/download/K26ARM/132/tomato-R7000-ARM--132-AIO-64K.zip
[2]disas.S (attached)
[3]qemu.log (attached)
[4]http://www.cvedetails.com/cve/CVE-2011-2702/
[5]http://old.sebug.net/paper/Exploits-Archives/2012-exploits/1208-exploits/eglibc-exec.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qemu.log
Type: text/x-log
Size: 3269 bytes
Desc: qemu.log
URL: <http://lists.busybox.net/pipermail/uclibc/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://lists.busybox.net/pipermail/uclibc/attachments/20160526/58343a78/attachment.asc>
More information about the uClibc
mailing list