lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDisk Destroyer, Cpu Reflashing, Root Security in General
I was reading through the thread started by Andre Hedrick with some serious
doubts. I was under the assumption that there was no real way to destroy any
of the hardware in your computer through the use of software. I figured, well,
the hardware manufacturer would make at least a decent effort to protect its
command interface from putting in values beyond the allowable range to keep it
from self-destructing, and most likely this is what they do.

However, the one point I failed to see is what the manufacturer *allows* you
to do with the component. Now these methods are either undocumented, or the
manufacturer provides binary-only programs to do these tasks. But, the biggest
type of damage you can do to your hardware to render it instantly unusable is
to reflash the firmware on the device with erroneous data.

In this, I agree with Andre that adding protection to the ioctl() commands
will keep the fault of crashing the system out of the kernel (i.e., a kernel
syscall is not the cause of the crash). However, Peter Svensson has come up
with a good point about the use of iopl().

Programs run as root (or hacked setuid-root) can use iopl() to gain ring 0
privledge levels, read the CPUID, or gain unlimited I/O access to all the
devices on your system. A root program therefore does not need the kernel to
make "ioctl" calls anymore--it can make its own destructive commands to the
devices themselves.

Blocking the commands in ioctl() is only half of the solution. For full
security, one must also block iopl(0) from working, and for every [valid]
application out there that needs to use iopl() to communicate with the
device, there must exist a kernel ioctl() or some other syscall that allows
the application to continue working after iopl() was disabled.

Now granted, this is a bit extreme. But this is the only way that you will
be able to protect your system from hardware destruction by software. I've
been working in the field of security for at least three years now, and I've
seen everything from buffer-overrun hacks to attacks by inside employees.
Intrusion detection systems only work to an extent, and they still don't
prevent hackers or even newbies from finding a way around the firewalls to get
inside the system.

I wouldn't even be surprised if the next ILOVEYOU-style virus executes
assembly that reflashes everyone's CPU and DVD firmware, then sends that
email on to the next person in their Friends list. Now that the source code
for CPU updating is available on the net, I wouldn't be surprised if hackers
implement any of its techniques in their attacks for the next couple of years.
It's really a life-saver that the ILOVEYOU virus did only minimal damage,
since it was done during the time when system administrators started letting
down their guard after the Melissa virus attack.

The bottom line is, there is no sense in putting protective measures on
ioctl() unless ioctl() is the ONLY way to get at a device. Until iopl() and
any other possible access points are also secured, the hole is left wide open.

I want to be able to say I can rely on Linux to be an extremely stable and
secure operating system, one that would be able to keep my hardware investment
intact and unreachable from anyone who breaks into my system as Root. I don't
know anyone who disagrees.

--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: bstanoszek@comtime.com


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.059 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site