Messages in this thread | | | From | (Eric W. Biederman) | Date | Mon, 11 Mar 2013 12:42:05 -0700 | Subject | Re: [PATCH] signal: always clear sa_restorer on execve |
| |
Kees Cook <keescook@chromium.org> writes:
> On Mon, Mar 11, 2013 at 12:28 PM, Oleg Nesterov <oleg@redhat.com> wrote: >> On 03/11, Kees Cook wrote: >>> >>> When the new signal handlers are set up for a fork, the location of >>> sa_restorer is not cleared, leaking a parent process's address space >>> location to children. This allows for a potential bypass of the parent's >>> ASLR by examining the sa_restorer value returned when calling sigaction(). >> >> I don't understand. >> >> fork() should not change restorer/etc, and the child has the same address >> space anyway. There is no any leak and the patch can't make any difference >> in this case because flush_signal_handlers() is not called by fork(). > > I probably failed to explain this correctly. From the perspective of > what should be considered "secret", it only matters across the exec, > not the fork (since the VMAs haven't changed until the exec). But the > info leak is easy to see, and this patch fixes it. As you say, since > other things were reset, so should sa_restorer.
At the very least please correct the explanation in your patch description.
Too often I have had seen a confused patch description, indicate confusion elsewhere in the patch. Let's make it easy for reviewers and future bisectors to understand what is intended.
>>> @@ -485,6 +485,9 @@ flush_signal_handlers(struct task_struct *t, int force_default) >>> if (force_default || ka->sa.sa_handler != SIG_IGN) >>> ka->sa.sa_handler = SIG_DFL; >>> ka->sa.sa_flags = 0; >>> +#ifdef __ARCH_HAS_SA_RESTORER >>> + ka->sa.sa_restorer = NULL; >>> +#endif
Also I am inclined to suggest this should be an inline function in a header. clear_sa_restorer(ka);
Just so we don't litter the code with #ifdefs.
Eric
| |