1) This is really way off topic.
2) The best, most funny, situation occurs in the very situation that the
BOFH is trying to achieve: when there are no core files. A mass deletion
as the result of a previously successful run is, well, sublime. No need to
roast anybody, just give them enough rope to do their own job.
Have a nice day.
--
------------------------------------------
boo@stilyagin.com
PGP Public Key available at
http://zloy.stilyagin.com/~boo/pgp-pub.txt
------------------------------------------
On Mon, 26 Oct 1998, Khimenko Victor wrote:
> Date: Mon, 26 Oct 1998 05:39:03 +0300 (MSK)
> From: Khimenko Victor <khim@sch57.msk.ru>
> To: mhw@wittsend.com
> Cc: rhw@bigfoot.com,
mjeffery@cse.ogi.edu,
linux-kernel@vger.rutgers.edu
> Subject: Re: Directory name problem...
>
> In <199810260025.TAA13771@alcove.wittsend.com> Michael H. Warfield (mhw@wittsend.com) wrote:
> MW> Khimenko Victor enscribed thusly:
> >> 25-Oct-98 20:01 you wrote:
> >> > Hi Michael.
>
> >> >>> % 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/
>
-
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/