>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

>>>>> 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