The java-example project does not pull in any external dependencies, but
rather consists of three basic Java fuzzers that hit a synthetic bug
after a few seconds. The project can be used to verify that ClusterFuzz
correctly handles JVM fuzz targets.
* ExampleFuzzer fails with an assertion.
* ExampleValueProfileFuzzer fails with an exception after a few seconds,
but only if running in value profile mode.
* ExampleFuzzerNative fails with an ASan report.
Seems that some bugs in openjpeg can be triggered only in release mode.
More specifically, I was trying to reproduce https://github.com/uclouvain/openjpeg/issues/1228 using the OSS-Fuzz harness and I failed.
I figured out that the bug is indeed reachable by the harness, but can be uncovered only in Release mode, otherwise, an assertion error blocks it.
I guess that they use assertions only in Debug mode (WTF) and remove them in Release.
So, IMO openjpeg should be fuzzed in Release mode as the configuration used in production is the one relevant for security.
This is a speculative fix for an issue we've seen where the class
fails to load.
A simpler approach I did not use is cd-ing into $this_dir. I didn't
use this approach because it will break things if relative paths
are passed to the fuzzer by ClusterFuzz.
The other reason that I think could be responsible for the missing
class issues is not unpacking the zipfile fully.
* Remove manual denylisting in tensorflow
Remove manual denylisting of fuzzing targets using bazel query via tags.
* Add a space in the bazel query.
* Update the tag we should denylist.
* Update the comment.
json-sanitizer uses Maven and has no native dependencies.
The build file is loosely divided into two parts. The first part is
project-specific, the second one can serve as a template for JVM fuzz
targets without native dependencies.
The following three fuzz targets are added to OSS-Fuzz and can later be
moved into the json-sanitizer tree:
* DenylistFuzzer verifies that the output of json-sanitizer never
contains certain substrings that can lead to HTML or XML injections.
* IdempotenceFuzzer verifies that json-sanitizer is idempotent.
* ValidJsonFuzzer verifies that the output of json-sanitizer is valid
JSON by passing it into gson.
compile, bad_build_check, and presubmit.py require small tweaks to
support JVM fuzz targets, most of which are similar to those required
for Python. The following additional changes are required:
* Since the Jazzer driver binary already links in libFuzzer, it should
not be built as a static library.
* It is not clear how to do architecture checks as JVM fuzz targets can
load their native dependencies dynamically at runtime. For now, the
check is disabled.
* The Jazzer binaries are moved into $OUT and need to be skipped over in
find_fuzz_targets.
Jazzer is built from HEAD using Bazel and the clang toolchain provided
by base-clang. While it could be built with OpenJDK 8, which is
available as a package, JVM fuzz targets should not be forced to be
compatible with Java 8. For this reason, the official binary release of
OpenJDK 15 is pulled into both base-builder and base-runner and set as
JAVA_HOME. It is trimmed down in size by removing src.zip and the jmods
directory.
Jazzer consists of the following four components:
* The API (`jazzer_api_deploy.jar`), which is required for fuzz targets
that use FuzzedDataProvider or custom method hooks, is made available
in /usr/local/lib in base-builder.
* The driver (`jazzer_driver`), which links in libFuzzer and is reused
across fuzz targets. Since it is used to run fuzz targets, it is
included into base-runner.
* The ASanified driver (`jazzer_driver_asan`), which is obtained from
`jazzer_driver` by linking in ASan.
* The agent (`jazzer_agent_deploy.jar`), which bundles the runtime
instrumentation agent with the Jazzer API. It is loaded by the driver
and thus also included into base-runner.
The changes to the infra scripts required by JVM fuzz targets will be
submitted as a separate PR.
Apparently the latest version of meson (0.57.0) somehow broke systemd
OSS-Fuzz builds. Since it was released systemd has been failing to compile
with
```
2021-02-14T21:23:53.3854577Z [481/664] clang++ -o fuzz-compress fuzz-compress.p/src_fuzz_fuzz-compress.c.o -L/usr/lib/clang/12.0.0/lib/linux -Wl,--as-needed -Wl,--allow-shlib-undefined '-Wl,-rpath,$ORIGIN/src/shared' -Wl,-rpath-link,/work/build/src/shared -Wl,--start-group src/shared/libsystemd-shared-247.so -lFuzzingEngine -Wl,--end-group
2021-02-14T21:23:53.3856578Z FAILED: fuzz-compress
2021-02-14T21:23:53.3858714Z clang++ -o fuzz-compress fuzz-compress.p/src_fuzz_fuzz-compress.c.o -L/usr/lib/clang/12.0.0/lib/linux -Wl,--as-needed -Wl,--allow-shlib-undefined '-Wl,-rpath,$ORIGIN/src/shared' -Wl,-rpath-link,/work/build/src/shared -Wl,--start-group src/shared/libsystemd-shared-247.so -lFuzzingEngine -Wl,--end-group
2021-02-14T21:23:53.4160985Z /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../libFuzzingEngine.a(FuzzerTracePC.o): In function `size':
2021-02-14T21:23:53.4162332Z /usr/local/bin/../include/c++/v1/set:641: undefined reference to `__asan_report_load8'
2021-02-14T21:23:53.4164959Z /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../libFuzzingEngine.a(FuzzerTracePC.o): In function `fuzzer::TracePC::HandleInline8bitCountersInit(unsigned char*, unsigned char*)':
2021-02-14T21:23:53.4166954Z /src/libfuzzer/FuzzerTracePC.cpp:61: undefined reference to `__asan_report_store1'
2021-02-14T21:23:53.4168493Z /src/libfuzzer/FuzzerTracePC.cpp:59: undefined reference to `__asan_report_store1'
2021-02-14T21:23:53.4170699Z /src/libfuzzer/FuzzerTracePC.cpp:59: undefined reference to `__asan_report_store1'
2021-02-14T21:23:53.4172114Z /src/libfuzzer/FuzzerTracePC.cpp:63: undefined reference to `__asan_report_store1'
2021-02-14T21:23:53.4173550Z /src/libfuzzer/FuzzerTracePC.cpp:63: undefined reference to `__asan_report_store1'
2021-02-14T21:23:53.4174876Z /src/libfuzzer/FuzzerTracePC.cpp:54: undefined reference to `__asan_handle_no_return'
2021-02-14T21:23:53.4176322Z /src/libfuzzer/FuzzerTracePC.cpp:64: undefined reference to `__asan_handle_no_return'
2021-02-14T21:23:53.4177521Z /src/libfuzzer/FuzzerTracePC.cpp:65: undefined reference to `__asan_handle_no_return'
2021-02-14T21:23:53.4178936Z /src/libfuzzer/FuzzerTracePC.cpp:66: undefined reference to `__asan_handle_no_return'
2021-02-14T21:23:53.4180439Z /src/libfuzzer/FuzzerTracePC.cpp:67: undefined reference to `__asan_handle_no_return'
2021-02-14T21:23:53.4182667Z /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../libFuzzingEngine.a(FuzzerTracePC.o):/src/libfuzzer/FuzzerTracePC.cpp:44: more undefined references to `__asan_handle_no_return' follow
2021-02-14T21:23:53.4185448Z /usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../libFuzzingEngine.a(FuzzerTracePC.o): In function `fuzzer::TracePC::HandleInline8bitCountersInit(unsigned char*, unsigned char*)':
2021-02-14T21:23:53.4189221Z /src/libfuzzer/FuzzerTracePC.cpp:61: undefined reference to `__asan_report_load8'
2021-02-14T21:23:53.4190419Z /src/libfuzzer/FuzzerTracePC.cpp:61: undefined reference to `__asan_report_store8'
2021-02-14T21:23:53.4191618Z /src/libfuzzer/FuzzerTracePC.cpp:61: undefined reference to `__asan_report_store8'
2021-02-14T21:23:53.4192815Z /src/libfuzzer/FuzzerTracePC.cpp:41: undefined reference to `__asan_report_load8'
2021-02-14T21:23:53.4194218Z /src/libfuzzer/FuzzerTracePC.cpp:46: undefined reference to `__asan_report_store8'
2021-02-14T21:23:53.4195434Z /src/libfuzzer/FuzzerTracePC.cpp:53: undefined reference to `__asan_report_store8'
2021-02-14T21:23:53.4196673Z /src/libfuzzer/FuzzerTracePC.cpp:55: undefined reference to `__asan_report_store8'
2021-02-14T21:23:53.4278293Z /src/libfuzzer/FuzzerTracePC.cpp:61: undefined reference to `__asan_report_store1'
2021-02-14T21:23:53.4279995Z /src/libfuzzer/FuzzerTracePC.cpp:64: undefined reference to `__asan_report_load8'
```
and so on.
In qemu/qemu@fff7111 we added configurations for fuzzing virtio-9p
devices. However, these fuzzers are presently stalled on oss-fuzz,
because the build image doesn't have the necessary libattr, and
libcap-ng libraries. Fix that.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
* Don't worry about raqm/fonts for now.
* Current fuzzer doesn't test the font handling
* Upstream (pillow) changes are coming to packaging for raqm/harfbuzz/fribidi
* Use core setup.py options for build linking
explcitly copy libraries in pyinstaller
* [cryptofuzz, bignum-fuzzer] Fix AFL++ builds
* [cryptofuzz, bignum-fuzzer] Don't build Golang
Because it's already part of the base image.
* [cryptofuzz, bignum-fuzzer] Retrigger CI
* libsodium: don't use the stack for potentially large data
Also check return codes of verification functions, and properly
check the random implementation name.
* Add license headers
It should make the script compatible with binutils-2.36.1 (where
"callq" is no longer present in the output of objdump)
It was spotted in https://github.com/systemd/systemd/pull/18528
Fabian Meumertzheim