Arbitrary file modification

[dali99]

When running picosnitch as a daemon, it will look for the first folder in /home/ that matches a uid > 1000. then loads config and dumps error logs and the database into that users .config/picosnitch folder.

This can be exploited by symlinking files:

ln -s /etc/importantfile .config/picosnitch/exe.log

When picosnitch starts, it will start appending logs to whatever file this unprivileged user specified.

This can lead to data corruption, denial of service, and in the worst case privilege escalation.

Found by:
@dali99 @jcaesar @emilazy

[emilazy]

FWIW, I expect there are other vulnerabilities of comparable severity lurking here. Things I noticed that made me uneasy during my brief scan of the source code:

• Lots of Python dependencies running in a privileged PID 0 process that probably weren’t designed to be hardened for such a context.

• Lots of circumstances where the code is trusting or interacting with resources owned by non‐privileged users. A PID 0 process taking configuration from an unprivileged user’s home directory is just not safe in general, especially if that unprivileged user is found by scanning /home rather than delegated explicitly to in some trusted configuration.

• site.addsitedir calls that make me nervous (although I’m not sure if they expand to user‐controlled paths in context or not).

• String templating that doesn’t do any escaping and is used to run commands (it seems like this probably isn’t exploitable in context, but it’s very risky in general).

I would suggest that the architecture of the program needs a rethink to account for the highly‐privileged context it executes in, as right now it is likely that there are local privilege escalation bugs lurking even if this specific instance is fixed. A good start would be to ensure that the majority of the code runs as an unprivileged user in a systemd service sandbox, and if it’s not possible to use fine‐grained capabilities or things like PolKit to achieve the tasks that require high privileges, communicate with a separate daemon that runs the minimum amount of code possible, doesn’t accept any configuration from an unprivileged source, doesn’t write to any files, and treats its client as untrusted.

[elesiuta]

Thanks for the detailed report. As I mentioned in NixOS/nixpkgs#336449 I'm taking a break from working on picosnitch. I'll pin this issue for now.