Hi Rodrigo, On Sun, 4 Aug 2024 13:14:24 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I think an RCE bug could allow an attacker to write an exploit in an HTML document (or image or any other thing parsed from the web) that would cause Dillo to execute the fork() syscall and then access those files and transfer the content to a remote host. See:
https://en.wikipedia.org/wiki/Return-oriented_programming
If this is the case, unless we prevent Dillo from being able to fork I don't think the unveil(2) protection is enough without pledge(2) to prevent this attack.
We can test it by putting this code after the last unveil() call, as if Dillo was running an exploit:
int ret = fork(); if (ret < 0) { perror("fork failed"); } else if (ret == 0) { /* Child */ FILE *f = fopen("/home/<theuser>/.ssh/id_rsa", "r"); // Adjust path if (f == NULL) { perror("game over exploit, fopen failed"); } else { int c; while ((c = fgetc(f)) != EOF) fputc(c, stdout); fclose(f); } exit(0); }
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
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.
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? Regards, Alex