Reland "Allow StackTrace to probe for dbghelp on Windows" This is a reland of commit ab086808f8b2babc78bb68e85c2c9da93d00d412 The original change assumed dbghelp.dll was distributed with Chrome but it is not, so this reland instead simply probes for dbghelp.dll by name, which will look in the dll directory on bots and system paths in deployed Chrome. In addition, this CL accidentally fixes some libfuzzer tests which were "passing" by detecting a failure to symbolize a stack. As the dbhhelp probe in base:: now allows symbols to be fetched in unsandboxed test processes these stacks are now valid, and the tests are updated to check for valid output: FuzzerStacktraceTest.SymbolizesUAF FuzzerStacktraceTest.SymbolizesCheck Original change's description: > Allow StackTrace to probe for dbghelp on Windows > > Before this CL stacktraces in some developer builds would not be > symbolized even when the sandbox allowed symbol loading. dbghelp is > delayloaded on Windows and isn't available in some sandboxed processes - > as symbol files cannot be loaded into these processes it isn't very > useful. Sandboxed processes can still produce numeric stacks. > > This CL allows StackTrace() to probe for dbghelp dll and use it if it > can be loaded. This is done by attempting to load the module, then > forcing resolution of delayloaded functions. It cannot probe purely by > calling the LoadAllImports helper as this results in a delayloading > crash if the module cannot be loaded. > > A positive side effect of this is that it is now safe to call > base::StackTrace().ToString() in a sandboxed process. The v8 > configuration can again use the default stacktrace function. > > Bug: 462160529 > Change-Id: I9cfc8d035bb53bb65ed0de356491a4a98809db34 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7303072 > Reviewed-by: Kyle Charbonneau <kylechar@chromium.org> > Commit-Queue: Alex Gough <ajgo@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1567106} Bug: 462160529, 40948553 Change-Id: I5c4f0a8254681376262384a39230da70b10a60a7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7452310 Commit-Queue: Alex Gough <ajgo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ali Hijazi <ahijazi@chromium.org> Reviewed-by: Kyle Charbonneau <kylechar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1569340} NOKEYCHECK=True GitOrigin-RevId: 128ded4b9483a395359f36b786ef66b50265fdd3
Fuzzing is a testing technique that feeds auto-generated inputs to a piece of target code in an attempt to crash the code. It's one of the most effective methods we have for finding security and stability issues (see go/fuzzing-success). You can learn more about the benefits of fuzzing at go/why-fuzz.
This documentation covers the in-process guided fuzzing approach employed by different fuzzing engines, such as libFuzzer or [AFL]. To learn more about out-of-process fuzzers, please refer to the Blackbox fuzzing page in the ClusterFuzz documentation.
In Chromium, you can easily create and submit fuzz targets. The targets are automatically discovered by buildbots, built with different fuzzing engines, then uploaded to the distributed ClusterFuzz fuzzing system to run at scale.
You should fuzz any code which absorbs inputs from untrusted sources, such as the web. If the code parses, decodes, or otherwise manipulates that input, it's an especially good idea to fuzz it.
Create your first fuzz target and submit it by stepping through our Getting Started Guide.
Creating a fuzz target that expects a protobuf instead of a byte stream as input.
Reproducing bugs found by libFuzzer/AFL and reported by ClusterFuzz.
Fuzzing mojo interfaces using automatically generated libprotobuf-mutator fuzzers.