After researching the literature (aka Google) on this, I've learned that the TOCTOU on `chmod` apparently does not to extend to `lchmod`. In particular, while it is not (possibly never?) safe to call `chmod`, it is always safe to use `lchmod`. So on platforms which implement that function (*BSD derivatives, including macOS), it's perhaps possible to fix the vulnerability?
https://github.com/nodejs/node/issues/23736 https://github.com/libuv/libuv/pull/2054 On Wed, Nov 7, 2018 at 9:24 AM Jan Staněk <jsta...@redhat.com> wrote: > Hi everyone, > recently, a covscan run discovered a potential TOCTOU vulnerability in > `uv_pipe_chmod` on UNIX [1]. It seemed simple, so I attempted to fix it > [2], only to discover that the simple fix does not work. > > TL;DR: > It seems that in the current state, the `uv_pipe_chmod` cannot be > changed to both work as described and not have potential security > vulnerability in it. I'm looking for any suggestions on how to deal with > it, or any hints what else in the library can be changed to fix this. > > Long version: > The original idea was to replace the `stat(2)`/`chmod(2)` calls with > `fstat(2)`/`fchmod(2)` call on platforms that are not broken and fix the > vulnerability at least there. However, I soon discovered that these > calls do not support socket descriptors, and the `stat`/`chmod` are > apparently the only working solution possible -- albeit a vulnerable one. > > From discussion on the issue/PR and AFK, it seems that changing access > permissions on bound unix socket post-creation is unsupported pretty > much anywhere, and the correct way to set the permissions is with > `umask(2)` before the socket is created. That change is of course out of > scope of the `uv_pipe_chmod` function itself. > > What is there to do? Is the `uv_pipe_chmod` considered a part of the API > and needed to be supported? Can it be changed so it can i.e. drop the > old socket and re-create it with the correct permissions? Or are we > stuck with the race condition, and can only minimize it? > > Thanks in advance for any suggestions! > Jan > > [1]: https://github.com/libuv/libuv/issues/2040 > [2]: https://github.com/libuv/libuv/pull/2044 > -- > Jan Staněk > Associate Software Engineer, Core Services > Red Hat Czech > jsta...@redhat.com IM: jstanek > > -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to libuv+unsubscr...@googlegroups.com. > To post to this group, send email to libuv@googlegroups.com. > Visit this group at https://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
