win32sux

[Log in to get rid of this advertisement]

At this point, there's still too much debate about this vulnerability for me to include it in the Kernel Vulns thread, even though it's now been issued a Bugtraq ID. Presumably, most of you keep an eye on Bugtraq (discussion has taken place on LKML too), so this issue wouldn't be news for you, but being able to discuss it in the comfort of LQ might be nice.

Link to the OP on Bugtraq: http://seclists.org/bugtraq/2009/Oct/179.

anomie

I'm really not invested in the argument one way or the other, but my take is: if you don't want a file to be written to, remove the write bit as appropriate.

That said, I could see how this idea would result in a blackhole of discussion.

H_TeXMeX_H

I agree with Dan Yefimov, this is not a vulnerability, but a user error.

win32sux

What exactly do you consider the user error to be? The assigning of world-writeable permissions to the file? The assumption that the file would be protected regardless by the restrictive permissions of the directory it resides in?

exvor

I found reading about this very interesting even if some of it is lost on me. Its odd why going though proc would bypass security on the file or am I missing something. Can you use other devices other then fd to accomplish this or is this specific to that?

H_TeXMeX_H

Well, the main thing the author of this bug does not understand is that /proc or procfs is actually just a set of hard links, or acts like it.

If you do not set the permissions on a file itself correctly, not the directory above, then you cannot expect that you cannot read it. Also, like Dan says here:
http://seclists.org/bugtraq/2009/Oct/291
what the author describes would not happen if the directory permissions were set correctly upon creation.

I can't say that I fully understand exactly what is going on, but it seems that this is no bug. It is that the user expects something that is not to be expected.

jpaugh

Whether this is actually a security hole--i.e. software behaving differently than specification--or simply a case of the user misunderstanding the specification, I think it should be "fixed," because it is a problem. I think the privilege level of a directory should represent the maximum privilege level of all contained files (and sub-folders). Either that, or creation of a new file should result in that file inheriting the read/write privileges of its parent, so that at least the parent's privileges becomes the default for all of the files within it.

GazL

I agree with H_Tex, it looks like a pretty standard example of a race condition. The guy should lock down the directory THEN create the file.

User error, but perhaps I'm missing something if it's getting as much discussion as it appears to be.