lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 01 Jul 2014 13:24:00 +0100
From: Nick Lindridge <nick@...cube.com>
To: steel-wing@....net, fulldisclosure@...lists.org
Subject: Re: [FD] Back To The Future: Unix Wildcards Gone Wild

On 28/06/2014 11:26, steel-wing@....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/

Powered by blists - more mailing lists