On 12/22/18 10:26 AM, Yousong Zhou wrote:
On Sat, 22 Dec 2018 at 16:03, Kevin 'ldir' Darbyshire-Bryant
<[email protected]> wrote:
On 22 Dec 2018, at 04:04, Yousong Zhou <[email protected]> wrote:
On Sat, 22 Dec 2018 at 01:21, Kevin 'ldir' Darbyshire-Bryant
<[email protected]> 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 <[email protected]>
Signed-off-by: Paul Burton <[email protected]>
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
Hi Yousong,
ASLR is currently not activated by default in OpenWrt, so the binary
itself is not randomized. Activate CONFIG_PKG_ASLR_PIE to compile
Openwrt with ASLR, but this increases the size of the binary.
I haven't understood why some parts of the busybox binary and other
binaries are mapped rwx, when I look into it with readelf no section is
mapped rwx, but it looks like some sections are ending at an not page
aligned offset and the next section starts directly after that. I assume
that Linux merges the permissions when one page needs different permissions.
I am still not sure if the common mips CPUs (24Kec, 74Kec) support
restricting execution on pages anyway.
Huake
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
