grsecurity forums

hi

i have little problem with ssh client and server: when try to ssh:

ssh2: error while loading shared libraries: libncurses.so.5: cannot enable
executable stack as shared object requires: Permission denied

that is after compiling 2.4.28 with grsec sets to high.

whats the problem ?

horizn wrote:whats the problem ?

the problem is that you haven't searched the board for this error message. it's been discussed extensively.

i cant find solve for my problem !

can you show me how to fix it without recompile kernel with:
http://pax.grsecurity.net/pax-linux-2.4 ... 2350.patch
and
http://pax.grsecurity.net/binutils-2.14 ... 2140.patch

??

why patching 2.4.27 was without any problems after reboot ?

i have slack10 updated to current.

horizn wrote:why patching 2.4.27 was without any problems after reboot ?

i have slack10 updated to current.

maybe you updated your glibc or ncurses in the meantime and got a false positive executable PT_GNU_STACK on libncurses (or maybe it's the lack of it while other libs have PT_GNU_STACK). i can't guess it remotely, you have to look at your system and find out what triggers the executable stack request. make sure you read the relevant threads on the board first.

PaX Team wrote:

horizn wrote:why patching 2.4.27 was without any problems after reboot ?

i have slack10 updated to current.

maybe you updated your glibc or ncurses in the meantime and got a false positive executable PT_GNU_STACK on libncurses (or maybe it's the lack of it while other libs have PT_GNU_STACK). i can't guess it remotely, you have to look at your system and find out what triggers the executable stack request. make sure you read the relevant threads on the board first.

nothing was updated between reboot after compiling 2.4.28, when boot at 2.4.26 (build-in) everything is ok.

# ls -la /var/log/packages/ | grep nc
-rw-r--r-- 1 root root 51834 Nov 30 01:01 ncurses-5.4-i486-2

# ls -la /var/log/packages/ | grep gl
-rw-r--r-- 1 root root 1344 Nov 28 00:57 glib-1.2.10-i386-2
-rw-r--r-- 1 root root 16079 Nov 28 12:51 glib2-2.4.7-i486-1
-rw-r--r-- 1 root root 258925 Nov 28 00:57 glibc-2.3.3-i486-2
-rw-r--r-- 1 root root 172263 Nov 28 00:57 glibc-i18n-2.3.3-noarch-2
-rw-r--r-- 1 root root 1380 Sep 19 13:56 glibc-solibs-2.3.2-i486-6
-rw-r--r-- 1 root root 63528 Sep 19 13:56 glibc-zoneinfo-2.3.2-noarch-6

# ls -la /var/log/packages/ | grep binu
-rw-r--r-- 1 root root 5977 Dec 1 20:19 binutils-2.15.92.0.2-i486-1

horizn wrote:nothing was updated between reboot after compiling 2.4.28, when boot at 2.4.26 (build-in) everything is ok.

what does readelf -l say about libncurses.so.5 ? it probably has no PT_GNU_STACK header or an executable one, in the former case you can recompile it with a recent (3.3+) gcc, in the latter you can use execstack -c on it (at least on my system it doesn't use gcc nested function trampolines, so it's safe to clear this bit).

PaX Team wrote:

horizn wrote:nothing was updated between reboot after compiling 2.4.28, when boot at 2.4.26 (build-in) everything is ok.

what does readelf -l say about libncurses.so.5 ? it probably has no PT_GNU_STACK header or an executable one, in the former case you can recompile it with a recent (3.3+) gcc, in the latter you can use execstack -c on it (at least on my system it doesn't use gcc nested function trampolines, so it's safe to clear this bit).

thanks for your patience, but im not so advanced in programming:

# readelf -l /lib/libncurses.so.5

Elf file type is DYN (Shared object file)
Entry point 0xe2e0
There are 4 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x351d4 0x351d4 R E 0x1000
LOAD 0x0351e0 0x000361e0 0x000361e0 0x07e50 0x0870c RW 0x1000
DYNAMIC 0x03c9e4 0x0003d9e4 0x0003d9e4 0x000d0 0x000d0 RW 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

Section to Segment mapping:
Segment Sections...
00 .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .i
nit .plt .text .fini .rodata
01 .data .eh_frame .dynamic .ctors .dtors .jcr .got .bss
02 .dynamic
03
# execstack -c
bash: execstack: command not found

# ls -la /var/log/packages/ | grep gcc
-rw-r--r-- 1 root root 7414 Nov 28 00:48 gcc-3.3.4-i486-1
-rw-r--r-- 1 root root 8562 Nov 28 00:48 gcc-g++-3.3.4-i486-1
-rw-r--r-- 1 root root 2023 Nov 28 12:53 gcc-g77-3.3.4-i486-1
-rw-r--r-- 1 root root 72430 Nov 28 12:53 gcc-gnat-3.3.4-i486-2
-rw-r--r-- 1 root root 2050 Nov 28 12:53 gcc-objc-3.3.4-i486-1

maybe its problem with packages, so i try to compile gcc from source.

horizn wrote: GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

this RWE is the problem, it should be RW normally. execstack is part of the prelink package.

# ls -la /var/log/packages/ | grep gcc
-rw-r--r-- 1 root root 7414 Nov 28 00:48 gcc-3.3.4-i486-1

maybe its problem with packages, so i try to compile gcc from source.

hmm, that gcc is recent enough, so the executable PT_GNU_STACK on libncurses must be a false positive coming from some other package. you should tell the slackware developers about this (and in general, you/they should sanitize userland for PT_GNU_STACK breakage). alternatively you can make use of the gentoo glibc patch that disables make_stack_executable() in ld.so for good.

Could somebody post a link to that glibc patch?

After rebuilding glibc what other packages would have to be rebuilt? Is there a way to check?

joeyt wrote:Could somebody post a link to that glibc patch?

http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-libs/glibc/files/2.3.4/glibc-2.3.4-dl_execstack-PaX-support.patch

After rebuilding glibc what other packages would have to be rebuilt? Is there a way to check?

it's a patch (well, more like an ugly workaround, but it's about as cheap as it can get without completely disabling PT_GNU_STACK) against the dynamic linker, so nothing else needs an update (at least in theory, lately statically linked glibc can still load dynamic libs for NSS, i don't know how PT_GNU_STACK works in such a case).