grsecurity forums

i just re-ran the paxtest and now it says the following have no randomization:

Code: Select all

Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (ET_DYN)         : No randomisation
Main executable randomisation (ET_EXEC)  : No randomisation

All I did was - remove some network stuff that i didn't need & put some into the kernel not as a module - and removed under PAX was Legacy Elf Marking & Elf Header Marking & added chroot protection - Elf Header marking says the following(snippet):

Code: Select all

 
Enabling this option will allow you to control PaX features on                                                                                     â”‚
  │ a per executable basis via the 'paxctl' utility available at                                                                                       â”‚
  │ http://pax.grsecurity.net/.


All the rest are the same and I get the above no randomization on heap, etc.. Oh! I also added the extra /proc security and allow only the users to see their own processes, etc.. when I enabled that I also enabled additional restrictions.

Besides the above I didn't enable/disable anything else. Could this be a problem with paxtest not showing the right output or what?

edit: oh and I disabled fair group scheduler.

edit2: I forgot some stuiff I also did: disabled Kernel support for a.out and ECOFF binaries, & something I seem to can't find now- I set a 32 stack something to 25. Now I believe that's all I did.

edit3: the 25 thing was CONFIG_NET_EMATCH_STACK=25 so it was a network/internet thing.

edit4: I disabled the elf flags options to increase security a bit as I didn't use mprotect, etc..but mostly I did not want to control pax stuff via the utilities.

"and removed under PAX was Legacy Elf Marking & Elf Header Marking"

was the problem. If you disable those, PaX doesn't get enabled on anything. In the more recent grsec patches actually I force the compiler to error out if it detects an improper PaX configuration like the one you used (so the people that don't verify with paxtest aren't caught by surprise).

-Brad

nowshining wrote:edit4: I disabled the elf flags options to increase security a bit as I didn't use mprotect, etc..but mostly I did not want to control pax stuff via the utilities.

paxtest relies on the presence of either PaX flag marking method, it has no knowledge of MAC control (i.e., if you want to get valid paxtest results, you'll have to add proper policies for the paxtest binaries yourself). also as spender said, without any control method (ELF markings or MAC policy) PaX won't engage.

thanks - u know I ran paxtest on my 2.6.24.7 without paxtest and it said the same, alas I only got errored out when enabling segexec or whatever without those two options, however only when I did that - i didn't get errored out when enabling randomization, etc.. in PAX only without at least the elf flags and segexec, etc..

So why does it allow one to set randomization and it compiles fine?

Example: in Security-Pax - mark non-executable pages & in pax control - don't mark an elf flag = compiling the kernel to error out.

Now: Don't mark non-executable pages in pax control but mark randomization, etc.. & don't mark the elf flags = kernel compiles fine.

So My question is this to make sure I get it: So unless I enabled the elf flags even tho i don't use segexec, etc.. Pax incl. randomization, etc.. won't work at all for at least the ones I posted? if so I'll re-compile the kernel with the elf flags re-enabled even tho this is forcement and it could do without which is called bloat. :/ Thanks for clearing this up for me: oh and a paxtest of the non 2.6.24.7 kernel I took while switching to the grsec one shows the following with libsafe:

Code: Select all

 
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux botnetgodalphamale 2.6.24.7-botnetgodalphamale #1 Wed Jun 11 20:59:41 PDT 2008 i686 GNU/Linux

Executable anonymous mapping             : Vulnerable
Executable bss                           : Vulnerable
Executable data                          : Vulnerable
Executable heap                          : Vulnerable
Executable stack                         : Vulnerable
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect)              : Vulnerable
Anonymous mapping randomisation test     : 9 bits (guessed)
Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (ET_DYN)         : No randomisation
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 10 bits (guessed)
Shared library randomisation test        : 8 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)
Return to function (strcpy)              : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc1.
    uid=0  euid=0  pid=8388
Call stack:
    0xb7f86871   /lib/libsafe.so.2.0.16
    0xb7f8697a   /lib/libsafe.so.2.0.16
    0x8048805   /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc1
    0x80489d1   /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc1
    0x48c6a04b   /lib/libc-2.6.1.so
Overflow caused by strcpy()
Killed
Return to function (strcpy, RANDEXEC)    : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc1x.
    uid=0  euid=0  pid=8391
Call stack:
    0xb7f1a871   /lib/libsafe.so.2.0.16
    0xb7f1a97a   /lib/libsafe.so.2.0.16
    0x80489c5   /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc1x
    0x8048971   /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc1x
    0x48c6a04b   /lib/libc-2.6.1.so
Overflow caused by strcpy()
Killed
Return to function (memcpy)              : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc2.
    uid=0  euid=0  pid=8394
Call stack:
Overflow caused by memcpy()
Killed
Return to function (memcpy, RANDEXEC)    : Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc2x.
    uid=0  euid=0  pid=8397
Call stack:
    0xb7f7a871   /lib/libsafe.so.2.0.16
    0xb7f7ac5d   /lib/libsafe.so.2.0.16
    0x804892c   /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc2x
    0x80488e1   /home/nowshining/Desktop/paxtest-0.9.7-pre4/rettofunc2x
    0x48c6a04b   /lib/libc-2.6.1.so
Overflow caused by memcpy()
Killed
Executable shared library bss            : Vulnerable
Executable shared library data           : Killed
Writable text segments                   : Vulnerable


I'm uploading a new patch now which handles erroring in the second case you listed. As we mentioned, disabling those two marking mechanisms effectively disables the userland randomization and segmexec/pageexec functionality. Enabling them maybe adds a few hundred bytes to your kernel -- nothing that can be considered bloat (especially as its usage is essential).

-Brad

spender wrote:I'm uploading a new patch now which handles erroring in the second case you listed. As we mentioned, disabling those two marking mechanisms effectively disables the userland randomization and segmexec/pageexec functionality. Enabling them maybe adds a few hundred bytes to your kernel -- nothing that can be considered bloat (especially as its usage is essential).

-Brad

lol. thanks - at least others will know. I always thought those two were just incase u wanted to fix issues with mprotect and segexec, etc.. with your utilities on the pax site. Again thanks for adding a fix to the patch for what I went thru so others don't have to go thru it.

nowshining wrote:lol. thanks - at least others will know. I always thought those two were just incase u wanted to fix issues with mprotect and segexec, etc.. with your utilities on the pax site. Again thanks for adding a fix to the patch for what I went thru so others don't have to go thru it.

others don't go through this because they actually read the kernel .config help which says among others:

config PAX_EI_PAX
If you have applications not marked by the PT_PAX_FLAGS ELF
program header then you MUST enable this option otherwise they
will not get any protection.

config PAX_PT_PAX_FLAGS
If you have applications not marked by the PT_PAX_FLAGS ELF
program header then you MUST enable the EI_PAX marking support
otherwise they will not get any protection.

i.e., if you don't enable either, then (as far as PaX is concerned) nothing will get the PaX features enabled. if you use PaX integrated with a MAC system such as grsecurity then you can get away without any marking support but then it's up to you write proper policies that enable PaX features as needed (and as i mentioned above, paxtest doesn't come with such policies so unless you write them, you can't use the results to test your system).

PaX Team wrote:

nowshining wrote:lol. thanks - at least others will know. I always thought those two were just incase u wanted to fix issues with mprotect and segexec, etc.. with your utilities on the pax site. Again thanks for adding a fix to the patch for what I went thru so others don't have to go thru it.

others don't go through this because they actually read the kernel .config help which says among others:

config PAX_EI_PAX
If you have applications not marked by the PT_PAX_FLAGS ELF
program header then you MUST enable this option otherwise they
will not get any protection.

config PAX_PT_PAX_FLAGS
If you have applications not marked by the PT_PAX_FLAGS ELF
program header then you MUST enable the EI_PAX marking support
otherwise they will not get any protection.

i.e., if you don't enable either, then (as far as PaX is concerned) nothing will get the PaX features enabled. if you use PaX integrated with a MAC system such as grsecurity then you can get away without any marking support but then it's up to you write proper policies that enable PaX features as needed (and as i mentioned above, paxtest doesn't come with such policies so unless you write them, you can't use the results to test your system).

as for read the configs - i didn''t really uderstand it - i read that over and over, but it also says APPLICATIONS not RANDOMIZATION about the heap, etc.. ie: Heap in an operating system is not an application but is apart of the memory right? Also it again it talks about protecting more like mprotect and segexec and marking the utilities for protection from your pax site and if you don't enable it and or them it won't help protect the applications to an extent if you don't mark them. ie: if you use mprotect and segexec but need to mark them with one of ur pax utilities to work, ie: xfree86, wine, etc..

Again i'm not talking about apps here, but Randomization of HEAP, etc.. Alas that's why I didn't enable it 'cause at least right now, i didn't want to go thru all the binaries and marking them with the pax utility, etc.. to get them to play nice of which i'd have to learn what to mark, 'cause I've never don't it before, but my guess is that they would of been in /usr/bin...

So at last so I didn't enable segexec and mprotect and since HEAP is in memory, etc.. and not an APP I decided NOT to enable them. If they are so important to making Pax work, then why the hell in the first place offer them as options?

You could always change the help to say something to effect of - "if you don't enable these the PAX, randomization and all will refuse to work to protect your system" or "these can't be disabed 'cause without them PAX will refuse to work."

recap: As far as I read it again and concerned I didn't need those since I had no intention of using mprotect and segexec, but wanted randomization of the parts of memory offered, along with freeing the page (i think it was page), etc.. So that's why i when i saw mprotect in the paxtest - i knew what they were for and what I disabled so i knew why they said vulnerable, then i asked on this forum - finally it became clear about the others need mprotect, segexec, etc.. so then I knew why they were vulnerable.

Unless i'm of course wrong about heap being apart of the OS memory and it's actually an app. or what heap even is??

nowshining wrote:as for read the configs - i didn''t really uderstand it - i read that over and over, but it also says APPLICATIONS not RANDOMIZATION about the heap, etc.. ie: Heap in an operating system is not an application but is apart of the memory right?

well, i see you're a bit confused, and although this forum isn't unix 101, let me quickly explain a few terms. an application is just a few files on your disk, passive in nature until you execute the 'main' executable. at that point the kernel creates something called a 'process', which is a collection of various resources allocated to the running instance of the application. one such resource is the 'virtual address space' that ensures that different processes don't trample on each other's data due to hardware enforcement (separation) of memory assigned to the processes. you can look at the address space layout of a given process in /proc/<pid>/maps for example, it lists all the libraries, heap/stack, etc mapped into the address space (remember that each process has its own address space, therefore even though you can see the same virtual address ranges used by different processes, due to the virtualization of memory, they actually access different physical memory underneath).

where PaX comes into the picture is that it tweaks how this address space is populated. one feature set (NOEXEC) ensures that certain constraints are observed regarding the access rights of memory regions, another feature set (ASLR) ensures that addresses themselves get randomized. since there exist applications that weren't writtent with such tweaks in mind, sometimes you need to be able to disable these tweaks, hence the need for controlling the PaX features on a per process basis. since PaX itself doesn't deal with file system access control (something that grsecurity's RBAC system provides however), it has to get these control flags somewhere else, the most practical way is to get them from the above mentioned 'main' executable itself. due to historical reasons there're two methods for this, the older one being obsolete but still supported since the newer one requires a patched binutils or manipulating all ELF headers in the system (paxctl -C).