>> >>> % Already tried, and he's not interested, but I did find out what script
>> >>> % he's using...
>> >>> %
>> >>> % Q> #!/bin/sh
>> >>> % Q> XYZZY="`find / -name core`"
>> >>> % Q> for LOOP in `find $XYZZY | sort -ru` ; do
>> >>> % Q> rm -fr $LOOP
>> >>> % Q> done
>> >> You have GOT to be kidding me!?!?!
>> > Crazy as it sounds, nope...
>> >> Oh beautiful! How about this instead... If you know the name
>> >> of the script (say /usr/local/stupid_BOFH_admin/rmcore) then use this
>> >> instead:
>> >> mkdir -p "BOFH /usr/local/stupid_BOFH_admin/rmcore /core"
>> >> Or how about this:
>> >> mkdir -p '"BOFH | chmod 666 /etc/passwd" /core'
>> >> Or...
>> >> mkdir -p '"BOFH ; chmod 666 /etc/passwd" /core'
>> >> Watch precise quoting carefully. That make take a little fine
>> >> tuning but you get the point...
>> > How about...
>> Guys, please try to avoid showing your BAD script-writers knowledge when you
>> criticize sripts written by others. Of course this script will allow you to
>> remove [almost] any file in system, but this script WILL NOT ALLOW you to
>> execute command from root. Why ? You are joking ? You are really could not
>> understood ? Ok. Take a look:
MW> I was making a point, not providing a receipe to burn someone. I even
MW> mentioned that it may "take a little fine tuning but you get the point."
It was wrong point IMO.
MW> Apparently you didn't. The point was that this clown did NOT quote
MW> a shell variable expansion.
Yes, it was intentional :-) Otherwise `find $XYZZY | sort -ru` will not work :-)
Unfortunatelly he completely forgot that filenames could include spaces, \t, \n
and other nasty symbols :-((
MW> I intentionally did not point specifically at that and left it to be a
MW> homework excersize.
VERY hard excersize. This script is immune. Of course you could use holes in
bash (like buffer overruns -- I bet he has some ancient version of bash there),
but it's completely other story.
MW> It doesn't MATTER that the exact string I provided wouldn't work.
Of course.
MW> It really wasn't worth the trouble to provide a live fire exploit and
MW> might potentially cause problems.
Yes, I understood this.
MW> What was important was the idea that shell meta characters were not even
MW> being considered in the discussion.
Not considered by script creator that is. Looks so but by some good (bad?) luck
script is immune to shell metacharacters in filenames :-))
MW> Unquoted shell variables are an invitation to disaster.
Yes. If you really want to find all occurences first and then to do some job
with them then you must use 'find -print0' and 'xargs -0' ...
MW> Are you implying that his code is totally immune to shell meta character
MW> exploits?
Yes. If you mean metacharacters in filenames that is.
MW> If you are that serious, I'll let some of my engineers at Internet
MW> Security Systems loose and let them come up with a few LIVE examples
MW> to entertain you.
Uh, oh, ah. If you THAT serius then send me (privately if you do not want to
create troubles from publishing such exploit -- I'll not distribute it)
exploit of THIS SCRIPT (not my bash, my glibc or my perl but exploit of THIS
SCRIPT; that is exploit which is not possible without executing of this script
every hour -- something like mkdir -p "/tmp /dev /core") which will make my
/etc/passwd word-writable.
MW> And I have much MUCH more destructive toys in my arsenal... (How
MW> about hashing his entire partition so you can't even recover the superblock).
I know a lot of such tricks myself and I'm pretty sure that discussed system
still has A LOT OF security holes but what about our small simple stupid
script ?
Yes, this script is immune for shell metacharacters. It's stupid and slow, but
immune for shell metacharacters and thus could not give you root rights :-((
Really. May be "all metacharacters will be hided" was wrong words :-(( More
correct will be "metacharacters from filenames will not be interpreted in this
script". Let's see. Where interpretation of shell metacharacters could occurs ?
-- cut --
XYZZY="`find / -name core`"
-- cut --
here shell metacharacters in filenames will not be interpreted since result of
` ` is not interpreted at all and will be just put in XYZZY "as is" even
without substituting \n as space !
-- cut --
for LOOP in `find $XYZZY | sort -ru` ; do
-- cut --
This is long and complex line but it's immune as well: $XYZZY will take XYZZY
contents, will change \n and \t (only \n and \t! not \r, \h etc. will be
substituted :-) to space and will split XYZZY. No shell metacharacters will be
interpreted. The same with result of `find $XYZZY | sort -ru` ! Result: this
line will not interpret shell metacharacters in filenames as well.
-- cut --
rm -fr $LOOP
-- cut --
Here LOOP contents will be put as rm parameter. Once more no shell
metacharacters will be interpreted. And rm does not have fancy parameters
which could lead to executing something. Removing -- just fine, but excecuting?
Nope...
Of course since result of "`find / -name core`" could be loooong and most
likely there are bash without needed updates it's possible to use buffer
overrun, but it's other story... It's really strange that such stupid script
is immune to shell metacharacters but it's true. Of course possibility to
remove any file (and even the whole filesystem :-) is more then enough by
itself but that's other story as well...
MW> To say that bash hides all the meta characters, is still making a
MW> brash assumption, though. It remains possible, although possibly difficult,
MW> to set up the correct combinations of meta characters and quotes to execute
MW> user arbitrary commands or scripts... It makes for an amusing hobby that
MW> I just happen to get paid to do... :-)
Then why such strange useless point ? If it's your work you must know this stuff
better then I am and may be this is possible after all but I'm really could not
understood how to do this :-(( So far to me looks like this is impossible at
all... Send me exploit if it's possible :-)) I'll not distribute it but I'll
admit you rigthness publically then if you are interested in this...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/