Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using __asan_default_options instead of ASAN_OPTIONS #17

Open
mschwager opened this issue Mar 27, 2024 · 1 comment
Open

Consider using __asan_default_options instead of ASAN_OPTIONS #17

mschwager opened this issue Mar 27, 2024 · 1 comment

Comments

@mschwager
Copy link
Member

ASan flags can be specified in a number of ways: https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run-time-flags.

Currently, we use the ASAN_OPTIONS ENV variable in a number of places:

ruzzy/README.md

Lines 57 to 70 in be40045

```bash
export ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0:use_sigaltstack=0"
```
<details>
<summary>Understanding these options isn't necessary, but if you're curious click here.</summary>
### `ASAN_OPTIONS`
1. Memory allocation failures are common and low impact (DoS), so skip them for now.
1. Like Python, the Ruby interpreter [leaks data](https://github.com/google/atheris/blob/master/native_extension_fuzzing.md#leak-detection), so ignore these for now.
1. Ruby recommends [disabling sigaltstack](https://github.com/ruby/ruby/blob/master/doc/contributing/building_ruby.md#building-with-address-sanitizer).
</details>

ruzzy/Dockerfile

Lines 23 to 26 in be40045

# 1. Skip memory allocation failures for now, they are common, and low impact (DoS)
# 2. The Ruby interpreter leaks data, so ignore these for now
# 3. Ruby recommends disabling sigaltstack: https://github.com/ruby/ruby/blob/master/doc/contributing/building_ruby.md#building-with-address-sanitizer
ENV ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0:use_sigaltstack=0"

The downside of this approach is that we require an additional step from users to export this ENV variable. If we use the __asan_default_options function in our source code, then that's one less step. We still need to confirm that ASAN_OPTIONS can overwrite __asan_default_options at runtime in case users need different options.

@mschwager
Copy link
Member Author

This is a bit more challenging than I initially anticipated due to the way Ruzzy is structured. When fuzzing C extensions, there ends up being two C extensions: the Ruzzy C extension and the target C extension. The Ruzzy C extension is the one we have the most control over, but I believe __asan_default_options would have to be defined in the target C extension. This certainly isn't impossible, but it's more work than adding __asan_default_options to cruzzy.c.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant