grsecurity forums

Dear,

I've enjoyed studying and getting to know grsec thus far.

While checking pax flags present on binaries in this system i've noticed pleny are

RANDEXEC is disabled
EMUTRAMP is disabled

I wonder if this is required for any reason as the logic does not seem apparent for all binaries involved. I'm afraid because i do not 100% grasp pax flags and their impact I'm wearing adamantium armor where steel armor would do.

As a matter of policy i wanted to have as little of pax flags disabled on this system as possible, especially on binaries/services which are to come in contact with the outside world.

/usr/bin/tshark is such an example which required MPROTECT to be disabled to work well. I'm not sure i want this and see but the option of a) requiring authentication to run tshark b) use a binary not requiring any pax flag set to disabled.

Please advise on this topic.

Best Regards,

J.L.

RANDEXEC is an obsolete feature that was removed many years ago, the proper solution is to use PIE binaries instead. EMUTRAMP is not as much a security feature per se but a special case to let some apps run with MPROTECT enabled if they only run specific runtime generated code (ffi and gcc nested function trampolines). as for tshark, can you post the PaX kill log from dmesg? it may be that it falls under EMUTRAMP and you could keep MPROTECT on it then (or just try it out ).

Many thanks for the quick response.

Reset of flags ( paxctl -z /usr/bin/tshark was used ) resulted in

paxctl -v /usr/bin/tshark
PaX control v0.7
Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team <pageexec@freemail.hu>

- PaX flags: -------x---- [/usr/bin/tshark]
RANDEXEC is disabled

~# tshark
tshark: error while loading shared libraries: cannot make segment writable for relocation: Permission denied

[Wed Dec 3 14:16:45 2014] grsec: From 19.22.9.92: denied RWX mprotect of /usr/bin/tshark by /usr/bin/tshark[tshark:2446] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:2436] uid/euid:0/0 gid/egid:0/0

as it was before

# hardening-check /usr/bin/tshark
/usr/bin/tshark:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yes

it seems that you have text relocations in a library probably, strace tshark and you'll see which one it is.

edit: or it can be tshark itself, in that case it may have been compiled as a PIE improperly. how did you build it? is it some distro binary?

Sorry, you lost me there. The ip in the formentioned mail is not my real ip by the way, it seemed to point to Ford Corporation

EDIT This is ran from plain Debian Wheezy.

EDIT strace /usr/bin/tshark output removed since it did not seem to provide much useful output related to this particular issue.

ok, so it seems to be the main executable that has textrels which is a small wonder itself as the amd64 ELF ABI doesn't allow such a thing to exist.

edit: so it's debian's binary, you should let them know that something's gone really wrong with this PIE binary (and probably others too).

I can offer the output of readelf -a /usr/bin/tshark if this would help.

In case this matters, since this is a test-system i've ran paxctl -c for /bin /sbin /usr/bin /usr/sbin
Since my last post i've ran paxctl -z for /bin /sbin /usr/bin /usr/sbin

i took a quick look at the binary, there's just one problematic relocation entry in .rodata, the symbol lt__PROGRAM__LTX_preloaded_symbols. no idea where it comes from but it seems like a build artifact that the debian folks should look into and fix (get rid of).

* Debian Wheezy
readelf -h /usr/bin/tshark
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x10ec0
Start of program headers: 64 (bytes into file)
Start of section headers: 270704 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 9
Size of section headers: 64 (bytes)
Number of section headers: 29
Section header string table index: 28

readelf -r /usr/bin/tshark | grep section
Relocation section '.rela.dyn' at offset 0x8758 contains 346 entries:
Relocation section '.rela.plt' at offset 0xa7c8 contains 346 entries:
000000241340 002d00000007 R_X86_64_JUMP_SLO 0000000000000000 cleanup_dissection + 0
000000241518 007700000007 R_X86_64_JUMP_SLO 0000000000000000 init_dissection + 0

* Ubuntu LTS 14.04

readelf -h /usr/bin/tshark
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x40c1aa
Start of program headers: 64 (bytes into file)
Start of section headers: 257232 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 9
Size of section headers: 64 (bytes)
Number of section headers: 28
Section header string table index: 27

readelf -r /usr/bin/tshark | grep section
Relocation section '.rela.dyn' at offset 0x5048 contains 69 entries:
Relocation section '.rela.plt' at offset 0x56c0 contains 360 entries:
00000063e138 002200000007 R_X86_64_JUMP_SLO 0000000000000000 cleanup_dissection + 0
00000063e318 005e00000007 R_X86_64_JUMP_SLO 0000000000000000 init_dissection + 0

PaX Team wrote:i took a quick look at the binary, there's just one problematic relocation entry in .rodata, the symbol lt__PROGRAM__LTX_preloaded_symbols. no idea where it comes from but it seems like a build artifact that the debian folks should look into and fix (get rid of).

Thanks for that. In a way to me it proves the policy rule i assumed would prove beneficial has already proven to be of interest for future evaluation and study. Would you mind posting your educated findings to the Debian package maintainer: balint@balintreczey.hu ?

https://packages.debian.org/wheezy/tshark

[ EDIT ] I've removed tshark and installed tcpdump which does not require any pax flags to be set and has full hardening-flags set.

jlambrecht wrote:In case this matters, since this is a test-system i've ran paxctl -c for /bin /sbin /usr/bin /usr/sbin
Since my last post i've ran paxctl -z for /bin /sbin /usr/bin /usr/sbin

please read the man page, those two options are not equivalent, you most probably don't want -z per se.

Sorry to keep on going, this is replicable.

vim.nox does not start anymore, throws

Tcl_InitNotifier: unable to start notifier thread
Aborted

Code: Select all

apt-get remove vim-nox
apt-get install vim-nox

vim.nox starts as expected

Code: Select all

paxctl -c /usr/bin/vim.nox

vim.nox does not start anymore, throws

Tcl_InitNotifier: unable to start notifier thread
Aborted

Code: Select all

paxctl -m /usr/bin/vim.nox

vim.nox starts as expected

jlambrecht wrote:Would you mind posting your educated findings to the Debian package maintainer: balint@balintreczey.hu ?

sorry, i don't have time for this, nor am i a debian user, so it'd be much more burden on me than it is on you, the lucky finder .

PaX Team wrote:

jlambrecht wrote:Would you mind posting your educated findings to the Debian package maintainer: balint@balintreczey.hu ?

sorry, i don't have time for this, nor am i a debian user, so it'd be much more burden on me than it is on you, the lucky finder .

oh well, i'll give it a shot

an update

The good news is the package maintainer recognizes there's an issue with tshark on Debian Wheezy. But, he reasons, since it is patched in Debian Jessie he will not make an effort to update the package in Debian Wheezy. Stuff like this makes me moan.