Re: Back To The Future: Unix Wildcards Gone Wild

[Nick Lindridge <nick () ioncube com>]

On 28/06/2014 11:26, steel-wing () att net wrote:
> Unfortunately, this analysis is just as flawed as defencecode's.
> Programs like 'rm' are even less "to blame" for this than the shell.
> As to the proposed solution:
> What you are suggesting is to have rm attempt to match every
> option passed to it against every file single before said file
> is to be removed. Correct?

The approach is simpler than that. Recognising that passed options could 
be the result
of expansion, rm could see whether any file or directory names match a 
pattern that would
look like an option if they appeared on the command line and require an 
override in
this case; in effect, directory entry sanitisation. It would not be 
concerned about whether
unexpected options are safe or not, or even whether they are valid 
options at all. This could work
very nicely, be provided as a standard library routine, and is not 
flawed in principle.
A wrinkle is in the recursive case, as unless there is a full scan 
before delete,
it will not be possible to know whether there are option looking 
filenames before some
file have already been deleted, which could be undesirable. An option to 
do recursive
sanitisation could solve that.

Of course, defensive programming can avoid issues, such as never using 
wildcards with rm or
disabling wildcard expansions, and one could take the view that if a 
user doesn't take
such precautions then they are "asking for it". Unfortunately, even 
clued up users will at times,
or perhaps habitually, fall short of best practice though, and 
application designers can help mitigate
disaster by thoughtful design and moderate protections for the end user. 
> From a purist standpoint
whether "rm" *should* have such protection is debatable, but perhaps it 
should on the Unix
distributions intended for beginners.

Nick


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