Solaris General - executable data segments?

Author

executable data segments?

Keith Michaels

2004-03-04, 3:34 pm

Why does solaris make all segments executable, including data
segments?

# pmap $$
00010000 584K r-x-- /usr/dt/bin/dtksh
000B0000 56K rwx-- /usr/dt/bin/dtksh
000BE000 104K rwx-- [ heap ]
FEB00000 16K r-x-- /usr/lib/libmp.so.2
FEB14000 8K rwx-- /usr/lib/libmp.so.2
FEB20000 8K rwx-- [ anon ]
....

everything, stack, heap, data, are executable. It would seem
safer to have executable only on code segments to protect against
common buffer overflow exploits.

Casper H.S. Dik

2004-03-05, 4:33 am

krm@sdc.cs.boeing.com (Keith Michaels) writes:

>Why does solaris make all segments executable, including data
>segments?

># pmap $$
>00010000 584K r-x-- /usr/dt/bin/dtksh
>000B0000 56K rwx-- /usr/dt/bin/dtksh
>000BE000 104K rwx-- [ heap ]
>FEB00000 16K r-x-- /usr/lib/libmp.so.2
>FEB14000 8K rwx-- /usr/lib/libmp.so.2
>FEB20000 8K rwx-- [ anon ]
>...

>everything, stack, heap, data, are executable. It would seem
>safer to have executable only on code segments to protect against
>common buffer overflow exploits.

There are two reasons: one is ABI compliance; the second is that
part of the data segment on SPARC is executed; the first part
contains the PLT (procedure linkage table) which is executable
code pointing to all dynamically linked functions.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Jonathan Adams

2004-03-06, 12:33 am

Casper H.S. Dik <Casper.Dik@Sun.COM> wrote in message news:<40484170$0$558$e4fe514c@news.xs4all.nl>...
> krm@sdc.cs.boeing.com (Keith Michaels) writes:
>
>
>
>
>
> There are two reasons: one is ABI compliance; the second is that
> part of the data segment on SPARC is executed; the first part
> contains the PLT (procedure linkage table) which is executable
> code pointing to all dynamically linked functions.

For the stack, at least, there are some options:
1. Solaris comes with a mapfile, /usr/lib/ld/map.noexstk, which
you can link your program with to enforce a non-executable stack.
Most of the core Solaris binaries are linked with it -- for example:

% sleep 10 &
[1] 299000
% pmap 299000
299000: sleep 10
00010000 8K r-x-- /usr/bin/sleep
00022000 8K rwx-- /usr/bin/sleep
....
FF3EC000 8K rwx-- /lib/ld.so.1
FFBFE000 8K rw--- [ stack ]
total 2008K

To use it, just get a '-M /usr/lib/ld/map.noexstk' added to your
link line:

Sun's CC: cc -M/usr/lib/ld/map.noexstk -o foo foo.c
GCC: cc -Xlinker -M/usr/lib/ld/map.noexstk -o foo foo.c

(there are some other mapfiles in /usr/lib/ld which may be of
interest, too)

2. the sparcv9 ABI specifies a non-executable stack, so 64-bit
applications get this for free...

3. you can set noexec_user_stack, to 1 in /etc/system, and it
will make everything have a non-executable stack. This breaks the
sparcv8 ABI, but most things won't have any problems.

- jonathan

Casper H.S. Dik

2004-03-06, 9:33 am

jonathan-ggl@ofb.net (Jonathan Adams) writes:

>Sun's CC: cc -M/usr/lib/ld/map.noexstk -o foo foo.c
>GCC: cc -Xlinker -M/usr/lib/ld/map.noexstk -o foo foo.c

> (there are some other mapfiles in /usr/lib/ld which may be of
>interest, too)

You can also map the BSS non-executable if you want with the following
mapfile:

bss = ?RW;

this, unfortunately, grws your application size because data and bss
are no longer one.

Also, you could try:

data = ?RW;

but that only works on Intel where the "X" bit is ignored anyway[1].

Casper

[1] Until such time that Solaris starts supporting the "NX" bit in the
Opteron CPUs.

--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.