in reply to Re^2: Dangerous diamonds! (races)
in thread Dangerous diamonds!
Classic security exploits often involve race conditions:
How do you suppose user blackhat will manage to predict 1) that a root user will be using pgrep in a blackhat writable directory and 2) exactly when he should create his evil file?
Yes, exploiting race conditions is a classic attack strategy... against processes that run with elevated privileges and which are in some way predictable. Generally, they involve doing something repeatedly in a tight loop, like creating a symlink for instance. Attempting to use this strategy against a human being does not pose a realistic threat.
But mostly I still consider it a very poor tool that will leak file name contents into the execution stream.
I agree that it's a misfeature. This one issue isn't enough to make me call perl² a "poor tool" though.
That something as simple as using "pgrep" as root on files whose names you don't control can run arbitrary code (as root) is a serious security risk that could easily result in security being breached somewhere.
It's true that there is a security risk present here, but that risk is really very small. There aren't even simple criteria by which to determine if any particular system has a security vulnerability due to this behavior. Building on your example, even if pgrep is installed it may be that the root user only uses it responsibly or not at all.
But the huge number of implausible ways that are so easy to come up with convince me that this is a real risk; that someone will figure out a plausible way to use this to "break in" somewhere.
Even if someone figures out how to use this behavior to "'break in' somewhere', their attack will be specific to the system they are violating. If someone were able to write an exploit based on it that would affect any significant number of machines, the chances are that it would already have been done² a dozen times over and they'd all be available on every script-kiddy site on the web. If, on the other hand, a widely distributed perl script is found to misuse two-argument open(), then CERT should issue an advisory or at least a vulnerability note about the guilty script. In fact, there are several of those already. (e.g. VU#453475, VU#181907, VU#671444, etc.)
It is a larger security hole than many items that have been the subject of CERT advisories.
I respectfully disagree. Most CERT advisories address specific vulnerabilities which have well-defined exploits. There have, however, been a few general advisories such as CA-1997-25: Sanitizing User-Supplied Data in CGI Scripts which address a whole class of vulnerabilities. By the way, that one mentions Perl; it says,
"The cause of the problem is not the CGI scripting language (such as Perl and C). Rather, the problem lies in how an individual writes his or her script. In many cases, the author of the script has not sufficiently sanitized user-supplied input."Let's face it though, the threat of an authorized user gaining elevated privileges on a system by seeding a directory with poisoned filenames is not nearly the same risk posed by a web user being able to gain unauthorized access to a system by feeding a CGI script a poisoned query.
I'll say again that I do think there needs to be a change. But let's keep a realistic view of the security implications. There is no cause for a panic inducing advisory. In fact, there is nothing here that should prevent a slow graceful transition from the current default behavior to something sane. That seems to be the direction things are already going. At least we have the 3-arg open() now. I advocate educating people and I agree that there hasn't been enough of that. I'll try to do my part from here on out.
[1] Nor, for that matter would I call the -p or -n switches or the diamond operator "poor tools." They are just tools that require a little more caution... like a band saw or a blow torch.
[2] This "feature" is not new; in fact, it's old. The problem is with two-argument open() not just that perl uses it with <>, -p, and such. Chip wrote about it here in Two-arg open() considered dangerous a year and a half ago. The 3-arg form was only introduced about a year and a half prior to that, iirc, when 5.6 came out. From perl56delta: "This is primarily useful for protecting against unintended magic behavior of the traditional two-argument form."
-sauoq "My two cents aren't worth a dime.";