Bug 1170174 - AUDIT-FIND: enlightenment: enlightenment_system: setcwd() is missing and a check for "libcurl.so.5" allows arbitrary file existence tests
AUDIT-FIND: enlightenment: enlightenment_system: setcwd() is missing and a ch...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Simon Lees
E-mail List
:
Depends on:
Blocks: 1169238
  Show dependency treegraph
 
Reported: 2020-04-22 09:55 UTC by Matthias Gerstner
Modified: 2020-05-22 08:35 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2020-04-22 09:55:31 UTC
+++ This bug was initially created as a clone of Bug #1169238

g) setcwd() is missing and a check for "libcurl.so.5" allows arbitrary file existence tests

The setuid-root program does not reset the current working directory to a safe
path like "/". Therefore whichever directory the unprivileged user sits in
when invoking the setuid-root program will affect relative path lookups
performed in the setuid-root context.

One such instance is found in the context of the call to
`ecore_file_download_init()ยด which later down the path tries to load the
shared library "libcurl.so.5" via `eina_module_load()`. If the `dlopen()`
fails the latter function performs a `stat()` on the library basename "to
determine" whether the library existed or not. If it thinks the library
existed but couldn't be loaded then it prints out an error message.

An attacker can place a symlink named "libcurl.so.5" in the current working
directory and enlightenment_system will follow the link and behave differently
depending on whether the link target exists or not. Therefore an attacker can
test for existence of arbitrary files also in paths usually not accessible to
him. Example:

```
user /home/user $ /usr/lib64/enlightenment/utils/enlightenment_system 
ddc-list^C

user /home/user $ ln -s /root/.bashrc libcurl.so.5
user /home/user $ /usr/lib64/enlightenment/utils/enlightenment_system
ERR<4165>:eina_module ../src/lib/eina/eina_module.c:319 eina_module_load() could not dlopen("libcurl.so.5", libcurl.so.5: cannot open shared object file: No such file or directory): RTLD_NOW
[...]
```

I suggest to set the CWD to a defined and safe default like "/".

Furthermore I'd adjust the code in `eina_module_load()` to use `dlerror()`
instead of guessing reasons for failed library loads.
Comment 1 Simon Lees 2020-04-22 11:07:29 UTC
Upstream: https://phab.enlightenment.org/T8676
Comment 3 Simon Lees 2020-04-23 07:00:18 UTC
From https://phab.enlightenment.org/T8676

raster added a comment.

btw eina module does use dlerror:
   

   if (!stat(m->file, &st))

     ERR("could not dlopen(\"%s\", %s): %s", m->file, dlerror(),
         (flag == RTLD_NOW) ? "RTLD_NOW" : "RTLD_LAZY");
   else
     DBG("could not dlopen(\"%s\", %s): %s", m->file, dlerror(),
         (flag == RTLD_NOW) ? "RTLD_NOW" : "RTLD_LAZY");

it just upgrades it to an error vs debug message if the file exists ... a non-existing file is just fine - we can just dumbly load the module and then check return for its existence.
Comment 4 Matthias Gerstner 2020-04-30 13:06:33 UTC
Well this one was also easy. It's fixed.
Comment 5 Matthias Gerstner 2020-05-22 08:35:03 UTC
A new common function `e_setuid_setup()` has been pulled out into generic
Enlightenment code. This function now also contains the `chdir("/")`. Closing
as fixed.