When the exec family is called from a multi-threaded process, all threads should terminate - the whole process should be replaced.
Currently, we end up in a weird state where the thread that called exec gets a new page directory but maintains its reference to the original file descriptor table, and all of the other threads continue to live, which can lead to a thread being able to reference file descriptor entries opened by the newly exec'd "process", and likely other shenanigans.
An exploit seen in a CTF competition (which I am disappointed was not reported here) involves exec'ing sudo in a thread, after which other lingering threads can read from file descriptors that sudo opens like ones for /etc/master.passwd.
In addition to terminating threads, we should probably ensure the "surviving" thread is the main thread (the thread group leader) regardless of which thread actually called exec, though we do have other thread-related issues with parent/child relationships that also need to be addressed.
When the
execfamily is called from a multi-threaded process, all threads should terminate - the whole process should be replaced.Currently, we end up in a weird state where the thread that called
execgets a new page directory but maintains its reference to the original file descriptor table, and all of the other threads continue to live, which can lead to a thread being able to reference file descriptor entries opened by the newly exec'd "process", and likely other shenanigans.An exploit seen in a CTF competition (which I am disappointed was not reported here) involves exec'ing
sudoin a thread, after which other lingering threads can read from file descriptors thatsudoopens like ones for/etc/master.passwd.In addition to terminating threads, we should probably ensure the "surviving" thread is the main thread (the thread group leader) regardless of which thread actually called
exec, though we do have other thread-related issues with parent/child relationships that also need to be addressed.