[kernel-hardening] Introduction and task request

[kernel-hardening] Introduction and task request

[Reshetova, Elena]

[-- Attachment #1.1: Type: text/plain, Size: 666 bytes --]

Hi everyone, 

 

I would like to introduce myself: I am part of Intel Open Source Technology
Security team and I got lucky enough to have part of my time now allocated
to this project now, so I am happy to start helping. 

What would be the reasonable task for me to do? 

 

I am quite a newbie in proper kernel development work (but not a newbie in
platform security), so please as initial task do not through to me the
biggest dead animal out there with the task to revive it :)

It is going to be a learning exercise for me at least at the beginning, but
I am hoping to learn fast and start bringing value to the project. 

 

Best Regards,
Elena Reshetova

 


[-- Attachment #1.2: Type: text/html, Size: 3040 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7586 bytes --]

Re: [kernel-hardening] Introduction and task request

[Kees Cook]

On Wed, Dec 16, 2015 at 1:34 AM, Reshetova, Elena
<elena.reshetova@intel.com> wrote:
> Hi everyone,
>
>
> I would like to introduce myself: I am part of Intel Open Source Technology
> Security team and I got lucky enough to have part of my time now allocated
> to this project now, so I am happy to start helping.

Hi! Welcome to the project! :)

> What would be the reasonable task for me to do?

I always suggest people work on stuff that interests them. Do you have
any specific areas you like working on, or exploits you'd like to see
stopped?

> I am quite a newbie in proper kernel development work (but not a newbie in
> platform security), so please as initial task do not through to me the
> biggest dead animal out there with the task to revive it.

Heh, understood. We'll be happy to assist you through whatever parts
you might want help with.

> It is going to be a learning exercise for me at least at the beginning, but
> I am hoping to learn fast and start bringing value to the project.

I had mentioned PAX_USERCOPY earlier. I'm not sure how much work
that'll be, but extracting it would be the first step, and you can go
from there. There's no one actively working on it at the moment, and
it would be very nice to have.

There's also the need to improve the kernel's module loader to segment
memory into rx, ro, and rw, in support of the __ro_after_init work. I
or Emese will likely get around to that, but it can probably be done
in parallel.

Or perhaps looking into the prior BPF_HARDEN work (currently this just
disables eBPF, but it used to try to defend against trivial
heap-sprays).

Thanks for joining! :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

RE: [kernel-hardening] Introduction and task request

[Reshetova, Elena]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

>> What would be the reasonable task for me to do?

> I always suggest people work on stuff that interests them. Do you have any 
> specific areas you like working on, or exploits you'd like to see stopped?

I guess ideally people subscribed to this list want all exploits to be stopped 
:) But seriously I don't have any preference at least for now. Since I will 
have to learn a lot in this area I want to start from something which would be 
a reasonable and useful for this project piece of work, that's why I was 
asking for suggestions.

>> I am quite a newbie in proper kernel development work (but not a
>> newbie in platform security), so please as initial task do not through
>> to me the biggest dead animal out there with the task to revive it.

>Heh, understood. We'll be happy to assist you through whatever parts you 
>might want help with.

Thank you!

>> It is going to be a learning exercise for me at least at the
>> beginning, but I am hoping to learn fast and start bringing value to the 
>> project.

>I had mentioned PAX_USERCOPY earlier. I'm not sure how much work that'll be, 
>but extracting it would be the first step, and you can go from there. There's 
>no one actively working on it at the moment, and it would be very nice to 
>have.

Casey is taking care of that, so I will leave it to him.

> Or perhaps looking into the prior BPF_HARDEN work (currently this just 
> disables eBPF, but it used to try to defend against trivial heap-sprays).

 This sounds smth that I can look into. I will be back when I have something 
reasonable ready or researched enough for sensible questions/discussion 
points. I will be away for long holidays until Jan 10, but hoping to return 
with plenty of energy :)

Merry Christmas and Happy New Year to everyone!

Best Regards,
Elena.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7586 bytes --]

Re: [kernel-hardening] Introduction and task request

[Kees Cook]

On Mon, Dec 21, 2015 at 3:16 AM, Reshetova, Elena
<elena.reshetova@intel.com> wrote:
>>> What would be the reasonable task for me to do?
>
>> I always suggest people work on stuff that interests them. Do you have any
>> specific areas you like working on, or exploits you'd like to see stopped?
>
> I guess ideally people subscribed to this list want all exploits to be stopped
> :) But seriously I don't have any preference at least for now. Since I will
> have to learn a lot in this area I want to start from something which would be
> a reasonable and useful for this project piece of work, that's why I was
> asking for suggestions.
>
>>> I am quite a newbie in proper kernel development work (but not a
>>> newbie in platform security), so please as initial task do not through
>>> to me the biggest dead animal out there with the task to revive it.
>
>>Heh, understood. We'll be happy to assist you through whatever parts you
>>might want help with.
>
> Thank you!
>
>>> It is going to be a learning exercise for me at least at the
>>> beginning, but I am hoping to learn fast and start bringing value to the
>>> project.
>
>>I had mentioned PAX_USERCOPY earlier. I'm not sure how much work that'll be,
>>but extracting it would be the first step, and you can go from there. There's
>>no one actively working on it at the moment, and it would be very nice to
>>have.
>
> Casey is taking care of that, so I will leave it to him.
>
>> Or perhaps looking into the prior BPF_HARDEN work (currently this just
>> disables eBPF, but it used to try to defend against trivial heap-sprays).
>
>  This sounds smth that I can look into. I will be back when I have something
> reasonable ready or researched enough for sensible questions/discussion
> points. I will be away for long holidays until Jan 10, but hoping to return
> with plenty of energy :)

The original name was JIT_HARDEN, prior to grsecurity's 3.16 patches
(which just disable JIT entirely):
https://github.com/slashbeast/grsecurity-scrape/blob/master/test/grsecurity-3.0-3.15.5-201407170639.patch

I think it'd be nice to have the the JIT hardening feature, since it
does block heap-sprayed immediate values and probably other stuff, but
I haven't studied it.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Introduction and task request

[Daniel Borkmann]

On 01/06/2016 12:57 AM, Kees Cook wrote:
> On Mon, Dec 21, 2015 at 3:16 AM, Reshetova, Elena
> <elena.reshetova@intel.com> wrote:
>>>> What would be the reasonable task for me to do?
>>
>>> I always suggest people work on stuff that interests them. Do you have any
>>> specific areas you like working on, or exploits you'd like to see stopped?
>>
>> I guess ideally people subscribed to this list want all exploits to be stopped
>> :) But seriously I don't have any preference at least for now. Since I will
>> have to learn a lot in this area I want to start from something which would be
>> a reasonable and useful for this project piece of work, that's why I was
>> asking for suggestions.
>>
>>>> I am quite a newbie in proper kernel development work (but not a
>>>> newbie in platform security), so please as initial task do not through
>>>> to me the biggest dead animal out there with the task to revive it.
>>
>>> Heh, understood. We'll be happy to assist you through whatever parts you
>>> might want help with.
>>
>> Thank you!
>>
>>>> It is going to be a learning exercise for me at least at the
>>>> beginning, but I am hoping to learn fast and start bringing value to the
>>>> project.
>>
>>> I had mentioned PAX_USERCOPY earlier. I'm not sure how much work that'll be,
>>> but extracting it would be the first step, and you can go from there. There's
>>> no one actively working on it at the moment, and it would be very nice to
>>> have.
>>
>> Casey is taking care of that, so I will leave it to him.
>>
>>> Or perhaps looking into the prior BPF_HARDEN work (currently this just
>>> disables eBPF, but it used to try to defend against trivial heap-sprays).
>>
>>   This sounds smth that I can look into. I will be back when I have something
>> reasonable ready or researched enough for sensible questions/discussion
>> points. I will be away for long holidays until Jan 10, but hoping to return
>> with plenty of energy :)
>
> The original name was JIT_HARDEN, prior to grsecurity's 3.16 patches
> (which just disable JIT entirely):
> https://github.com/slashbeast/grsecurity-scrape/blob/master/test/grsecurity-3.0-3.15.5-201407170639.patch
>
> I think it'd be nice to have the the JIT hardening feature, since it
> does block heap-sprayed immediate values and probably other stuff, but
> I haven't studied it.

Was on my todo list as well for some time, but if you have some cycles in
spare, go for it. We recently discussed that it would be nice if it could
be done on a more generic level, in the sense to do [e]BPF insns rewrite
for blinding, so that each JIT would not need to add up even more complexity
and/or duplicate efforts.

RE: [kernel-hardening] Introduction and task request

[Reshetova, Elena]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

>On 01/06/2016 12:57 AM, Kees Cook wrote:
> On Mon, Dec 21, 2015 at 3:16 AM, Reshetova, Elena
> <elena.reshetova@intel.com> wrote:
>>>> What would be the reasonable task for me to do?
>>
>>> I always suggest people work on stuff that interests them. Do you
>>> have any specific areas you like working on, or exploits you'd like to see 
>>> stopped?
>>
>> I guess ideally people subscribed to this list want all exploits to
>> be stopped
>> :) But seriously I don't have any preference at least for now. Since
>> I will have to learn a lot in this area I want to start from
>> something which would be a reasonable and useful for this project
>> piece of work, that's why I was asking for suggestions.
>>
>>>> I am quite a newbie in proper kernel development work (but not a
>>>> newbie in platform security), so please as initial task do not
>>>> through to me the biggest dead animal out there with the task to revive 
>>>> it.
>>
>>> Heh, understood. We'll be happy to assist you through whatever parts
>>> you might want help with.
>>
>> Thank you!
>>
>>>> It is going to be a learning exercise for me at least at the
>>>> beginning, but I am hoping to learn fast and start bringing value
>>>> to the project.
>>
>>> I had mentioned PAX_USERCOPY earlier. I'm not sure how much work
>>> that'll be, but extracting it would be the first step, and you can
>>> go from there. There's no one actively working on it at the moment,
>>> and it would be very nice to have.
>>
>> Casey is taking care of that, so I will leave it to him.
>>
>>> Or perhaps looking into the prior BPF_HARDEN work (currently this
>>> just disables eBPF, but it used to try to defend against trivial 
>>> heap-sprays).
>>
>>   This sounds smth that I can look into. I will be back when I have
>> something reasonable ready or researched enough for sensible
>> questions/discussion points. I will be away for long holidays until
>> Jan 10, but hoping to return with plenty of energy :)
>
> The original name was JIT_HARDEN, prior to grsecurity's 3.16 patches
> (which just disable JIT entirely):
> https://github.com/slashbeast/grsecurity-scrape/blob/master/test/grsec
> urity-3.0-3.15.5-201407170639.patch
>
> I think it'd be nice to have the the JIT hardening feature, since it
> does block heap-sprayed immediate values and probably other stuff, but
> I haven't studied it.

>Was on my todo list as well for some time, but if you have some cycles in 
>spare, go for it. We recently discussed that it would be nice if it could be 
>done on a more generic level, in the sense to do [e]BPF insns rewrite for 
>blinding, so that each JIT would not >need to add up even more complexity 
>and/or duplicate efforts.

Do you have any pointers for this discussion that I can read it also?

Best Regards,
Elena.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7586 bytes --]

Re: [kernel-hardening] Introduction and task request

[Daniel Borkmann]

On 01/11/2016 10:44 AM, Reshetova, Elena wrote:
>> On 01/06/2016 12:57 AM, Kees Cook wrote:
>> On Mon, Dec 21, 2015 at 3:16 AM, Reshetova, Elena
>> <elena.reshetova@intel.com> wrote:
>>>>> What would be the reasonable task for me to do?
>>>
>>>> I always suggest people work on stuff that interests them. Do you
>>>> have any specific areas you like working on, or exploits you'd like to see
>>>> stopped?
>>>
>>> I guess ideally people subscribed to this list want all exploits to
>>> be stopped
>>> :) But seriously I don't have any preference at least for now. Since
>>> I will have to learn a lot in this area I want to start from
>>> something which would be a reasonable and useful for this project
>>> piece of work, that's why I was asking for suggestions.
>>>
>>>>> I am quite a newbie in proper kernel development work (but not a
>>>>> newbie in platform security), so please as initial task do not
>>>>> through to me the biggest dead animal out there with the task to revive
>>>>> it.
>>>
>>>> Heh, understood. We'll be happy to assist you through whatever parts
>>>> you might want help with.
>>>
>>> Thank you!
>>>
>>>>> It is going to be a learning exercise for me at least at the
>>>>> beginning, but I am hoping to learn fast and start bringing value
>>>>> to the project.
>>>
>>>> I had mentioned PAX_USERCOPY earlier. I'm not sure how much work
>>>> that'll be, but extracting it would be the first step, and you can
>>>> go from there. There's no one actively working on it at the moment,
>>>> and it would be very nice to have.
>>>
>>> Casey is taking care of that, so I will leave it to him.
>>>
>>>> Or perhaps looking into the prior BPF_HARDEN work (currently this
>>>> just disables eBPF, but it used to try to defend against trivial
>>>> heap-sprays).
>>>
>>>    This sounds smth that I can look into. I will be back when I have
>>> something reasonable ready or researched enough for sensible
>>> questions/discussion points. I will be away for long holidays until
>>> Jan 10, but hoping to return with plenty of energy :)
>>
>> The original name was JIT_HARDEN, prior to grsecurity's 3.16 patches
>> (which just disable JIT entirely):
>> https://github.com/slashbeast/grsecurity-scrape/blob/master/test/grsec
>> urity-3.0-3.15.5-201407170639.patch
>>
>> I think it'd be nice to have the the JIT hardening feature, since it
>> does block heap-sprayed immediate values and probably other stuff, but
>> I haven't studied it.
>
>> Was on my todo list as well for some time, but if you have some cycles in
>> spare, go for it. We recently discussed that it would be nice if it could be
>> done on a more generic level, in the sense to do [e]BPF insns rewrite for
>> blinding, so that each JIT would not >need to add up even more complexity
>> and/or duplicate efforts.
>
> Do you have any pointers for this discussion that I can read it also?

Sorry, this was just a private conversation during Plumbers, iirc. We agreed
that the way to go would be to try mitigating it on a BPF bytecode level iff
feasible. For example, by expanding/rewriting things like loading constants
into a i) load where the constant is xored with a (each time newly generated)
prandom_u32()/.. value followed by ii) xor on the same reg with that prandom
value itself. And that functionality would be enabled f.e. via sysctl switch.
That would be a first direction to look into, and could help also some more
"exotic" archs like the jit on mips, etc.

Thanks,
Daniel

Re: [kernel-hardening] Introduction and task request

[Loganaden Velvindron]

On Thu, Dec 17, 2015 at 8:25 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Dec 16, 2015 at 1:34 AM, Reshetova, Elena
> <elena.reshetova@intel.com> wrote:
>> Hi everyone,
>>
>>
>> I would like to introduce myself: I am part of Intel Open Source Technology
>> Security team and I got lucky enough to have part of my time now allocated
>> to this project now, so I am happy to start helping.
>
> Hi! Welcome to the project! :)
>
>> What would be the reasonable task for me to do?
>
> I always suggest people work on stuff that interests them. Do you have
> any specific areas you like working on, or exploits you'd like to see
> stopped?
>

And what about the low hanging fruits ? Anything on your mind ?