lkml.org 
[lkml]   [1998]   [Oct]   [26]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 25 Oct 1998 21:31:15 -0700 (MST)
FromDarrin Chandler <>
SubjectRe: Directory name problem...
Before anybody gets too upset about this, remember two things:

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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2008