From: Rick James
Date: May 14 2012 8:35pm
Subject: RE: MySQL Community Server 5.1.63 has been released
List-Archive: http://lists.mysql.com/mysql/227436
Message-Id: <2E7DD7ADE53B044C8C8BCD9C5829E1EB1485F37252@SP2-EX07VS01.ds.corp.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What you do recommend in place of mysql_real_escape_string()?=20

> -----Original Message-----
> From: Govinda [mailto:govinda.webdnatalk@stripped]
> Sent: Monday, May 14, 2012 7:34 AM
> To: Johan De Meersman
> Cc: mysql@stripped
> Subject: Re: MySQL Community Server 5.1.63 has been released
>=20
> >>>>  Bugs Fixed
> >>>>    * Security Fix: Bug #64884 was fixed.
> >>>>    * Security Fix: Bug #59387 was fixed.
> >>>
> >>> Anyone want to elaborate on the nature or severity of the security
> >>> problem? Both are private / inaccessible to me.
> >>
> >> Bug #64884 was apparently also applicable to, and fixed in 5.5.24 -
> >> would be very good to know what the vulnerabilities were, so we know
> >> wether or not they apply to us.
>=20
>=20
>=20
> > Not, it seems. Must've been some pretty ugly critters, to get the
> silent treatment.
>=20
>=20
>=20
> Thanks for at least saying this ^^^ .  I was wondering too what was the
> nature of those vulnerabilities.
>=20
>=20
> Which reminds me...  and maybe I am asking something obvious to others
> (?) -
>=20
> In the PHP circles, as soon as any newbie comes along and shows code
> that makes it evident they are not using prepared statements, or PDO,
> to talk to their MySQL db, then some expert yells at them to do so...
> citing that escaping (i.e. mysql_real_escape_string() ) is "no longer
> valid/secure", etc.  There was a famous talk by a security guy whose
> name I forget (Dan ___ ?) that bashed on the whole concept of
> escaping..  pointing out that now with UTF and code points one never
> knows what characters are going to be represented by escaped input, and
> so escape attempts might miss.  There is that famous example of that
> charset (I forget, was it a Chinese charset?) where
> mysql_real_escape_string() would allow a code point to be represented
> as a single quote (right?  I am not looking in my notes to be sure of
> these details,.. but you guys familiar with all this know very well and
> can correct me?).  Anyway my understanding was that a MySQL patch came
> out to address that.  True?  When security patches come along (like the
> above 5.5.24), I wonder if they might have to do with addressing
> another example of where mysql_real_escape_string() may have failed.
> (?)
>=20
> 1.) Is anyone *who knows what he is doing* still using
> mysql_real_escape_string()?  Ever?
>=20
> 2.) Can anyone get past the rhetoric/buzz and actually point out with
> authority a way to hack (SQL inject) past mysql_real_escape_string()
> with UTF-8 db/table/collation, from a UTF-8 PHP script?  Or is the
> argument against escaping (in the case when using UTF-8) just only
> fear-based?
>=20
> 3.) Do we understand/expect that the MySQL team makes a point (and
> concerted effort) to keep mysql_real_escape_string() current, so that
> in case any new security holes are found, they are patched?  Or have
> even the MySQL devs completely abandoned escaping in favor of prepared
> statements, along with all the buzzy articles and pseudo experts?
>=20
> I am not attached to escaping, just would like to know what is really
> going on behind the scenes, and also I have legacy code that uses
> escaping (and not prepared statements) and I want to get a sense of its
> shelf life.
>=20
> More than anything I would like to just shed light on this topic from
> those who KNOW.  I have read a lot of rhetoric, but not seen much truly
> authoritative writing.
>=20
> Thanks,
> -Govinda
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    http://lists.mysql.com/mysql