Hi, On Sun, Aug 04, 2024 at 05:14:52PM +0200, a1ex@dismail.de wrote:
If you see your SSH key in the stdout, the unveil() protection alone is not enough to mitigate this attack (check that the key exists first, I used id_rsa). This would also confirm that unveil() settings don't get inherited in forked children.
I placed that after the last unveil call and made sure I used a valid key path. Here is the console output:
game over exploit, fopen failed: No such file or directory
From what I am seeing, fork() inherits the unveil, and exec() does not.
Hmm, I guess that makes more sense. I was thinking we could read the preferences only from Dillo, then unveil accordingly, and then all DPIs would already get the unveiled environment. But as you comment, on the exec() the unveil will reset, so we will need to re-read the dillorc file again. I think this is also a good approach in case someone runs the dpid by hand, so it adheres to what dillorc says.
Maybe for now we can add a simple implementation of the parser just to parse the "save_dir" and the new "enable_unveil" (or similar) option, like dpid is doing for dpi_dir.
Ok thanks, I will try to use that as an example and see if I can get anywhere with it.
Thanks!
I think we could just not allow $HOME to be set as save_dir (or any directory that contains $HOME, like /home) and refuse to start if this is the case.
Not sure I understand what this achieves. So '/home/user' would be blocked, but '/home/user/foo' would be allowed? Why not just explicitly block access to ~/.ssh with unveil, and then let the user do whatever they want after that?
Yeah, but there may be a lot of other unknown directories we don't want Dillo to access to (~/.config, ~/.cache, ...). So I think is a good approach to block all directories in home, except the downloads one. Another attack may involve encrypting ~/Pictures and asking for a ransom, so we should prevent any access to home that is not required. Best, Rodrigo.