Message-ID: <20140630215541.GA37503@redoubt.spodhuis.org>
Date: Mon, 30 Jun 2014 17:55:42 -0400
From: Phil Pennock <full-disclosure+phil@...dhuis.org>
To: fulldisclosure <fulldisclosure@...lution-hosting.eu>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Back To The Future: Unix Wildcards Gone Wild

On 2014-06-28 at 12:06 +0200, fulldisclosure wrote:
> Am 27.06.2014 01:20, schrieb Julius Kivimäki:
> > Um, this is well documented behavior that's been around for decades. *
> > expands to all files in the dir as arguments to whatever, if the filename
> > is "--no-preserve-root -rf .." why shouldn't that be returned?
> >
> to be honest, bash shouldn't expand * to "file1 file2 file3 -rf..." it
> should do it to "  'file1' 'file2' 'file3' '\-rf'..." instead, with all
> meta chars escaped properly.

How is this expected to help?

In Unix, the backslash escapes are interpreted by the shell, as are any
quotes; programs are not expected to interpret escape sequences to
decode filenames and starting now would introduce new security holes as
systems which are currently correct would not be expecting some tool to
start changing the filename it acts upon when it was given a correctly
formed filename in argv.

Running >> rm -rf foo <<    gives argv=["rm", "-rf", "foo", NULL]
Running >> rm "-rf" foo <<  gives argv=["rm", "-rf", "foo", NULL]
Running >> rm \-rf foo <<   gives argv=["rm", "-rf", "foo", NULL]
Running >> rm "\-rf" foo << gives argv=["rm", "-rf", "foo", NULL]
Running >> rm '\-rf' foo << gives argv=["rm", "\\-rf" (4 chars (plus NUL)), "foo", NULL]

and if the program treats []char{'\\', '-', 'r', 'f', NUL} as anything
other than matching a Unix filename of 4 characters then we're opening a
can of worms as large as the "how do you safely filter HTML of
JavaScript for all browsers" one, if not larger.  The semantics are
well-defined.

Letting applications map attacker-controlled filenames into the
filesystem unchanged is a design flaw; having privileged users leave
$TMPDIR as /tmp or any location another user can write to is a system
flaw; using /tmp is a code smell; if scripting something which has to
handle untrustworthy filenames, especially around "scp" which has its
own issues of portability with filenames with embedded newlines and
figuring out the correct quoting for remote systems, then you need
someone who understands Unix and the shell to vet the script you write
(and if you have humans routinely typing the arguments to such scripts,
you need to improve your process tooling until you don't require this,
because humans make mistakes and leaving the human/machine interface for
specifying options right where attacker-controlled files live is
dangerous; move away from raw invocation of "rm" or "rsync" or anything
else, towards "do_customer_backups" or whatever).

-Phil

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists