Bug 180688 - Fix possible out-of-bounds read in protocolIsInHTTPFamily
Summary: Fix possible out-of-bounds read in protocolIsInHTTPFamily
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-12-11 17:47 PST by Alex Christensen
Modified: 2017-12-14 18:04 PST (History)
3 users (show)

See Also:


Attachments
Patch (3.05 KB, patch)
2017-12-11 17:48 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (3.05 KB, patch)
2017-12-11 18:06 PST, Alex Christensen
dbates: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Christensen 2017-12-11 17:47:04 PST
Fix possible out-of-bounds read in protocolIsInHTTPFamily
Comment 1 Alex Christensen 2017-12-11 17:48:36 PST
Created attachment 329067 [details]
Patch
Comment 2 Alex Christensen 2017-12-11 18:06:30 PST
Created attachment 329070 [details]
Patch
Comment 3 Daniel Bates 2017-12-12 14:25:17 PST
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.
Comment 4 Alex Christensen 2017-12-12 17:54:44 PST
http://trac.webkit.org/r225829
Comment 5 Radar WebKit Bug Importer 2017-12-12 17:55:20 PST
<rdar://problem/36010694>
Comment 6 Darin Adler 2017-12-12 18:26:57 PST
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.
Comment 7 Darin Adler 2017-12-13 21:24:21 PST
(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
Comment 8 Alex Christensen 2017-12-14 18:04:36 PST
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.