|
|
| Author |
Message |
| 22 new of 80 responses total. |
drew
|
|
response 59 of 80:
| 
Aug 26 19:15 UTC 1999 |
You start out with a deeply nested directory, like /a/u/s/user.
Recursively nested - that would be like having a symbolic link to a few levels
up? I guess there's no harm in it, unless you run something that recursively
follows all subdirectories and treats links as actual directories.
|
mdw
|
|
response 60 of 80:
|
Aug 26 19:53 UTC 1999 |
/a/u/s/user is only 4 levels down, which hardly qualifies as deeply
nested. I have pathnames at work like
/afs/umich.edu/group/itd/build/mdw/krb5.cast/krb5/src/lib/crypto/des/afsstring2k
ey.c and even that's not too hairy; it does fit on one line, and is only 13
levels deep, at least. The directories created by the last vandal were over
3000 levels deep, and this was deep enough to cause problems for the "SYSAUDIT"
feature which we had inadvertently built into the grex kernel; this feature
collects path name information for C2 security logging purposes, and apparently
the feature didn't like pathnames over 64k in size. It seems, in some
respects, we operate in a more hostile environment than the pentagon.
|
don
|
|
response 61 of 80:
|
Aug 26 19:57 UTC 1999 |
Why dontya just modify the sysaudit program to spit out a message into the
sys log when there's a huge directory and skip it?
|
mdw
|
|
response 62 of 80:
|
Aug 26 20:07 UTC 1999 |
Because it's not a program, we don't have source to it, we don't need
it, and taking it out is effectively the same as having it skip every
directory.
|
steve
|
|
response 63 of 80:
|
Aug 26 22:47 UTC 1999 |
Actually, taking it out was a win. IN talking with someone at MSU today
who has dealt with C2 security stuff on SunOS, his comment was along the
lines that we ought to have crashed into C2 weirdness before now. So just
getting rid of it was a win.
|
mcnally
|
|
response 64 of 80:
|
Aug 27 01:17 UTC 1999 |
I get cognitive dissonance when someone talks about crash-preventing
measures as a "Win".. Too much Microsoft influence, I guess..
|
steve
|
|
response 65 of 80:
|
Aug 27 03:26 UTC 1999 |
Mike, when you administer a system like Grex, anything you can do to
stop the vandal from doing things is a "win". It's just one more item
that they can't use to hurt you. Now, granted this is similar to the
Microsoft style of software creation, but in Grex's case I think its
pretty reasonable.
|
scg
|
|
response 66 of 80:
|
Aug 27 03:37 UTC 1999 |
I think Mike was making a pun. Win as in Windows.
|
jazz
|
|
response 67 of 80:
|
Aug 27 12:10 UTC 1999 |
Heh.
Recursive-directory spam seems to be of the sort of low-brow attempted
hacking that'd be stopped with a few changes to mkdir.
|
steve
|
|
response 68 of 80:
|
Aug 27 14:05 UTC 1999 |
The changes need to be in the kernel, not mkdir. A vandal could
circumvent a protected mkdir program by simply calling mkdir in some
code. It can be done in the kernel, but it isn't a trivial task.
|
jazz
|
|
response 69 of 80:
|
Aug 27 15:18 UTC 1999 |
To truly prevent it, yes. I'm just saying that that sort of exploit
is in most cases used by someone who wouldn't *think* nor have the resources
to write even a simple chdir() mkdir() recursive program. Come to think of
it, most programmers I know aren't capable of really recursive programming,
heh. :P
|
mdw
|
|
response 70 of 80:
|
Aug 27 23:01 UTC 1999 |
This particular vandal used a perl script.
|
steve
|
|
response 71 of 80:
|
Aug 28 06:03 UTC 1999 |
At least 50% of the recursive dir bombs have been C code. The nastyist
one creates random strings of files and dirs, then dives another level
deep and starts over again.
Changing mkdir itself isn't worth it.
|
janc
|
|
response 72 of 80:
|
Aug 28 18:11 UTC 1999 |
Yup, most of the people who are stupid enough to want to do something
like this aren't smart enough to write even a shell script - they use
programs written by other people that they found on the web. Half of
them barely know what the programs they run do - except that it is
somethink K00l and hackerish. The programs themselves aren't typically
very good either, since they were mostly written by people who just
barely knew what they were doing, but they are very diverse. Building
good defenses against them is non-trivial. We finally have good
defenses against fork bombs, at least.
|
jazz
|
|
response 73 of 80:
|
Aug 29 11:37 UTC 1999 |
If there's something running around the script kids that does mkdir()
calls, then I retract my statement. I haven't seen one on any of the ususal
suspects.
|
flem
|
|
response 74 of 80:
|
Sep 16 16:00 UTC 1999 |
If you were writing a program whose only objective was to make really
deep directories, why would you recurse? I would think looping would
be far more effective.
|
remmers
|
|
response 75 of 80:
|
Sep 16 19:22 UTC 1999 |
By recursing, you can make 'em deep and wide.
|
flem
|
|
response 76 of 80:
|
Sep 17 13:50 UTC 1999 |
How would recursing help to make them wide? Are you assuming that the
recursion is finite? I mean, if you have something like (ignoring the
finer points of syntax)
foo()
{
mkdir("something");
chdir("something");
foo();
/* never reached */
mkdir("something else");
chdir(something else");
foo();
chdir("..");
}
you still won't get a tree-like expansion, you'll get a single line of
deeper and deeper nested children, one for each recursion, until
someone kills the program. So how would you use recursion to make 'em
wide, too? And why does it matter if they're wide, if the objective is
to fill up a filesystem? Won't deep do it just as well?
Maybe this question should be taken elsewhere? :)
|
drew
|
|
response 77 of 80:
|
Sep 17 20:08 UTC 1999 |
You need to spawn() or something like that, to get wide. And do it more than
once in each instance of the program. Deep gets you a linear growth, while
wide gets you an exponential expansion.
|
mdw
|
|
response 78 of 80:
|
Sep 17 21:49 UTC 1999 |
It doesn't really matter. We have a nice tool that digs through and
gets them all no matter if they're wide or deep. Usually, I think these
people are trying to create something that's deep and "annoying" (weird
filenames); probably they're hoping to core dump things like "find",
"restore", and "rm -rf". Filling up the filesystem appears to be of
2ndary interest to the vandals that make deeply nested directories.
|
don
|
|
response 79 of 80:
|
Sep 19 23:54 UTC 1999 |
Here's how I think they do it (ignoring syntax):
foo()
for (n=1,n<1000/*Or something equally large*/,n++)
{
mkdir("%d",n);
chdir("%d",n);
spawn(foo.c);
chdir("..");
}
This would create a tree with 1000 branches at each level, and infinitely deep
(ie, until stopped by staff or some sort of filesystem limitation).
At least, this is how I'd do it.
|
janc
|
|
response 80 of 80:
|
Sep 20 00:39 UTC 1999 |
Yup, except on Grex it would probably create maybe 50 directories before
all your processes, including your login shell, suddenly and
mysteriously died. These days our fork bomb defenses are very
effective, and that little program is a fork bomb.
|
