oss-fuzz/projects/elfutils/build.sh

144 lines
5.7 KiB
Bash
Raw Normal View History

#!/bin/bash -eu
# Copyright 2021 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
################################################################################
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
# This script is supposed to be compatible with OSS-Fuzz, i.e. it has to use
# environment variables like $CC, $CFLAGS, $OUT, link the fuzz targets with CXX
# (even though the project is written in C) and so on:
# https://google.github.io/oss-fuzz/getting-started/new-project-guide/#buildsh
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
# It can be used to build and run the fuzz targets using Docker and the images
# provided by the OSS-Fuzz project: https://google.github.io/oss-fuzz/advanced-topics/reproducing/#building-using-docker
# It can also be used to build and run the fuzz target locally without Docker.
# After installing clang and the build dependencies of libelf by running something
# like `dnf build-dep elfutils-devel` on Fedora or `apt-get build-dep libelf-dev`
# on Debian/Ubuntu, the following commands should be run:
#
# $ git clone https://github.com/google/oss-fuzz
# $ cd oss-fuzz/projects/elfutils
# $ git clone git://sourceware.org/git/elfutils.git
# $ ./build.sh
# $ unzip -d CORPUS fuzz-dwfl-core_seed_corpus.zip
# $ ./out/fuzz-dwfl-core CORPUS/
set -eux
SANITIZER=${SANITIZER:-address}
flags="-O1 -fno-omit-frame-pointer -g -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=$SANITIZER -fsanitize=fuzzer-no-link"
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
export CC=${CC:-clang}
export CFLAGS=${CFLAGS:-$flags}
export CXX=${CXX:-clang++}
export CXXFLAGS=${CXXFLAGS:-$flags}
export SRC=${SRC:-$(realpath -- $(dirname -- "$0"))}
export OUT=${OUT:-"$SRC/out"}
mkdir -p "$OUT"
export LIB_FUZZING_ENGINE=${LIB_FUZZING_ENGINE:--fsanitize=fuzzer}
cd "$SRC/elfutils"
# ASan isn't compatible with -Wl,--no-undefined: https://github.com/google/sanitizers/issues/380
find -name Makefile.am | xargs sed -i 's/,--no-undefined//'
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
# ASan isn't compatible with -Wl,-z,defs either:
# https://clang.llvm.org/docs/AddressSanitizer.html#usage
sed -i 's/^\(ZDEFS_LDFLAGS=\).*/\1/' configure.ac
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
if [[ "$SANITIZER" == undefined ]]; then
additional_ubsan_checks=alignment
UBSAN_FLAGS="-fsanitize=$additional_ubsan_checks -fno-sanitize-recover=$additional_ubsan_checks"
CFLAGS="$CFLAGS $UBSAN_FLAGS"
CXXFLAGS="$CXXFLAGS $UBSAN_FLAGS"
# That's basicaly what --enable-sanitize-undefined does to turn off unaligned access
# elfutils heavily relies on on i386/x86_64 but without changing compiler flags along the way
sed -i 's/\(check_undefined_val\)=[0-9]/\1=1/' configure.ac
fi
if [[ "$SANITIZER" == memory ]]; then
CFLAGS+=" -U_FORTIFY_SOURCE"
CXXFLAGS+=" -U_FORTIFY_SOURCE"
fi
autoreconf -i -f
if ! ./configure --enable-maintainer-mode --disable-debuginfod --disable-libdebuginfod \
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
--without-bzlib --without-lzma --without-zstd \
CC="$CC" CFLAGS="-Wno-error $CFLAGS" CXX="-Wno-error $CXX" CXXFLAGS="$CXXFLAGS" LDFLAGS="$CFLAGS"; then
cat config.log
exit 1
fi
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
ASAN_OPTIONS=detect_leaks=0 make -j$(nproc) V=1
# External dependencies used by the fuzz targets have to be built
# with MSan explicitly to avoid bogus "security" bug reports like
# https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45630,
# https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45631 and
# https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45633
# To make sure all the fuzz targets use the same version of zlib
# it's also built with ASan and UBSan.
git clone https://github.com/madler/zlib
pushd zlib
git checkout v1.2.12
if ! ./configure --static; then
cat configure.log
exit 1
fi
make -j$(nproc) V=1
popd
zlib=zlib/libz.a
# When new fuzz targets are added it usually makes sense to notify the maintainers of
# the elfutils project using the mailing list: elfutils-devel@sourceware.org. There
# fuzz targets can be reviewed properly (to make sure they don't fail to compile
# with -Werror for example), their names can be chosen accordingly (so as not to spam
# the mailing list with bogus bug reports that are opened and closed once they are renamed)
# and so on. Also since a lot of bug reports coming out of the blue aren't exactly helpful
# fuzz targets should probably be added one at a time to make it easier to keep track
# of them.
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
$CC $CFLAGS \
-D_GNU_SOURCE -DHAVE_CONFIG_H \
-I. -I./lib -I./libelf -I./libebl -I./libdw -I./libdwelf -I./libdwfl -I./libasm \
-c "$SRC/fuzz-dwfl-core.c" -o fuzz-dwfl-core.o
$CXX $CXXFLAGS $LIB_FUZZING_ENGINE fuzz-dwfl-core.o \
./libdw/libdw.a ./libelf/libelf.a "$zlib" \
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
-o "$OUT/fuzz-dwfl-core"
2022-03-16 15:04:20 +00:00
$CC $CFLAGS \
-D_GNU_SOURCE -DHAVE_CONFIG_H \
-I. -I./lib -I./libelf -I./libebl -I./libdw -I./libdwelf -I./libdwfl -I./libasm \
-c "$SRC/fuzz-libelf.c" -o fuzz-libelf.o
$CXX $CXXFLAGS $LIB_FUZZING_ENGINE fuzz-libelf.o \
2022-03-16 15:04:20 +00:00
./libasm/libasm.a ./libebl/libebl.a ./backends/libebl_backends.a ./libcpu/libcpu.a \
./libdw/libdw.a ./libelf/libelf.a ./lib/libeu.a "$zlib" \
-o "$OUT/fuzz-libelf"
$CC $CFLAGS \
-D_GNU_SOURCE -DHAVE_CONFIG_H \
-I. -I./lib -I./libelf -I./libebl -I./libdw -I./libdwelf -I./libdwfl -I./libasm \
-c "$SRC/fuzz-libdwfl.c" -o fuzz-libdwfl.o
$CXX $CXXFLAGS $LIB_FUZZING_ENGINE fuzz-libdwfl.o \
./libasm/libasm.a ./libebl/libebl.a ./backends/libebl_backends.a ./libcpu/libcpu.a \
./libdw/libdw.a ./libelf/libelf.a ./lib/libeu.a "$zlib" \
-o "$OUT/fuzz-libdwfl"
2022-03-16 15:04:20 +00:00
# Corpus
[elfutils] start afresh (#6944) The elfutils project was integrated into OSS-Fuzz in https://github.com/google/oss-fuzz/pull/6670 where Dockerfile pointed to a fork of the official repository with a series of patches that were supposed to make it compile on OSS-Fuzz. Apart from that there was a fuzz target that effectively wrapped the readelf utility by applying a patch to its source code. On the whole it worked at the time but I think there are a few issues: 1. It's hard to point OSS-Fuzz to the official repository (because most of the patches touch the build system and they can't always be applied cleanly); 2. It's almost impossible to add new fuzz targets covering other use cases; 3. It's not possible to build fuzz targets without Docker 4. Since the fuzz target mostly wraps the readelf utility it looks more like a CLI tool than a fuzz target. It calls exit when it should just return 0 to let it keep going and so on. This PR should addresses all those issues apart from 4. The fuzz target was just removed and another one was added instead. (It can be added later though but since it isn't exactly maintainable with the build script pointing at the official repository it should probably be rewritten: https://sourceware.org/pipermail/elfutils-devel/2021q4/004295.html) The new fuzz target covers the code that `systemd` uses to parse untrusted data. Currently it can be used to trigger various issues like heap-buffer-overflows and inifinite loops that in theory can bring down coredump processing on machines where systemd-coredump is used by default. Even though those issues were discovered by one of `systemd` fuzz targets I think elfutils bugs should be caught and reported by elfutils fuzz targets.
2021-12-01 11:15:17 +00:00
cp "$SRC/fuzz-dwfl-core_seed_corpus.zip" "$OUT"