Wandering Thoughts archives

Check then use is a dangerous security pattern

A commentator here recently noted the danger of the Unix pattern of stat()'ing a filename, checking to see if the stat results look good, and then open()'ing the file. The problem is that in many cases an attacker can change what the filename is pointing to between the time you stat() it and when you open() it, so that you check a harmless thing but open a dangerous thing.

In thinking about this, I came to realize that this is an example of general security problem pattern: checking something and then using it. If an attacker can figure out how to mutate the thing between your check and your use of it, you have a security vulnerability. You either need atomic 'check and use' operations, or you need to change to a 'capture and check' pattern instead, where you make your checks only after you have captured an immutable reference to the real object you will be working on.

(This also implies that you need some safe way of getting an immutable reference. Unfortunately open() does not quite qualify on most Unixes, because there is no way to tell it to refuse to do opens that would have side effects, such as opening some device files.)

It doesn't matter if you can't see a way to mutate the thing between your check and the actual use. First, attackers have proven they are very ingenious, and second, even if there is no way now, later changes to the overall system may introduce one, because you are ultimately counting on behavior that is not guaranteed.

A more abstract view of the generalized open() issue

Part of the generalized open() problem is that such generalized open()s silently cross what I will call 'security contexts'. Here a security context is both what you can do and where the data is coming from; read versus write versus run a pipe, local files versus remote URLs, and so on.

When something is security sensitive (and open() is here), it should either be explicit about what security context it is operating in, or it should at least be explicit about the fact that it is crossing them. In other words, this is one of the places where you deliberately want to break abstractions, so that there is no possibility of code accidentally operating in the wrong security context.

As a corollary, namespaces that cross security contexts are a danger sign. Firefox has had problems with because its internal files and resources are partly named using URIs in the chrome:// scheme, so lots of things that accept URLs have to be blocked from using them (and sometimes stuff using chrome:// URLs had to be blocked from using other sorts of URLs). And of course there's the great fun to be had because browsers accept 'javascript:' as a scheme in URLs.

(I suspect that these things sneak into languages partly because the language designers did not see them as crossing security boundaries, and in part I think this may be because security boundaries sometimes only become obvious with painful experience. After all, no one deliberately puts security holes in their language or their library.)

Implicit generalized open()'s are dangerous

A number of languages have open() functions that are generalized by default; they open more than plain files, sometimes far more. Such functions are dangerous bear traps lying in wait for the unwary and insufficiently paranoid, because what the programmer thinks is a simple file open may be something very different and more dangerous. In turn, this means that all an attacker needs to do is find some way to supply a 'file name' that your program will try to open.

There's two core problems: the generality is implicit, not explicit, and it is in what you use for a common case that neither needs nor wants the generality. This means that the full potential of what the code can do is not immediately obvious when you read (or write) 'open(filename)', and that you will be writing it a lot. Adding to the problem is that this is a hard mistake to notice. Your code works; it just has extra 'features' that you don't actually want.

(Even if there is a way to be explicit, people are lazy and sooner or later someone is going to use the implicit way when they shouldn't have.)

As you may have gathered, I don't particularly like such open()s; I feel that they are a prime example of an error-prone interface.

I don't like smooth scrolling

Courtesy of upgrading my home machine to Fedora 8 and getting a new version of liferea in the bargain, I have been reminded of something: I really don't like applications that do smooth scrolling.

While I could pick specific nits, I suspect that a good part of this comes down to metaphor choices; I tend to think of scrolling as a 'turn the page' action, for which the closest computer equivalent is just immediately replacing the text with no fancy effects (although I want a line or two of context, which you can't get with physical objects). People with different metaphors probably would find the page turning approach irritating and a good way to lose their context.

(And it's true that my way has a big jump between scrolling a bit, with cursor keys or a scroll wheel or gestures, and scrolling a lot with page down/page up keys.)

Unfortunately, since smooth scrolling by default is so prevalent, I suspect that there are solid human factors reasons for it and thus that I am going to keep running into this. However, I really wish programmers would at least expose an explicit option for this in their programs; not all of us want the slow flickering visual distraction.

Sidebar: my nits with smooth scrolling

There's a number of specific things that bug me about smooth scrolling:

• it at least feels slower (I don't know if it is), and I resent waiting just because the computer wants to show me that it's clever.
• it's visually distracting.
• it unpleasantly reminds me of CRT and LCD screen flickering.
• often, it effectively forces me to defocus my eyes briefly because otherwise I automatically try to read the scrolling text. (This depends on the scroll speed.)

All in all it makes me feel that I'm being forced to wait for a visually distracting effect just so the system can show me that it's clever.