Timeout in net fuzzers due to slow GURL normalization of IDNA. |
|||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6092039560364032 Fuzzer: libFuzzer_net_mime_sniffer_fuzzer Job Type: libfuzzer_chrome_msan Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: net_mime_sniffer_fuzzer Sanitizer: memory (MSAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6092039560364032 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.
,
Jan 17 2018
I suspect this is a GURL perf issue. I suppose we could cap the length of the max URL we accept, though any other fuzzer which ever puts a non-length-limited string into a GURL object is likely susceptible (Even just, say, parsing something as an HTTP response could result in a redirect to a similarly long and ugly GURL).
,
Jan 17 2018
Experimentally, pasting the URL from the test into Chrome's omnibox locks up Chrome for a bit over 30 seconds.
,
Jan 17 2018
Has anything changed in how tests are built or such? Having 4 separate targets show non-reproducible timeout failures (with 3 kinds of distinct backtraces) at about the same time sounds like something got made slower...
,
Jan 17 2018
I believe they started passing in larger strings? We also got a report about a DCHECK in the mime fuzzer when input was > 100k (The size DCHECK has been around in the MIME code as long as it existed).
,
Jan 17 2018
We have a 2MB max limit for GURLs going over IPC at least, but this URL is way smaller than that (69kb). My gut is this is a perf issue in ICU
,
Jan 17 2018
The URL certainly does have a lot of IDN substrings.
,
Jan 18 2018
,
Jan 29 2018
,
Jan 29 2018
The runtime profiles for net_mime_sniffer_fuzzer and net_http_security_headers_hpkp_fuzzer point to the same problem -- lots of time spent normalizing the GURL in url::IDNToASCII: ########### net_mime_sniffer_fuzzer ######################## Samples: 108K of event 'cycles', Event count (approx.): 99285977081 Children Self Command Shared Object Symbol + 99.84% 0.00% net_mime_sniffe liburl.so [.] GURL::InitCanonical<std::__1::basic_string<char, std::__1::char_traits<char>, + 99.84% 0.00% net_mime_sniffe liburl.so [.] GURL::GURL + 99.82% 0.00% net_mime_sniffe liburl.so [.] url::(anonymous namespace)::DoHostSubstring<char, unsigned char> + 99.82% 0.00% net_mime_sniffe liburl.so [.] url::(anonymous namespace)::DoHost<char, unsigned char> + 99.82% 0.00% net_mime_sniffe liburl.so [.] url::CanonicalizeHost + 99.82% 0.00% net_mime_sniffe liburl.so [.] url::(anonymous namespace)::DoCanonicalizeStandardURL<char, unsigned char> + 99.82% 0.00% net_mime_sniffe liburl.so [.] url::CanonicalizeStandardURL + 99.82% 0.00% net_mime_sniffe liburl.so [.] url::(anonymous namespace)::DoComplexHost + 99.79% 0.00% net_mime_sniffe liburl.so [.] url::(anonymous namespace)::DoIDNHost + 99.78% 0.00% net_mime_sniffe libicuuc.so [.] icu_60::UTS46::process + 99.78% 0.00% net_mime_sniffe libicuuc.so [.] icu_60::UTS46::nameToASCII + 99.78% 0.00% net_mime_sniffe libicuuc.so [.] uidna_nameToASCII_60 + 99.78% 0.00% net_mime_sniffe liburl.so [.] url::IDNToASCII + 99.78% 0.00% net_mime_sniffe libicuuc.so [.] icu_60::UTS46::processUnicode + 99.77% 0.00% net_mime_sniffe libicuuc.so [.] icu_60::UTS46::processLabel + 93.90% 38.17% net_mime_sniffe libicuuc.so [.] u_strFromPunycode_60 + 61.30% 61.13% net_mime_sniffe net_mime_sniffe[.] __sanitizer_cov_trace_pc_guard ###### net_http_security_headers_hpkp_fuzzer ############## Samples: 17K of event 'cycles', Event count (approx.): 15099080743 Children Self Command Shared Object Symbol + 96.28% 0.00% net_http_securi liburl.so [.] GURL::InitCanonical<std::__1::basic_string<char, std::__1::char_t + 96.28% 0.00% net_http_securi liburl.so [.] GURL::GURL + 95.06% 0.00% net_http_securi liburl.so [.] url::(anonymous namespace)::DoHostSubstring<char, unsigned char> + 95.06% 0.00% net_http_securi liburl.so [.] url::(anonymous namespace)::DoHost<char, unsigned char> + 95.06% 0.00% net_http_securi liburl.so [.] url::CanonicalizeHost + 95.06% 0.00% net_http_securi liburl.so [.] url::(anonymous namespace)::DoCanonicalizeStandardURL<char, unsig + 95.06% 0.00% net_http_securi liburl.so [.] url::CanonicalizeStandardURL + 94.91% 0.00% net_http_securi liburl.so [.] url::(anonymous namespace)::DoComplexHost + 93.60% 0.00% net_http_securi liburl.so [.] url::(anonymous namespace)::DoIDNHost + 92.71% 0.00% net_http_securi libicuuc.so [.] icu_60::UTS46::nameToASCII + 92.71% 0.00% net_http_securi libicuuc.so [.] uidna_nameToASCII_60 + 92.71% 0.00% net_http_securi liburl.so [.] url::IDNToASCII + 92.67% 0.00% net_http_securi libicuuc.so [.] icu_60::UTS46::process + 92.60% 0.16% net_http_securi libicuuc.so [.] icu_60::UTS46::processUnicode + 91.82% 0.16% net_http_securi libicuuc.so [.] icu_60::UTS46::processLabel + 87.53% 0.02% net_http_securi libicuuc.so [.] icu_60::replaceLabel + 87.38% 0.00% net_http_securi libicuuc.so [.] icu_60::UnicodeString::replace + 87.16% 0.01% net_http_securi libicuuc.so [.] icu_60::UnicodeString::doReplace + 86.97% 0.06% net_http_securi libicuuc.so [.] icu_60::UnicodeString::doReplace + 85.68% 85.47% net_http_securi libc-2.24.so [.] __memmove_sse2_unaligned_erms + 8.69% 8.67% net_http_securi net_http_securit[.] __sanitizer_cov_trace_pc_guard
,
Jan 29 2018
,
Jan 29 2018
,
Jan 29 2018
Issue 804714 has been merged into this issue.
,
Jan 29 2018
Issue 806544 has been merged into this issue.
,
Jan 30 2018
Hmm... fuzzing input strings have non-ASCII characters in domain labels that start with 'xn--'. In that case, IDNAInfo.Label i͐.xnBBBCAAA͐<rss.xn--fm-ne7olcACADLaCBBBBBBCAArss.xn--fm-ne7olcACADLaCBBBBBBC AABBBBBBCAAAAAAABH͐.xn--fm-ne7olcAAADLaCBBBBBBCAAA͐.xn--fm-ne7olcADLaCBBBBBBCAAAAA AABH͐.xn--fm-ne7Cs.xn--fm-ne7olcACADBBBBCAAAAAAABH͐.xn--fm-ne7olcAACDLaCCBBBBBBCAA A͐.xn--fm-ne7olcACADLaCBBBBBBCADLaCBBBBBBCAArss .... and many more labels ..... Because they have non-ASCII characters, GURL is calling ICU's uidna_nameToASCII to convert them to punycode. UTS46::ProcessLabel should return early with a bad punycode input ( https://cs.chromium.org/chromium/src/third_party/icu/source/common/uts46.cpp?rcl=c8ca2962b46670ec89071ffd1291688983cd319c&l=704 ) afaict. If that's the case, icu_60::replaceLabel wouldn't be called. So, it's likely that I'm misreading the code.
,
Feb 28 2018
,
Mar 9 2018
As mentioned earlier, we can put a hard upperlimit somewhere on the length of 'host' part in GURL because the spec limits the FQDN to 253 (?) octets. It can be in GURL or ICU or both.
,
Mar 9 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by brajkumar@chromium.org
, Jan 17 2018Components: Internals>Network
Labels: Test-Predator-Wrong CF-NeedsTriage