sudo is enabled by default for the first installed user.

In sudoers we do specify secure_path as
Defaults 
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

We do not include the current working directory in PATH.

Thus the recommendation is to fork&exec, rather than use system(). I.e.
using execlp(), execvp(), execvp() as appropriate.

I do not see setting PATH or using hard-coded names to binaries as a
protective measure. If one has root, one can bind mount their own binary
on top of /usr/bin/cryptsetup if one really wants zkey to execute their
own cryptsetup.

I am actually not sure why the choice is to exec cryptsetup, instead of
using libcryptsetup.so.12 like cryptsetup itself does. It is not an
additional runtime dependency, because /lib/systemd/systemd-cryptsetup
is typically there and also uses libcryptsetup.so.12 directly.

Having a command as a long string, rather than list of args or an array,
looks like there might be shell escape vulnerabilities. I wonder if I
can trick the program to have key_file_name as passed to system() to be
"filename; rm -rf ~/*" for example.

ps. I see system() is used elsewhere in the codebase too.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1803958

Title:
  [UBUNTU] zkey: Fails to run commands generated by 'zkey cryptsetup'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1803958/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to