lkml.org 
[lkml]   [1998]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.034 / U:63.748 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site