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