Bug 180688 – Fix possible out-of-bounds read in protocolIsInHTTPFamily

• Component: New Bugs
• Status: RESOLVED FIXED

[Alex Christensen]

Fix possible out-of-bounds read in protocolIsInHTTPFamily

[Alex Christensen]

Created attachment 329067 [details]
Patch

[Alex Christensen]

Created attachment 329070 [details]
Patch

[Daniel Bates]

Comment on attachment 329070 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=329070&action=review

> Source/WebCore/platform/URL.cpp:877
> +    return url.length() > 4

We could cache url.length() in a local to avoid dereferencing it twice. Maybe the compiler is smart enough?

For your consideration I suggest using >= 5 as it tends to be easier to reason about when verifying bounds. The compiler should be smart enough to optimize this to > 4 if such a micro-optimization is considered a win on a particular ISA.

> Source/WebCore/platform/URL.cpp:882
> +        && (url[4] == ':' || (isASCIIAlphaCaselessEqual(url[4], 's') && url.length() > 5 && url[5] == ':'));

For similar reasons I suggest changing > 5 to >= 6.

> Tools/TestWebKitAPI/Tests/WebCore/URL.cpp:218
> +    EXPECT_FALSE(protocolIsInHTTPFamily("abc"));

I suggest that we also check the empty string, a null string, and a string with a single character.

[Alex Christensen]

http://trac.webkit.org/r225829

[Radar WebKit Bug Importer]

<rdar://problem/36010694>

[Darin Adler]

Comment on attachment 329070 [details]
Patch

This bug is based on false promise. The String subscript operate return zero for characters past the end of the string, This change would be needed if we change the argument type to something like StringView or if we change the behavior of the string class subscript operator. But otherwise it is unnecessary to make a change.

[Darin Adler]

(In reply to Darin Adler from comment #6)
> false promise

false premise(In reply to Darin Adler from comment #6)
> subscript operate return zero

subscript operator returns zero

[Alex Christensen]

Dan and I disagree about what to do here.  This was safe before because of our implementation of WTF::String::operator[].  Dan thinks we should revert this change and encourage programmers to rely on String's bounds checks.  I think that this was still a good change because it makes the code look safer and it probably doesn't change the optimized code generated.  I don't think we should encourage dangerous-looking code in WebKit, and I think WTF::String::operator[] checks should be a fallback to make sure when we make a mistake it doesn't turn into a security issue.