Re: + signal-always-clear-sa_restorer-on-execve.patch added to -mm tree

[Kees Cook]

On Mon, Mar 11, 2013 at 2:22 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 11 Mar 2013 14:03:20 -0700 Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
>> On Mon, Mar 11, 2013 at 2:01 PM, Andrew Morton
>> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Mon, 11 Mar 2013 13:37:53 -0700 Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>> >
>> >> ...
>> >>
>> >
>> > (pop toasting undone)
>> >
>> >> > Subject: signal: always clear sa_restorer on execve
>> >> >
>> >> > When the new signal handlers are set up, 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().
>> >> >
>> >> > Based on what should be considered "secret" about addresses, it only
>> >> > matters across the exec not the fork (since the VMAs haven't changed until
>> >> > the exec).  But since exec sets SIG_DFL and keeps sa_restorer, this is
>> >> > where it should be fixed.
>> >>
>> >> A note for backporters: you'll likely want to change
>> >> __ARCH_HAS_SA_RESTORER to SA_RESTORER, since the former was recently
>> >> introduced. If not, this will apply but not actually do any good.
>> >
>> > I added this to the changelog, but I fear people won't read it!  Is
>> > there any clever way in which we can have one patch which will work OK
>> > in both old and new kernels?  I can't think of one...
>>
>> Using just SA_RESTORER will work in both cases, but isn't "correct"
>> going forward. :(
>
> That's easy.
>
> patch #1: use SA_RESTORER, cc stable (please promise me this will work OK)

I don't have the ability to build all the architectures, but it seems
like the best flag based on code review.

> patch #2: switch to __ARCH_HAS_SA_RESTORER, no cc stable
>
> I'm assuming this is all for 3.10, btw.  If you think it should be in
> 3.9 then you need to write scarier changelogs.

Well, I'm not sure it needs to be scarier; it's a serious local ASLR
info leak. I was hoping it could go into 3.9 since the expectation is
for it to go to stable, so why not put it in 3.9 now?

Do you want me to spin up the 2-patch solution or is it too much of a hack?

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/