List:General Discussion« Previous MessageNext Message »
From:Govinda Date:May 14 2012 2:33pm
Subject:Re: MySQL Community Server 5.1.63 has been released
View as plain text  
>>>>  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.



> Not, it seems. Must've been some pretty ugly critters, to get the silent treatment.



Thanks for at least saying this ^^^ .  I was wondering too what was the nature of those
vulnerabilities.


Which reminds me...  and maybe I am asking something obvious to others (?) -

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. (?)

1.) Is anyone *who knows what he is doing* still using mysql_real_escape_string()?  Ever?

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?

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?

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.

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.

Thanks,
-Govinda
Thread
MySQL Community Server 5.1.63 has been releasedSunanda Menon7 May
  • Re: MySQL Community Server 5.1.63 has been releasedBaron Schwartz7 May
    • Re: MySQL Community Server 5.1.63 has been releasedJohan De Meersman8 May
      • Re: MySQL Community Server 5.1.63 has been releasedJohan De Meersman14 May
        • Re: MySQL Community Server 5.1.63 has been releasedGovinda14 May
          • Re: MySQL Community Server 5.1.63 has been releasedJohan De Meersman14 May
            • Re: MySQL Community Server 5.1.63 has been releasedReindl Harald14 May
              • Re: MySQL Community Server 5.1.63 has been releasedJohan De Meersman14 May
                • RE: MySQL Community Server 5.1.63 has been releasedRick James14 May
          • RE: MySQL Community Server 5.1.63 has been releasedRick James14 May