Re: [PATCH] [SECURITY] suid procs exec'd with bad 0,1,2 fds

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Wed, 5 Aug 1998 11:39:58 +0200 (MET DST)


>
> Date: Tue, 4 Aug 1998 15:51:50 -0400
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
>
> This is not a technical argument, then, but a social one. This
> doesn't mean that we shouldn't put the stack hack into mainline at
> some point. It just means we have to be careful how we market it,
> and make sure developers still worry about stack overruns.
>
> Also true.
>
> But I have yet another technical argument. It BREAKS the existing elf
> ABI's of all systems I know of.
>
> I have the 32-bit Sparc and 32-bit MIPS ELF specifications here for
> reference and both specify:
>
> "The stack segment has READ, WRITE, and EXECUTE permissions."
>
> I don't have it handy, but I would not be surprised if the x86 ELF
> specs say the same thing. Someone can easily check this.
>
> Dean Gaudet made a reference to Solaris2.7 and the fact that they've
> turned off execute permission for the stack on Sparc. This is for
> 64-bit Sparc binaries covered on the new 64-bit V9 processor ABI.
> They did not turn off execution for the stack segment when existing
> 32-bit binaries run.

BTW: Anyone have an idea why they do it for 64bit binaries? It seems
complete nonsense there. They can achieve the same e.g. by simply designing a
right memory map, for example:

0 nothing
16GB binary
data
heap
|
v
...
^
|
stack (ie. all stack addresses look like 0x000007XXXXXXXXXX)
8TB memory hole
-8TB mmap area (ie. first 4GB of shared libs have addresses
| like 0xfffff800XXXXXXXX)
v
...
end_of_memory

Like that, a buffer overflow will very unlikely succeed to execute any code
on the stack (as i7 would have to include two zeros initially (we're big
endian :)), and as libraries will be mmaped from -8TB onwards, I'm sure the
most common will have addresses like 0xfffff800XXXXXXXX, so even there, one
won't be able to fully control the low 32bits of the return call address).
Not counting that the cracker, unless he'll make changes to frame 7
functions up in the call trace, must ensure the task gets an irq or syscall
just before filling the buffer with the attack string.
So, I'm not telling a overflow attack is impossible in such a memory
configuration, but I think it is totally equal in the amount of difficulty
for a cracker to write a succesful buffer overflow attack.
Of course, 32bit binaries are much weaker in this respect.

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.114 on a sparc64 machine (498.80 BogoMips).
___________________________________________________________________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html