>>>> 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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
