From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: References: <1476016472.2329.38.camel@cvidal.org> <1476040182.2329.72.camel@cvidal.org> <20161009193731.GD14666@pc.thejh.net> <2236FBA76BA1254E88B949DDB74E612B41BDCAF6@IRSMSX102.ger.corp.intel.com> <1476115319.2329.108.camel@cvidal.org> From: Gengjia Chen Date: Tue, 18 Oct 2016 19:52:22 +0800 Message-ID: Content-Type: multipart/alternative; boundary=001a11401c505852b2053f22531a Subject: Re: [kernel-hardening] self introduction To: Kees Cook Cc: "kernel-hardening@lists.openwall.com" , Juerg Haefliger List-ID: --001a11401c505852b2053f22531a Content-Type: text/plain; charset=UTF-8 > > > > >2016-10-18 4:15 GMT+08:00 Kees Cook : > >On Mon, Oct 17, 2016 at 4:57 AM, Gengjia Chen > wrote: > >>>>> In your research have you seen a common kind of bug that results in > >>>>> the vulnerabilities you find? > >>>> > >>>> No, > >>>> Most of those issues are caused by the lack of checking of user input > >>>> length > >>>> in copy_xx_user functions or afterwards in memcpy functions, > >>>> however, looking into the details, > >>>> they vary among different functions in different files. > >>> > >>>Cool, I hope the recent hardened usercopy stuff will improve that > >>>situation, though there is plenty left to do. > >>> > >>>>> Is there anything that would have > >>>>> significantly made exploitation more difficult in the things you > >>>>> worked on? > >>>> > >>>> Yes! > >>>> > >>>> I mostly exploit buffer overflow vulns by overwrite function pointers > >>>> (such > >>>> as > >>>> pointers in file_operations) of a global object or a heap object > >>>> to redirect execution (and if PXN is enable, we simply use rop > gadgets). > >>>> Therefore mitigation solutions of Function_pointer_overwrite would > >>>> make such kind of exploitation much more diffcult. > >>>> But I don't know if you have let all the pointers "const". > >>> > >>>Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel() > >>>combined with the constify plugin would vastly improve the function > >>>tables that could be const in the kernel. Perhaps that's something you > >>>could look at: porting the pax_open_kernel()/pax_close_kernel() > >>>infrastructure on ARM to upstream? > >>> > >> > >> I found that pax_open_kernel()/pax_close_kernel() infrastructure > >> had been ported on ARM in patch > >> grsecurity-3.1-4.7.8-201610161720.patch, as follow: > >> > >> file: arch/arm/include/asm/pgtable.h > >> > >> #ifdef CONFIG_PAX_KERNEXEC > >> static inline unsigned long pax_open_kernel(void) { > >> #ifdef CONFIG_ARM_LPAE > >> /* TODO */ > >> #else > >> preempt_disable(); > >> BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC)); > >> modify_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC); > >> #endif > >> return 0; > >> } > >> > >> static inline unsigned long pax_close_kernel(void) { > >> #ifdef CONFIG_ARM_LPAE > >> /* TODO */ > >> #else > >> BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_MANAGER)); > >> /* DOMAIN_MANAGER = "client" under KERNEXEC */ > >> modify_domain(DOMAIN_KERNEL, DOMAIN_MANAGER); > >> preempt_enable_no_resched(); > >> #endif > >> return 0; > >> } > >> #else > >> static inline unsigned long pax_open_kernel(void) { return 0; } > >> static inline unsigned long pax_close_kernel(void) { return 0; } > >> #endif > >> > >> Is there anything else I can do to help about this (mitigation > solutions of > >> Function_pointer_overwrite )? > > > >The ARM open/close depends on their use of Domains. For upstream, > >you'd have to examine how Domains are being used (which seems > >different to me). > > So, I will try to start to port pax_open_kernel/pax_close_kernel > arm-specific features to upstream, and keep you in touch. > > >The other work is building the in-kernel > >infrastructure to support write-rarely memory (likely a new section, > >like ro_after_init, etc). > > > > It seems that the constify plugin still not been ported to the lastest > code (v4.9-rc1), > If I understand, you means that a new section should be added > to the upstream , and cooperate with the future constify plugin (the > plugin automatically put those objects to that section ) ? > > > >>>> Becsides, ret2dir is a common way to exploit UAF vulns > >>>> so I think solutions like XPFO is a way to make > >>>> those kind of exploitation more diffcult. > >>> > >>>That's also good to hear. XPFO is making some progress; I'm looking > >>>forward to it's next patch version (though IIUC, we'll need > >>>arch-specific support for it on ARM -- the current patches are x86 > >>>only). > >> > >> I think I can also start with porting XPFO on ARM if you need. > > > >Sure, I'd be very curious to see this! Hopefully Juerg has some ideas > >for helping there (he's been working on the x86 XPFO). > > > >>>> Right now KALSR is still disable in most android devices, > >>>> so it is easy to get kernel symbol address, > >>>> however if KALSR is enable, it may make exploitation more diffcult. > >>> > >>>Eliminating the various address exposures for KASLR is going to be a > >>>long process, I suspect. If you find any that look easily fixable, > >>>let's get them in. :) > >>> > >>>>> Are you interested mostly in ARM-specific things? > >>>> > >>>> I am famillar with ARM-specific things mostly, but I can also accept > >>>> x86/x64 > >>>> tasks. > >>>> > >>>>> Are you interested in kernel-assisted userspace defenses too? > >>>> > >>>> What dose that mean ? something like seccomp ? > >>> > >>>Sure, though I meant things like the brute-force detection, or W^X > >>>memory enforcement for mmap/mprotect, etc. The defenses that the > >>>kernel provides, but are for userspace hardening rather than kernel > >>>hardening. > >> > >> Right now, I am rather more interested in kernel hardening, > >> however, if there are people in charge of all areas, I can also > >> get involve in userspace hardening > > > >Yeah, it's fine to stick with kernel; no worries. :) Thanks! > > > >-Kees > > > > > >-- > >Kees Cook > >Nexus Security > --001a11401c505852b2053f22531a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


>2016-10-18 4:15 GMT+08:00 Kees Cook <keescook@chromium.org>:
>On Mon, Oct 17, 2016 at 4:57 AM, Gengjia Chen <chengjia4574@gmail.com> wrote:
>>>>> In your research have you seen a common= kind of bug that results in
>>>>&= gt; the vulnerabilities you find?
>>>= >
>>>> No,
>>>> Most of those issues are caused by the lack of ch= ecking of =C2=A0user input
>>>> le= ngth
>>>> in copy_xx_user function= s or afterwards in memcpy functions,
>>&= gt;> however, looking into the details,
>= ;>>> they vary among different functions in different files.
=
>>>
>>&= gt;Cool, I hope the recent hardened usercopy stuff will improve that
<= div class=3D"gmail-h5">>>>situation, though there is plenty left t= o do.
>>>
>>>>> Is there anything that would have
>>>>> significantly made exploitation more diffic= ult in the things you
>>>>> wor= ked on?
>>>>
>>>> Yes!
>>>>=
>>>> I mostly exploit buffer over= flow vulns by overwrite function pointers
>= >>> (such
>>>> as
>>>> pointers in file_operations) of a gl= obal object or a heap object
>>>> = to redirect execution (and if PXN is enable, we simply use rop gadgets).
>>>> Therefore mitigation solutions = of Function_pointer_overwrite =C2=A0would
>= >>> make such kind of exploitation much more diffcult.
>>>> But I don't know if you have let all= the pointers "const".
>>><= /div>
>>>Creating a mechanism like PaX'= s pax_open_kernel()/pax_close_kernel()
>>= ;>combined with the constify plugin would vastly improve the function
>>>tables that could be const in the ke= rnel. Perhaps that's something you
>>= ;>could look at: porting the pax_open_kernel()/pax_close_kernel()
<= div class=3D"gmail-h5">>>>infrastructure on ARM to upstream?
=
>>>
>><= /div>
>> I found that pax_open_kernel()/pax_cl= ose_kernel() infrastructure
>> had been = ported on ARM in patch
>> grsecurity-3.1= -4.7.8-201610161720.patch, as follow:
>>=
>> file: arch/arm/include/asm/pgtable.h=
>>
>>= ; #ifdef CONFIG_PAX_KERNEXEC
>> static i= nline unsigned long pax_open_kernel(void) {
&g= t;> #ifdef CONFIG_ARM_LPAE
>> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 /* TODO */
>> #else=
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 preempt_= disable();
>> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC));
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 modify_domain(DOMAIN_KERNEL= , DOMAIN_KERNEXEC);
>> #endif
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
>> }
>>
<= div class=3D"gmail-h5">>> static inline unsigned long pax_close_kerne= l(void) {
>> #ifdef CONFIG_ARM_LPAE
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* TODO */
>> #else
>= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_M= ANAGER));
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0= /* DOMAIN_MANAGER =3D "client" under KERNEXEC */
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 modify_domain(DOMAIN_KER= NEL, DOMAIN_MANAGER);
>> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 preempt_enable_no_resched();
>= ;> #endif
>> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 return 0;
>> }
>> #else
>> static inline = unsigned long pax_open_kernel(void) { return 0; }
>> static inline unsigned long pax_close_kernel(void) { return 0;= }
>> #endif
>>
>> Is there anything else I c= an do to help about this (mitigation solutions of
>> Function_pointer_overwrite )?
>= ;
>The ARM open/close depends on their use = of Domains. For upstream,
>you'd have t= o examine how Domains are being used (which seems
>different to me).=C2=A0

So, I will try to start to port pax_open_kernel/pax_clo= se_kernel=C2=A0
arm-specific features to upstr= eam, and keep you in touch.=C2=A0

>The other work is building the in-kernel
>infrastructure to support write-rarely memory (lik= ely a new section,
>like ro_after_init, etc= ).
>

It seems that the constify plugin still not been p= orted to the lastest code (v4.9-rc1),
If I und= erstand, you means that a new section should be added=C2=A0
to the upstream , and cooperate with the future constify plug= in (the plugin automatically put those objects to that section ) ?

<= br>
>>>> Becsides, ret2dir is a co= mmon way to exploit =C2=A0UAF vulns
>>&g= t;> so =C2=A0I think solutions like XPFO is a way =C2=A0to make
>>>> those kind of exploitation more diffc= ult.
>>>
>>>That's also good to hear. XPFO is making some progress; I&= #39;m looking
>>>forward to it's = next patch version (though IIUC, we'll need
>>>arch-specific support for it on ARM -- the current patches ar= e x86
>>>only).
>>
>> I think I can also s= tart with porting XPFO on ARM if you need.
>= ;
>Sure, I'd be very curious to see thi= s! Hopefully Juerg has some ideas
>for help= ing there (he's been working on the x86 XPFO).
>
>>>> Right now KALSR is = still disable in most android devices,
>>= ;>> so it is easy to get kernel symbol address,
>>>> however if KALSR is enable, it may make exploitati= on more diffcult.
>>>
>>>Eliminating the various address exposures for KAS= LR is going to be a
>>>long process, = I suspect. If you find any that look easily fixable,
>>>let's get them in. :)
&= gt;>>
>>>>> Are you inter= ested mostly in ARM-specific things?
>>&= gt;>
>>>> I am famillar with AR= M-specific things mostly, but I can also accept
>>>> x86/x64
>>>> ta= sks.
>>>>
>>>>> Are you interested in kernel-assisted userspace d= efenses too?
>>>>
>>>> What dose that mean ? =C2=A0something like s= eccomp ?
>>>
>>>Sure, though I meant things like the brute-force detection= , or W^X
>>>memory enforcement for mm= ap/mprotect, etc. The defenses that the
>&g= t;>kernel provides, but are for userspace hardening rather than kernel
>>>hardening.
>>
>> Right now, I am rather = more interested in kernel hardening,
>> = however, if there are people in charge of all areas, I can also
>> get involve in userspace hardening
>
>Yeah, it's fine t= o stick with kernel; no worries. :) Thanks!
&g= t;
>-Kees
>=
>
>--
>Kees Cook
>Nex= us Security

--001a11401c505852b2053f22531a--