>>> 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 )?
>> 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.
>> 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