1300445 - Segfault in SpiderMonkey Shell (js/src/editline/editline.c)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[jon.metzman]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/51.0.2704.79 Chrome/51.0.2704.79 Safari/537.36

Steps to reproduce:

1. Build the latest SpiderMonkey shell
2. Pass an input containing the hex value 0x12 as the last character in the input.
Using the attached file crashing-input.js:
./js/src/js < /tmp/crashing-input.js 


Actual results:

Running the command output this:

     h: js> 
js> Segmentation fault



Expected results:

Something other than a segmentation fault

Comment 1

[jon.metzman]

Attachment: Crashing input

Comment 2

[jon.metzman]

Valgrind seems to think this a null dereference but I disagree.
Running this command in valgrind:

$ valgrind ./js/src/js < /tmp/crashing-input.js

Outputs the following:

==4771== Memcheck, a memory error detector
==4771== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4771== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==4771== Command: ./js/src/js
==4771== 
js> q
      Search: js> 
     
js> 
js> ==4771== Invalid write of size 4
==4771==    at 0x473440: jemalloc_crash (jemalloc.c:1631)
==4771==    by 0x476969: arena_dalloc (jemalloc.c:4737)
==4771==    by 0x476969: free (jemalloc.c:6485)
==4771==    by 0x47F0AC: editinput (editline.c:940)
==4771==    by 0x47F8CB: readline (editline.c:999)
==4771==    by 0x42869D: GetLine (js.cpp:457)
==4771==    by 0x42869D: ReadEvalPrintLoop(JSContext*, _IO_FILE*, bool) (js.cpp:963)
==4771==    by 0x428F4B: Process(JSContext*, char const*, bool, FileKind) (js.cpp:1048)
==4771==    by 0x434AE0: ProcessArgs (js.cpp:6881)
==4771==    by 0x434AE0: Shell (js.cpp:7282)
==4771==    by 0x434AE0: main (js.cpp:7657)
==4771==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==4771== 
==4771== 
==4771== Process terminating with default action of signal 11 (SIGSEGV)
==4771==  Access not within mapped region at address 0x0
==4771==    at 0x473440: jemalloc_crash (jemalloc.c:1631)
==4771==    by 0x476969: arena_dalloc (jemalloc.c:4737)
==4771==    by 0x476969: free (jemalloc.c:6485)
==4771==    by 0x47F0AC: editinput (editline.c:940)
==4771==    by 0x47F8CB: readline (editline.c:999)
==4771==    by 0x42869D: GetLine (js.cpp:457)
==4771==    by 0x42869D: ReadEvalPrintLoop(JSContext*, _IO_FILE*, bool) (js.cpp:963)
==4771==    by 0x428F4B: Process(JSContext*, char const*, bool, FileKind) (js.cpp:1048)
==4771==    by 0x434AE0: ProcessArgs (js.cpp:6881)
==4771==    by 0x434AE0: Shell (js.cpp:7282)
==4771==    by 0x434AE0: main (js.cpp:7657)
==4771==  If you believe this happened as a result of a stack
==4771==  overflow in your program's main thread (unlikely but
==4771==  possible), you can try to increase the size of the
==4771==  main thread stack using the --main-stacksize= flag.
==4771==  The main thread stack size used in this run was 8388608.


However using gdb, we can see that this looks like a double free.

If we break on editline.c:940, run the program using the command r < /tmp/crashing-input.js, and print the variable "Line", we see that the same address is freed twice.
It looks like this happens because h_search() gets called when 0x12 (reverse search) is input.

It is also worth noting that I've been able to reproduce the crash when there are characters preceeding 0x12 but not when there are characters following it, in the input.

Comment 3

[jon.metzman]

Please ignore the part about "User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/51.0.2704.79 Chrome/51.0.2704.79 Safari/537.36" in the first comment.

That was inserted by the default bug report form, I didn't realize I should have used the advanced form.

Comment 4

[jon.metzman]

The SpiderMonkey shell was built without passing any options to autoconf, configure or make

Comment 5

[:Gijs (he/him)]

Not sure who does triage for JS. CC'ing the world to avoid the "core" sec group making this inaccessible. Jan or Waldo, can you ensure someone looks at this? Thanks!

Comment 6

[Nicolas B. Pierron [:nbp]]

As far as I know this is only used by the JavaScript shell, which is not supposed to be part of any released, except mozjs.

Looking at editline.c, I fear that this file never got any major update since May 9th 1999.

Maybe it would be time to take a look at upstream version of the project [1], at least to get rid of the C k&r style.

[1] https://github.com/troglobit/editline

Comment 7

[Jan de Mooij [:jandem]]

Thanks for the report.

The JS shell is just for internal use. It has lots of footguns and likely has other holes - it shouldn't be used for anything security-sensitive. Patches welcome but I don't think this is a priority for us atm :)