[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: