Bug 159241 – Possible Info Leak in TypedArray.indexOf/lastIndexOf

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Natalie Silvanovich]

Created attachment 282308 [details]
Crashing sample

There is a possible info leak in TypedArray.indexOf. In JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h, the function genericTypedArrayViewProtoFuncIndexOf has the following code:

    JSValue valueToFind = exec->argument(0);
    unsigned index = argumentClampedIndexFromStartOrEnd(exec, 1, length);

    typename ViewClass::ElementType* array = thisObject->typedVector();
    typename ViewClass::ElementType target = ViewClass::toAdaptorNativeFromValue(exec, valueToFind);
    if (exec->hadException())
        return JSValue::encode(jsUndefined());

    for (; index < length; ++index) {
        if (array[index] == target)
            return JSValue::encode(jsNumber(index));
    }

There are two places that an attacker can call into script and neuter the array and cause problems. The first is at the argumentClampedIndexFromStartOrEnd, in which case array will be 0, and an absolute pointer specified by index can be compared against value. It's also possible to use this issue as a read-only use-after-free by setting the first parameter to an object with valueOf defined. Since this value is converted after the array pointer is set, the array will be searched after it is freed.

I'm not sure if searching an array bytewise for every value between 0 and 255 is a practical attack, so there is no deadline on this issue unless we figure out how to exploit it.

[Radar WebKit Bug Importer]

<rdar://problem/27324561>

[Mark Lam]

(In reply to comment #0)
> The first is at the argumentClampedIndexFromStartOrEnd, in which case array will be 0, and an
> absolute pointer specified by index can be compared against value. 

This no longer an issue because r202982: <http://trac.webkit.org/changeset/202982> added a neuter check immediately after the call to argumentClampedIndexFromStartOrEnd().

[Mark Lam]

Brent, it's not fixed yet.  There's a second issue ...

(In reply to comment #0)
> It's also possible to use this issue as a read-only use-after-free by setting the
> first parameter to an object with valueOf defined. Since this value is
> converted after the array pointer is set, the array will be searched after
> it is freed.

Here, I think Natalie is referring to this line in the code:
    typename ViewClass::ElementType target = ViewClass::toAdaptorNativeFromValue(exec, valueToFind);

Keith already has this baking in a fix he's implementing.

So, I'll send this bug over to Keith.

[Keith Miller]

*** This bug has been marked as a duplicate of bug 159400 ***