full-disclosure - Re: Possibility to exploit bash "*" processing

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 21 Sep 2011 11:36:32 -0700
From: Andrew Farmer <andfarm@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk, Dan Carpenter <error27@...il.com>
Subject: Re: Possibility to exploit bash "*" processing

On 2011-09-21, at 09:55, Valdis.Kletnieks@...edu wrote:
> On Wed, 21 Sep 2011 16:01:24 +0300, Dan Carpenter said:
>> Seems like a good time to promote David Wheeler's filename proposal:
>> http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
> 
> Unfortunately, David Wheeler's proposal has some implementation issues:
> 
> 1. Forbid/escape ASCII control characters (bytes 1-31 and 127) in filenames,
> including newline, escape, and tab.
> 
> 3. Forbid/escape filenames that aren't a valid UTF-8 encoding.
> 
> The problem is that the UTF-8 codespace consists *mostly* of multibyte
> characters, wherein at least one of the bytes, when considered by itself, is an
> ASCII control character.

Not true - the multibyte sequences in UTF-8 text consist entirely of high-bit characters (0xC2 - 0xF4 initial, 0x80 - 0xBF continuation). All characters below 0x80, including ASCII control characters, are always mapped directly to the corresponding codepoints.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/