Re: Debian Server Compromise -- A Fire Drill ??
On Thu, 04 Dec 2003 15:30:31 +0100, Isaac To <kkto@csis.hku.hk> wrote:
>>>>>> "Dave" == Dave <dmq@gci-net.com> writes:
>
> Dave> Seems like the critical link to be fixed is the vulnerability of
> Dave> daemons that run with root privilege and receive input from users.
>
>No. The kernel itself has bug. The "user" (attacker) is running *perfectly
>legitimate* system calls (brk(), the call that will be made when you
>malloc()) from a rather strange but allowed executable file (that have the
>code segment moved to the end of address space). And then, due to the
>kernel bug, the user can write into arbitrary location in the kernel, do
>whatever he wants. So here the problem is the kernel---the ultimate source
>of permission that you have on the computer. If the kernel is buggy, there
>is really little that you can do to be protected from being harmed---except
>of course to have a network of mutually distrusting servers with completely
>different passwords, keys, etc.
Good point. Instead of "daemons", I should have said "daemons (or any
kernel routines)"
It still seems like it should not be difficult isolate the user input, and
force it to flow through a "narrow channel" where we can test it carefully
for excess length, or any other irregularities that might cause a breach of
security. I'm using colorful language here, because I don't understand the
details of how bad input gets read into priveledged code. I just have a
general intuition that it could be "channeled", the way access to
supervisor mode is done in a modern microprocessor.
Instead of a mode where the user can write anything he wants into memory,
imagine an OS that works something like this:
(Again, please excuse my fanciful imagination.)
User: CallService DestroyFileSystem <victim's partition>
OS: Sorry, no such service.
User: CallService 227
OS: Sorry, no such service.
User: CallService 226
226> OpenForWrite <victim's filename>
Sorry, you don't have permission to write to someone else's files.
226> PokeMemory <some address>
Sorry, service 226 has no such command.
226> SaveThisData <very long string>
Sorry, your data exceeds the size of my buffer.
226>
I've shown this as an interaction, but it could be just a single call with
all the parameters. The point I'm trying to make is that the OS has only a
very limited set services offered, and each service has very limited and
carefully checked input it will accept. There is no such thing as a
"buffer overflow" because all raw input goes through some *common routine*
that at leasts checks for maximum length.
So how many daemons and kernel routines need both root access and input
from a user process?
-- Dave
Reply to: