Resolution for ver_export()/addslashes() encoding based script execution attack?

Yasuo Ohgaki wrote:

    As you know, all databases' escaping functions have encoding parameter.
    PostgreSQL uses encoding parameter stored in db connection structure. This
    is the reason why pg_escape_string() has optional database base connection
    parameter for escaping.


On the whole any database access I'm doing with Firebird is done using
parameters which are handled in the database connection rather than having
to worry about many of these sorts of 'protections'. The result for me is
that I don't have to worry about many of the problems the more lax handling
of data in MySQL can create. But the more important thing here is that I've
not used a 'locale' other than UTF8 for websites for many years and so the
whole underlying structure needs fixing rather than trying to patch small
areas that are better handled by doing the job correctly in the first place!

We cannot force users to use Unicode for database/file/etc ;)
I'm not proposing use of locale, but new escape API that support multibyte
encoding.

My point Yasuo is that I think the reason this has been rejected is simply
because there needs to be a more comprehensive review of how 'multi_byte'
characters are handled? There needs to be at least some agreement moving forward
if PHP should be made fully UTF-8 complaint or the alternative 'ASCII only' for
code, so that perhaps 'mb_' SHOULD be the only way to handle multi byte strings?
Short term fixes are just exacerbating the real problem? Also I don't see how
the RFC addressed the problem anyway. While I use UTF-8 output exclusively I've
not had to resort to mbstring extension to do so yet so would not even use the
extra functions in normal production.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Hi Stas,

On Sat, Mar 1, 2014 at 3:57 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

PHP supports SJIS and the like. Escape functions should provide safe
escaping like databases. The only way to solve this issue is encoding

You are making global claims which sound plausible on surface, but when
you put them in context, it gets much more complicated. PHP supports
SJIS, yes - just as it supports any other existing encoding. That does
not mean every scenario possible is automatically working or can be made
to work consistently. Specifically, SJIS encoding is not compatible with
ASCII encoding, which means same function with same parameters would not
work, moreover - choosing parameters which would work in every situation
may be quite problematic.

It seems your are trying to solve issue in a way of cannot be solved.

To eliminate encoding based attacks, proper use of encoding is mandatory.
Leaving encoding setting automagic would be cause of issues. Example is use
of locale for deciding encoding in programming language. (Note: use of
locale is not always bad choice. It's good enough for applications in many
cases, but it's bad in programming language in general.)

There are many lessons with databases/browsers in past years. Why not adopt
it for PHP?

aware escape which databases adopted years ago. I'm proposing known
vulnerability with known method to fix.

Encoding-aware inside PHP means different thing than inside the
database. The database has only one encoding within the session and
doesn't have to deal with anything else. PHP has much more to deal with,
especially in scenarios you are proposing - where you are writing out
PHP scripts to be executed later. Your solution assumes one set of
environment settings and will break in another, current solution works
in one set of environment settings and will break in another. So I'm not
sure we'll be making much of an improvement there by switching set of
cases where it will break.

Like database users may have multiple connections at once and should know
what the encoding for each connection, PHP users can use multiple exported
PHP scripts with multiple encodings and PHP users should know what the
correct encoding for a script. There is a way to handle this situation
properly now. declare(encoding='NAME');

What I would like to fix is design bug of encoding support. There should be
encoding aware escape/unescape if various encodings are supported,
otherwise we open hole to attacker.

BTW, users who do not have to worry about this are not affected by
proposed change.

That is not the reason to accept the change. It is a necessary, but not
a sufficient condition for acceptance.

Necessity is clear. There is situation that attackers could execute their
script with PHP supported encoding. This is fatal bug. Counter measure is
also clear. Use of encoding aware function is mandatory. Therefore, all we
have to discuss is "implementation of encoding aware escaping/unescaping
functions".

Please note that it does not matter at all if PHP is going to support UTF-8
as internal character encoding or not. Encoding aware escape/unescape is
mandatory regardless of internal UTF-8 support because this is a issue of
input/output. i.e. If PHP could handle I/O properly or not.

Let's make it simple.

• There is issue (code execution by attacker).
• There is solution (encoding aware escape/unescape).
• There are 2 feasible resolutions (modify existing function or add new
  function)
• Proper implementation may vary. (what we should discuss)

To Pierrie,

I'll post (or create new RFC) to explain details of encoding based attacks.
Knowledge about encoding based attack is mandatory for Unicode support
also.

Any more comments for disclosing attack details at point?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net