Board index Linux development

Why's the data segment PROT_EXEC set?

Why's the data segment PROT_EXEC set?

Post by Joachim Bar » Mon, 17 Aug 1998 04:00:00



Hello!

  I can't understand why the data segment has PROT_EXEC
set. As confirming to phrack 47 and the usual stack
overflow exploits - I unable to understand why this
was done and not fixed till now.

  A similar problem was discovered in Solaris and it
was turned of in version 2.6 (set in /etc/system). And
in every further version (all 64bit applications) it's
gone...

Bye.
--

Breslauerstr.18     http://prinz.hannover.sgh-net.de/~jbaran
31171 Mahlerten                       Network Administration
Lower Saxony/Germany                         and Programming

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Rob Rya » Mon, 17 Aug 1998 04:00:00



>  I can't understand why the data segment has PROT_EXEC
> set. As confirming to phrack 47 and the usual stack
> overflow exploits - I unable to understand why this
> was done and not fixed till now.

As I understand it from the except of /usr/src/linux/mm/mmap.c below the
x86 hardware doesn't allow execute permission to be denied while
granting either read or write access.

-Rob

/*
 * description of effects of mapping type and prot in current
implementation.
 * this is due to the limited x86 page protection hardware.  The
expected
 * behavior is in parens:
 *
 * map_type     prot
 *              PROT_NONE       PROT_READ       PROT_WRITE      PROT_EXEC
 * MAP_SHARED   r: (no) no      r: (yes) yes    r: (no) yes     r: (no) yes
 *              w: (no) no      w: (no) no      w: (yes) yes    w: (no) no
 *              x: (no) no      x: (no) yes     x: (no) yes     x: (yes) yes
 *              
 * MAP_PRIVATE  r: (no) no      r: (yes) yes    r: (no) yes     r: (no) yes
 *              w: (no) no      w: (no) no      w: (copy) copy  w: (no) no
 *              x: (no) no      x: (no) yes     x: (no) yes     x: (yes) yes
 *
 */

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Joachim Bar » Tue, 18 Aug 1998 04:00:00




>>  I can't understand why the data segment has PROT_EXEC
>> set. As confirming to phrack 47 and the usual stack
>x86 hardware doesn't allow execute permission to be denied while
>granting either read or write access.

  Yes, I also read this, but I couldn't believe it.

  But as far as this is right it seems that it would take
a little bit longer to protect the data segment for
execution... I'll take a further look on it.

MfG,
        Joachim Baran
--

Breslauerstr.18     http://prinz.hannover.sgh-net.de/~jbaran
31171 Mahlerten                       Network Administration
Lower Saxony/Germany                         and Programming

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Rob Rya » Tue, 18 Aug 1998 04:00:00


Section 12.8.1.2 of the Pentium manual says:

Only two types of pages are recognized by the protection mechanism:
1. Read-only access (R/W=0)
2. Read/write access (R/w=1)

Further, I have failed to find any hint of anything which would support
denying execute access without making data access extremely expensive.
(Though it's certainly a complex enough area in the x86s that there may
be some technique to achieve this effect.)

-Rob

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Joachim Bar » Tue, 18 Aug 1998 04:00:00



>Further, I have failed to find any hint of anything which would support
>denying execute access without making data access extremely expensive.

  Yes. I thought a little bit about the known and public
available exploits which give you root access and all of
them use a system call to invoke a shell.
  So what have we learned from this? Obviously we've to
check the segment if a system call is made, probably in
entry.S .
  I think I'll take further investigations in it but I
haven't programmed x86-asm for several years, so I might
get stucked...

Bye.
--

Breslauerstr.18     http://prinz.hannover.sgh-net.de/~jbaran
31171 Mahlerten                       Network Administration
Lower Saxony/Germany                         and Programming

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Kalle Niemital » Wed, 19 Aug 1998 04:00:00



> Further, I have failed to find any hint of anything which would support
> denying execute access without making data access extremely expensive.
> (Though it's certainly a complex enough area in the x86s that there may
> be some technique to achieve this effect.)

I don't know what the memory map of a process looks like under Linux,
but maybe setting the code segment limit could help?  This would not
affect access to data, which uses DS or SS.

Also, there's a stack-noexec patch which prevents execution of code in
the stack.  I don't know what method it uses but maybe it could be
extended to the whole data segment.

Or maybe not.

--

666 MHz getting closer

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Rob Rya » Wed, 19 Aug 1998 04:00:00


Joachim Baran:
Quote:>   Yes. I thought a little bit about the known and public
> available exploits which give you root access and all of
> them use a system call to invoke a shell.
>   So what have we learned from this? Obviously we've to
> check the segment if a system call is made, probably in
> entry.S .
>   I think I'll take further investigations in it but I
> haven't programmed x86-asm for several years, so I might
> get stucked...

This won't help, the problem is that the * code could use the
overrun to run some code to locate the exec system call that has to
exist in libc somewhere, and simply jump to it.  There won't be any
evidence left for the kernel to key off of to see that the exec was
initiated by code in a non PROT_EXEC segment.

And even if that weren't the case, once * code has access to the
data segment of a program really the best you can hope for is security
through obscurity I'm afraid.

-Rob

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Joachim Bar » Thu, 20 Aug 1998 04:00:00



>And even if that weren't the case, once * code has access to the
>data segment of a program really the best you can hope for is security
>through obscurity I'm afraid.

  Well, I guess that no access to the data segment would be
the best access you could give :>, but that's some sort of
immpossible if you want to keep the system running at a
reasonable speed. Hm, but you've already mentioned that...

  What about Intels 'Merced'? Has it the same problem as
it's anchors?

Bye.
--

Breslauerstr.18     http://www.veryComputer.com/~jbaran
31171 Mahlerten                       Network Administration
Lower Saxony/Germany                         and Programming

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Joachim Bar » Fri, 21 Aug 1998 04:00:00



>Also, there's a stack-noexec patch which prevents execution of code in
>the stack.  I don't know what method it uses but maybe it could be
>extended to the whole data segment.

  Where to get it? Can you send it to me?

Bye.
--

Breslauerstr.18     http://prinz.hannover.sgh-net.de/~jbaran
31171 Mahlerten                       Network Administration
Lower Saxony/Germany                         and Programming

 
 
 
Top

Why's the data segment PROT_EXEC set?

Post by Kalle Niemital » Sun, 23 Aug 1998 04:00:00




> >Also, there's a stack-noexec patch which prevents execution of code in
> >the stack.  I don't know what method it uses but maybe it could be
> >extended to the whole data segment.
>   Where to get it? Can you send it to me?

You can get it via www.linuxmama.com; here's a direct link:
ftp://ftp.linuxmama.com/pub/2.0/stack_noexec-symlink-security-fix.bz2

--

666 MHz getting closer

 
 
 
Top

1. ULIMIT - data segment, stack, resident set, etc.

I'm trying to figure out what some ULIMIT options do.  I've learned
generally what most of the stuff is, but some options are still
confusing me.

The -d option sets the maximum data segment size. Now, from what I've
read, all that goes in there (using C programs as an example) would be
the global variables, right? (with a section of it for both
initialized and uninitialized variables) Now, I tried making a program
to test this, which would define a global char [10240]. Then I set
this option to 1 kilobyte, and my program ran fine. (I even had it
read/write to every char in the array, just to make sure nothing
screwy was going on) Shouldn't I get some sort of segmentation
fault/out of memory error?

Next, the -s option, which sets the maximum stack size. I think I have
this one pretty well figured out. In my test program, I defined a char
[10240] in main(), and I did get a segmentation fault when lowering
the maximum stack size below 12 KB. I'm not sure exactly why I needed
more than 11 (the only other thing that I would think would be in
there was my argc, argv, and an int used in main()) but I'm sure an
assembly programmer could tell me why. :)

I've got pretty much no idea what the maximum resident set (-m) option
does. All I can say is that it probably limits the total program's
memory usage. I guess that would include the text, data, and stack
segments? Is there anything else? But when I tried setting it to, say,
1 kb, with no swapfile, my programs would still run. I guess that that
means that if you run out of swapfile, it will use RAM no matter what
the limit is set at?

Finally, the -l option is for "the maximum size that may be locked
into memory." What is that?  :)

2. magellan spacemouse XFree 4.01

3. loading executables into the data segment (poor man's exec)

4. Support for WinTV (ignore the 'Win' bit ;-)

5. Bruce's C Compiler Problem - No Data Segment

6. Apache users

7. addresses of shared objects' data segment

8. Linux Red Hat 6.0 and Solaris 7

9. Why can't I ping outside my segment SCO openserver

10. Why 'data subpacket too long' error?

11. Why can't I record data CD-RW's???

12. Why 'finger' returns old data?

13. why can't I set 'rw' permissions to my msdos partition?


All times are UTC
Board index