Re: [PATCH v2] Unveil patch

Hi Rodrigo,

On Sun, 4 Aug 2024 13:14:24 +0200
Rodrigo Arias <[email protected]> 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
_______________________________________________
Dillo-dev mailing list -- dillo-dev-lx9mn2B4QYRWk0Htik3J/[email protected]
To unsubscribe send an email to dillo-dev-leave-lx9mn2B4QYRWk0Htik3J/[email protected]