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

NEW
Unassigned

Status

()

Core
JavaScript Engine
P3
normal
a year ago
28 days ago

People

(Reporter: jon.metzman, Unassigned)

Tracking

({triage-deferred})

Trunk
x86_64
Linux
triage-deferred
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
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
(Reporter)

Comment 1

a year ago
Created attachment 8788011 [details]
Crashing input
(Reporter)

Comment 2

a year ago
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.
(Reporter)

Comment 3

a year ago
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.
(Reporter)

Updated

a year ago
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
(Reporter)

Comment 4

a year ago
The SpiderMonkey shell was built without passing any options to autoconf, configure or make
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!
Group: firefox-core-security → core-security
Component: Untriaged → JavaScript Engine
Flags: needinfo?(jwalden+bmo)
Flags: needinfo?(jdemooij)
Product: Firefox → Core
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
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 :)
Flags: needinfo?(jdemooij)
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jwalden+bmo)
Duplicate of this bug: 1306444
Duplicate of this bug: 1383507
Keywords: triage-deferred
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.