Re: utf-8 filenames in phar files.

On Tue, Apr 22, 2014 at 11:13 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > On Tue, Apr 22, 2014 at 8:06 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > >> > I have created a quick PR: >> > https://github.com/php/php-src/pull/649 that >> > is fixing the ill-formed UTF-8 paths. >> >> Thanks for the patch. One thing I'd like to understand is what is the >> added value of being so strict in checking UTF-8. I.e. what would happen >> if we allow some path with weird chars in? > > > Although invalid encoding would not be security issues by itselves, > invalid encoding > creates various uncertainties. There are/were many ways to use it to > exploit. > e.g. Old browsers had _many_ security issues with ill-formed strings. > One valid example I can think of right now is filter evasion. > > http://capec.mitre.org/data/definitions/80.html > > Another is DoS. Browsers may refuse to render page at all when there is > ill-formed > strings. e.g. Recent Chrome. Yet another is injections. i.e If user > assumes path name > encoding is UTF-8 and didn't escape, their program could be vulnerable to > injections. > > Other programs are getting better to deal with invalid encodings, but > leaving invalid > encoding relies on other programmer's code for proper/safe operations. > This is not good. > Any external inputs that have certain form must be validated where it is > possible. > This way, we would not leave uncertainties/risks. > BTW, without NFC normalization, I sure there will be unhappy users if users use it with OSX and Linux/Windows. OSX decomposes Unicode and there will be the same name path with different unicode string that appears the same on their terminal/etc on Linux/Windows. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net