Linux-kernel mailing list archive 2000-23,: OS stopping stack buffer overflow exploits

# OS stopping stack buffer overflow exploits

Robert Redelmeier (redelm@ev1.net)
Sat, 03 Jun 2000 21:06:46 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Luke Reeves: "Re: Linux 2.5 / 2.6 TODO (preliminary)"
- Previous message: Ben LaHaise: "Re: Linux 2.5 / 2.6 TODO (preliminary)"
- Next in thread: Theodore Y. Ts'o: "Re: OS stopping stack buffer overflow exploits"
- Reply: Theodore Y. Ts'o: "Re: OS stopping stack buffer overflow exploits"
- Reply: Robert Redelmeier: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Xuan Baldauf: "Re: OS stopping stack buffer overflow exploits"
- Reply: Robert Redelmeier: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Markus Pfeiffer: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"

While thinking about stack buffer overflow exploits (like `bind`),
it occured to me that our beloved OS [Linux] might be able to
provide some security for the many poorly-written suid-root apps.

The key to these exploits is the ability to hijack the thread
of execution by overwriting the return address on the stack.
There are a couple of x86 mechanisms that could be used to
stop the hijack:

1) The limit portion of the processes' CS segment descriptor
could be adjusted downwards, so the stack addresses would not
be executable and attempting would trigger a #GP exception.

2) On syscall entry, the kernel could check the page tables
to be sure that the return address is from code pages (read-only),
and not from data pages (read-write). The kernel would log and
terminate any such process. Kill some nasty bugs this way too.
This assumes an exploit can do limited damage without syscalls.

I believe that even root processes really are running at
Intel Ring3 privilige level. This greatly limits what bare
code can do. AFAIK, only the kernel runs in Ring0.

Of course, either or both of these might break some poorly
behaved applications.

-- Robert

-
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.tux.org/lkml/

- Next message: Luke Reeves: "Re: Linux 2.5 / 2.6 TODO (preliminary)"
- Previous message: Ben LaHaise: "Re: Linux 2.5 / 2.6 TODO (preliminary)"
- Next in thread: Theodore Y. Ts'o: "Re: OS stopping stack buffer overflow exploits"
- Reply: Theodore Y. Ts'o: "Re: OS stopping stack buffer overflow exploits"
- Reply: Robert Redelmeier: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Xuan Baldauf: "Re: OS stopping stack buffer overflow exploits"
- Reply: Robert Redelmeier: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"
- Reply: Markus Pfeiffer: "Re: OS stopping stack buffer overflow exploits"
- Reply: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"