Building Packages With ASAN
Many times CVEs and other security-related bugs that are reported make use of AddressSanitizer in order to identify the defective behavior. Frequently, the reporter of a bug or issue will provide proof of concept or working example that relies on the program or library having been build with AddressSanitizer support.
This article describes what is necessary for building a package with AddressSanitizer support.
One issue of building with AddressSanitizer for Wheezy LTS is that the version of GCC in Wheezy is too old to provide AddressSanitizer support.
Suggestions on how to overcome this limitation are given below.
Passing Appropriate Flags
Generally, what is necessary for AddressSanitizer is to pass the appropriate compiler and linker flags to the build.
Many Debian packages use dpkg-buildflags and so the build can be adjusted without modifying debian/rules by setting environment variables like this:
export DEB_CFLAGS_APPEND=-fsanitize=address export DEB_CPPFLAGS_APPEND=-fsanitize=address export DEB_CXXFLAGS_APPEND=-fsanitize=address export DEB_LDFLAGS_APPEND=-static-libasan
The point of the -static-libasan flag is to have GCC statically link ASAN without also statically linking everything else. Adding that flag makes installation of the resulting packages easier as they will not depend on the libasan shared library.
There are other flags, like -fsanitize=thread, -fsanitize=leak, -fsanitize=undefined, along with their corresponding -static-* flags which may be useful depending on the nature of the bug report or vulnerability.
This approach works for cowbuilder, pbuilder, and other build chroot-type environments (including those invoked by git-buildpackage, for example) which will pass the environment variables through.
If the package being built does not properly support dpkg-buildflags or if a build method is being used which does not properly handle the environment, then it may be necessary temporarily modify debian/rules in order to insert the necessary flags at the appropriate locations. Depending on the package being updated and whether the source is available in Git or come other VCS, it might make sense to create a branch for the temporary modifications to the build.
It is also a good idea to leave the changelog in a state that will prevent accidental upload of the package built with ASAN. This can be accomplished by starting a new changelog entry and leaving the suite set to UNRELEASED.
AddressSanitizer For Wheezy Packages
Because the latest GCC in Wheezy (4.7) does not support ASAN, it is necessary to pursue an alternate path when reproducing bugs. Generally, the best approach is to build the package in question in a Jessie environment. The GCC available in Jesse has support for AddressSanitizer.
As when working with any bug, this sequence should be appropriate:
build the suspected vulnerable package for Jessie (with ASAN support either through environment variables or a modified debian/rules)
- install the newly built vulnerable package into a jessie environment
- reproduce the bug (using the information from the upstream bug report)
- fixing the bug
- build the candidate fixed package for Jessie
- install the fixed package into a Jessie environment
- verify that the vulnerability has been addressed
- rebuild the package for wheezy and follow the normal LTS process
The advice above about setting the suite to UNRELEASED while building/testing with ASAN also applies here. Additionally, it is likely that in order to build a package from Wheezy in Jessie that build dependencies may need to be adjusted. In some cases libraries or APIs may have changed such that it is not possible to complete the build of the package from Wheezy in Jessie. In such cases it may be necessary to modify the build configuration to exclude support for certain features or libraries in order to allow the build complete in a Jessie environment. Of course, this may impact the viability of reproducing the vulnerability.