Security Level: high/server/workstation/virtualization
 

27.01.2012 21:26, Alex Efros wrote:

> As for me, spending ~1% performance for ~all hardened is good trade off,
> but spending 4% more for protection against leaking information in freed
> memory is too much for workstation (and for most servers too), so I
> recommend to change workstation security level to not enable
> CONFIG_PAX_MEMORY_SANITIZE by default.

Isn't sacrificing 4% of performance to prevent attackers from circumventing
all the other measures like KERNEXEC and UDEREF with an arbitrary write and
a kernel memory leak a fair deal? I think it is, often than not.

If you need some profiles to favour small performance gains over more secure
defaults, then maybe you should propose additional profiles to accomplish
exactly that, and clearly state that 4% gain in the config help.

Security Level: high/server/workstation/virtualization
 

Hi!

Two small notes related to security level defaults:

1) On my system vmware reboot host OS when starting guest OS if any one
(or both) of these are enabled:

CONFIG_PAX_KERNEXEC (enabled by default on workstation security level)
CONFIG_PAX_MEMORY_UDEREF

2) When wireshark started by non-root user this option kill all my
processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):

CONFIG_GRKERNSEC_BRUTE (enabled by default on all security levels)

--
WBR, Alex.

Security Level: high/server/workstation/virtualization
 

On 27 Jan 2012 at 16:25, Kevin Chadwick wrote:

> Thanks for the info. In a discussion about malloc flags, it was
> mentioned on the OpenBSD list that clearing the memory
> immediately brought little in security as it would be cleared before
> re-use and if anything could increase the chances of an attacker
> writing to areas that he wanted to.

the SANITIZE feature of PaX doesn't clear userland memory, it clears kernel pages
when they're freed back to the lowest level kernel memory allocator. it is meant
to reduce the amount of information that can be leaked by kernel bugs from kernel
space to userland. if these pages were cleared on allocation only (as is the case
without SANITIZE) then they'd be subject to said infoleaking bugs while sitting
on the free page list.

also as an optimization these early-cleared pages are not cleared again when the kernel
metes them out to the next user.

> > Core2Duo
>
> I don't know the details but according to OpenBSDs Theo, the Core2Duo
> had some major design flaws that intel couldn't fix with microcode with
> some security implications.

yeah, Theo for president! of the lunatic asylum.

Security Level: high/server/workstation/virtualization
 

On 27 Jan 2012 at 22:19, Alex Efros wrote:

> Hi!
>
> Two small notes related to security level defaults:
>
> 1) On my system vmware reboot host OS when starting guest OS if any one
> (or both) of these are enabled:
>
> CONFIG_PAX_KERNEXEC (enabled by default on workstation security level)
> CONFIG_PAX_MEMORY_UDEREF

vmware needs patching to work with these features, i think there's a bug or two
open about this in the gentoo bugzilla already.

> 2) When wireshark started by non-root user this option kill all my
> processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):

can you generate a coredump and see what the backtrace shows?

Security Level: high/server/workstation/virtualization
 

On Fri, 27 Jan 2012 22:19:42 +0200
Alex Efros <powerman@powerman.name> wrote:

> Hi!
>
> Two small notes related to security level defaults:
>
> 1) On my system vmware reboot host OS when starting guest OS if any
> one (or both) of these are enabled:
>
> CONFIG_PAX_KERNEXEC (enabled by default on workstation security
> level) CONFIG_PAX_MEMORY_UDEREF
>
> 2) When wireshark started by non-root user this option kill all my
> processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):
>
> CONFIG_GRKERNSEC_BRUTE (enabled by default on all security levels)
>

You should be using the virt profile.

--
Matthew Thode (prometheanfire)

Security Level: high/server/workstation/virtualization
 

Hi!

On Fri, Jan 27, 2012 at 03:14:12PM -0600, Matthew Thode wrote:
> You should be using the virt profile.

Why? As far as I understand, virt profile is for guest OS, not host OS.

--
WBR, Alex.

Security Level: high/server/workstation/virtualization
 

El 27/01/12 22:20, Alex Efros escribió:
> Hi!
>
> On Fri, Jan 27, 2012 at 03:14:12PM -0600, Matthew Thode wrote:
>> You should be using the virt profile.
> Why? As far as I understand, virt profile is for guest OS, not host OS.
Virt profile is for both of them, that's why it is called virt. Anyway
and since some of the issues regarding hardening and virt are becoming
solved on some hardwares as time passes some of the settings on virt are
tunable so you can try enabling them first.

Security Level: high/server/workstation/virtualization
 

Hi!

On Fri, Jan 27, 2012 at 10:40:43PM +0200, pageexec@freemail.hu wrote:
> > 2) When wireshark started by non-root user this option kill all my
> > processes (https://bugs.gentoo.org/show_bug.cgi?id=379369):
> can you generate a coredump and see what the backtrace shows?

Actually I can't get core. :-/ Look:

I've re-emerged wireshark using this:

# CFLAGS="-march=prescott -O1 -pipe -ggdb"
FEATURES="userpriv usersandbox userfetch parallel-fetch nostrip"
emerge wireshark

Now:

$ sudo zgrep ELF_CORE /proc/config.gz
CONFIG_ELF_CORE=y
$ cat /proc/sys/kernel/core_pattern
core
$ grep core /etc/security/limits.conf | grep -v '^#'
* soft core unlimited
$ cat /etc/limits.conf
* C20480
$ ulimit -c unlimited
$ ulimit -c
unlimited
$ dumpcap
Segmentation fault
$ ls -l core
ls: cannot access core: No such file or directory

But under strace core generated ok:

$ strace dumpcap
...
socket(PF_PACKET, SOCK_RAW, 768) = -1 EPERM (Operation not permitted)
socket(PF_INET, SOCK_PACKET, 0x300 /* IPPROTO_??? */) = -1 EPERM (Operation not permitted)
open("/sys/class/net", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOE XEC) = -1 EACCES (Permission denied)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
--- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} (Segmentation fault) ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

$ ls -l core
-rw------- 1 powerman users 446464 Jan 28 00:59 core

$ gdb
(gdb) core core
[New LWP 26950]
Core was generated by `strace dumpcap'.
Program terminated with signal 11, Segmentation fault.
#0 0xa6dda422 in __kernel_vsyscall ()
(gdb) bt
#0 0xa6dda422 in __kernel_vsyscall ()
#1 0xa6c946a6 in ?? ()
#2 0x1f69cd64 in ?? ()
#3 0x1f663179 in ?? ()
#4 0x0000000b in ?? ()
#5 0x00000000 in ?? ()
(gdb)

Here is another way:

$ gdb dumpcap
(gdb) run
Starting program: /usr/bin/dumpcap

Program received signal SIGSEGV, Segmentation fault.
0xab94e152 in ?? ()
(gdb) bt
#0 0xab94e152 in ?? ()
#1 0xaba4c197 in ?? ()
#2 0xaba4fd99 in ?? ()
#3 0xaba51e37 in ?? ()
#4 0x16f4269d in get_interface_list_findalldevs (err=0xbdaff4a8, err_str=0xbdaff4a4)
at capture-pcap-util.c:174
#5 0x16f409c0 in get_interface_list (err=0xbdaff4a8, err_str=0xbdaff4a4)
at capture-pcap-util-unix.c:110
#6 0x16f469d2 in capture_interface_list (err=0xbdaff4a8, err_str=0xbdaff4a4) at dumpcap.c:797
#7 0x16f42345 in capture_opts_trim_iface (capture_opts=0x16f4e060, capture_device=0x0)
at capture_opts.c:770
#8 0x16f476cd in main (argc=<optimized out>, argv=<optimized out>) at dumpcap.c:3850
(gdb)

Is this enough, or I can do more?

--
WBR, Alex.

Security Level: high/server/workstation/virtualization
 

Hi!

On Sat, Jan 28, 2012 at 01:02:40AM +0200, Alex Efros wrote:
> Is this enough, or I can do more?

Ok, this one is better:

# paxctl -mr /usr/bin/dumpcap
$ gdb dumpcap
(gdb) run
Starting program: /usr/bin/dumpcap
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0xb7658152 in readdir64 () from /lib/libc.so.6
(gdb) bt
#0 0xb7658152 in readdir64 () from /lib/libc.so.6
#1 0xb7756197 in ?? () from /usr/lib/libpcap.so.1
#2 0xb7759d99 in pcap_platform_finddevs () from /usr/lib/libpcap.so.1
#3 0xb775be37 in pcap_findalldevs () from /usr/lib/libpcap.so.1
#4 0xb78e369d in get_interface_list_findalldevs (err=0xbfffe798, err_str=0xbfffe794)
at capture-pcap-util.c:174
#5 0xb78e19c0 in get_interface_list (err=0xbfffe798, err_str=0xbfffe794)
at capture-pcap-util-unix.c:110
#6 0xb78e79d2 in capture_interface_list (err=0xbfffe798, err_str=0xbfffe794) at dumpcap.c:797
#7 0xb78e3345 in capture_opts_trim_iface (capture_opts=0xb78ef060, capture_device=0x0)
at capture_opts.c:770
#8 0xb78e86cd in main (argc=<optimized out>, argv=<optimized out>) at dumpcap.c:3850
(gdb)

--
WBR, Alex.

Security Level: high/server/workstation/virtualization
 

On 28 Jan 2012 at 1:15, Alex Efros wrote:

> $ gdb dumpcap --batch --quiet -ex 'run' -ex 'thread apply all bt full' -ex quit
>
> What's next? Recompile glibc with same CFLAGS/FEATURES and try again?

having debug info for glibc won't hurt for sure ;).

> Program received signal SIGSEGV, Segmentation fault.
> 0xb75fd152 in readdir64 () from /lib/libc.so.6

x/16i $pc
x/16x $sp

and based on the disasm i'll need more info later.