google / google/sanitizers

Sanitizer silently ignores ASAN_OPTIONS when application has some capabilities set

Open
#784 8 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
12.5k
Forks
1.1k
PR merge metrics
No merged PRs in 30d

Description

How to reproduce the issue:

```
$ echo "int main() { return 0; }" > test.c
$ gcc -fsanitize=address -o test test.c

$ ASAN_OPTIONS="help=1" ./test
Available flags for AddressSanitizer:
<...>

$ sudo setcap cap_net_raw=ep ./test
$ ASAN_OPTIONS="help=1" ./test

```

This happens because /proc/self/environ (and other items in the folder) is owned by root for any application with capabilities set. This was done to prevent data leakage from privileged (user < capabilities < root) process to unprivileged user. Application's euid is still user (not root) hence it can't access the file with 400 permissions owned by root:

```
$ cp `which ls` .

$ ./ls -l /proc/self/environ
-r-------- 1 ubuntu ubuntu 0 мар 17 12:26 /proc/self/environ

$ sudo setcap cap_net_raw=ep ./ls

$ ./ls -l /proc/self/environ
-r-------- 1 root root 0 Mar 17 12:27 /proc/self/environ
```

Address sanitizer tries to open /proc/self/environ, fails (permission denied) and silently moves on. The same issue can be reproduced with simple cat utility:

```
$ cp `which cat` .

$ ./cat /proc/self/environ
XDG_VTNR=7LC_PAPER=ru_RU.UTF-8<...>XAUTHORITY=/home/ubuntu/.Xauthority_=./cat

$ sudo setcap cap_net_raw=ep ./cat

$ ./cat /proc/self/environ
./cat: /proc/self/environ: Permission denied
```

It's an open question if we want to fix this issue by switching from /proc/self/environ to some other way of fetching the environment. It's probably enough to display a warning if sanitizer can't get access to /proc/self/environ. But we shouldn't ignore ASAN_OPTIONS silently.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the issue with AddressSanitizer, ASAN_OPTIONS="help=1", and a binary granted cap_net_raw=ep. Inspect the sanitizer path that reads /proc/self/environ and determine how its permission failure is handled. Done means ASAN_OPTIONS is no longer silently ignored for capability-bearing applications, with the chosen behavior covered by a regression test if the project provides one.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
security, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.