Apport follows symbolic links in path components when creating core dump file
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Apport |
New
|
High
|
Unassigned | ||
| apport (Ubuntu) |
New
|
High
|
Unassigned | ||
Bug Description
Author: Sander Bos, <https:/
Date: 2019-07-30
In data/apport, Apport (implicitly) protects against symbolic link
following for to be created core dump files, but not sufficiently:
181 core_path = os.path.join(cwd, 'core')
...
186 core_file = os.open(core_path, os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o600)
When Apport opens (creates, actually) the core dump file in the
second line, symbolic link following is (implicitly) prevented due to
the combination of "os.O_CREAT" and "os.O_EXCL". However, this only
applies to the final path component of "core_path" (the core dump file
name of "core"), _not_ for the earlier path components (taken from
"cwd"). For those path components, no such prevention is explicitly
applied either. Thus, symbolic links in path components before "core"
are followed. Combined with a different issue of "cwd" being replaced
after reading out the current working directory but before using the "cwd"
variable's value, users may be able to replace any path component of the
"cwd" file system entry with a symbolic link pointing to an arbitrary
location on the file system.
This can for example be used to place core dumps in arbitrary (but
user-writable) directories different than the actual current working
directory of the crashed process, or even (user-writable) directories
outside the root directory in case of a chroot()ed crashed process or
outside of a container / sandbox in case of a containerized / sandboxed
process (because Apport is ran from the host's root file system, not
within such environment).
Proposed fix: make Apport not follow symbolic links in non-last path
components when writing core dump files.
CVE References
| Changed in apport (Ubuntu): | |
| importance: | Undecided → High |
| Changed in apport: | |
| importance: | Undecided → High |
| Seth Arnold (seth-arnold) wrote | #1 |
| Alex Murray (alexmurray) wrote | #2 |
| Alex Murray (alexmurray) wrote | #3 |
| Seth Arnold (seth-arnold) wrote | #4 |
| Alex Murray (alexmurray) wrote | #5 |
| information type: | Private Security → Public Security |
| tags: | added: id-5d640f669cd10e562c3038cf |
Do we want to mitigate this one?
The usual approach is to break paths apart into components, use O_PATH and openat(2) to walk each component individually, checking fstat(2) to make sure that the owner and permissions are correct on each (for whatever 'correct' may mean), etc.
The alternative is to make sure that apport is running with the appropriate user permissions (again, for whatever definition of 'appropriate') so that the final component, the filename, is only written into a directory that the user can legitimately write into anyway.
Quite a lot of programs never bother with the complicated O_PATH version.
If apport is writing these files as an incorrect user that ought to be addressed and may also address this at the same time.
Thanks