Messages in this thread |  | | | Date | Tue, 9 Sep 1997 17:11:20 +0200 (MET DST) | | From | Wolfram Kleff <> | | Subject | Re: /dev/full a security hole? |
| |
H. Peter Anvin wrote: > Consider the code: [code deleted]
I think you miss the access call, without this you can even read /dev/mem...
I think we should be more careful for programs which get setuid, or we get setuid programs which offers /dev/mem ;-).
> "How realistic is this exploit?" is a question that matters to > crackers only. The fact of the matter is that it turns a legitimate, > secure, operation into a security hole. Our job is to plug these > holes *before* crackers find a way to exploit them.
The behavior of /dev/full is known for ages. (At least for me...) And it has (can ?) never been exploited so far. (At least not in public or in underground)
> What is it used for? That would be helpful to know.
Mainly for device performance tests, security tests, and program debugging.
To come to an conclusion: As Rogier Wolff pointed out, what about changing permissions to 622 and we are all happy. (and secure) Therefor we don't need a patch, for example if you give /dev/mem 666 permissions you are lost anyway. So I think we should let the people decide if they would life with this "security bug". (Yes, I'm still not 100% convinced :-)
The 644 permission in RedHat 4.1 is RedHats security problem, and not a security problem inside the kernel. Again, would anybody change the behavior of /dev/mem just because somebody gives 666 permission within a distribution ? I think not.
BTW: There are still real security bugs inside the kernel, e.g. the use of sprintf instead of snprintf. OK, normally you can only crash the kernel (DoS), but I think that is not what we all want. If you really want to secure the kernel, what about correcting these old and real security bugs ?
|  |