[OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages

[Yousong Zhou]

On Sat, 22 Dec 2018 at 16:03, Kevin 'ldir' Darbyshire-Bryant
<ldir at darbyshire-bryant.me.uk> wrote:
>
>
>
> > On 22 Dec 2018, at 04:04, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> >
> > On Sat, 22 Dec 2018 at 01:21, Kevin 'ldir' Darbyshire-Bryant
> > <ldir at darbyshire-bryant.me.uk> wrote:
> >>
> >> Backport https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3
> >>
> >> "Mapping the delay slot emulation page as both writeable & executable
> >> presents a security risk, in that if an exploit can write to & jump into
> >> the page then it can be used as an easy way to execute arbitrary code.
> >>
> >> Prevent this by mapping the page read-only for userland, and using
> >> access_process_vm() with the FOLL_FORCE flag to write to it from
> >> mips_dsemul().
> >>
> >> This will likely be less efficient due to copy_to_user_page() performing
> >> cache maintenance on a whole page, rather than a single line as in the
> >> previous use of flush_cache_sigtramp(). However this delay slot
> >> emulation code ought not to be running in any performance critical paths
> >> anyway so this isn't really a problem, and we can probably do better in
> >> copy_to_user_page() anyway in future.
> >>
> >> A major advantage of this approach is that the fix is small & simple to
> >> backport to stable kernels.
> >>
> >> Reported-by: Andy Lutomirski <luto at kernel.org>
> >> Signed-off-by: Paul Burton <paul.burton at mips.com>
> >> Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot instructions")"
> >>
> >> Without patch:
> >>
> >> cat /proc/self/maps
> >> 00400000-0047a000 r-xp 00000000 1f:03 1823       /bin/busybox
> >> 00489000-0048a000 r-xp 00079000 1f:03 1823       /bin/busybox
> >> 0048a000-0048b000 rwxp 0007a000 1f:03 1823       /bin/busybox
> >> 77ec8000-77eed000 r-xp 00000000 1f:03 2296       /lib/libgcc_s.so.1
> >> 77eed000-77eee000 rwxp 00015000 1f:03 2296       /lib/libgcc_s.so.1
> >> 77eee000-77f81000 r-xp 00000000 1f:03 2470       /lib/libc.so
> >> 77f90000-77f92000 rwxp 00092000 1f:03 2470       /lib/libc.so
> >> 77f92000-77f94000 rwxp 00000000 00:00 0
> >> 7f946000-7f967000 rw-p 00000000 00:00 0          [stack]
> >> 7fefb000-7fefc000 rwxp 00000000 00:00 0
> >> 7ffac000-7ffad000 r--p 00000000 00:00 0          [vvar]
> >> 7ffad000-7ffae000 r-xp 00000000 00:00 0          [vdso]
> >
> > Hi,
> >
> > I must miss something.  After reading another thread on mips security,
> > I was thinking that all segments with w and x permission set were
> > problematic:  the same attacker can write and execute shellcode there,
> > right?  Sorry, if the answer is too apparent ;(
> >
> > Regards,
> >                yousong
>
> Hi Yousong,
>
> My limited understanding goes something like this:  Most of the other segments address ranges change on each execution due to ASLR, thus whilst they can be written to things are harder for an attacker because locations change.  The math emulation page was especially bad because a) user space had write permission to it and b) it was always in a fixed location.  The patch removes user space write permission to the page thus the process should receive a SIGSEGV if it attempts to do so.
>
> Cheers,
>
> Kevin D-B

Thanks for the confirmation ;) . Indeed, I just did a quick read on
the kernel code, that region is mapped at STACK_TOP, essentially a
constant.

It's also worth noting that segments of the executable itself is also
not randomized.  I checked OpenWrt x86/64, malta/be, and CentOS7, they
are all the same.  It's quite a surprise to me.  I always assumed
randomization was applied to all segments.

Regards,
                yousong

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel