Josh Wieder

Four days ago I received an email from Dawid Golunski through the list illustrating one of the more brutal pair of security vulnerabilities I have seen recently. Here's how it works.     The exploit uses a vulnerability within MariaDB, PerconaDB (and/or XtraDB Cluster) and MySQL to, first, gain access to the 'mysql' system user using any mysql user that has CREATE / INSERT / UPDATE permissions. The first part revolves around a race condition when sql generates temporary files as part of the `REPAIR table` command. Then using the mysql system user the second vulnerability grants the attacker root access to the server using a clever hack that takes advantage of mysql_safe's approach to writing to file based error logs. Below I've provided a list of vulnerable server versions. Just about any server using the more recent (unpatched) stable releases of MySQL or MariaDB through CentOS is vulnerable (Percona isn't part of the st

Oracle has released a Critical Security Patch for a long list of Oracle products. For MySQL specifically, the patch purports to resolve a multitude of vulnerabilities that allow remote execution without authentication, and impact nearly all versions of the database software. Oracle provided the following Risk Matrix to their MySQL customers, which outlines the CVE numbers of stated vulnerabilities, the component used by the vulnerability and a number of other details. I've included a copy of that Matrix for readers to review below. As the reader can clearly see, the risk for unpatched MySQL users is huge. A total of 154 vulnerabilities are addressed with this update. Some of these vulnerabilities reach a forehead-slapping CVSS score of 9.0 (just one point beneath the score for  the recent Shellshock bash vulnerability ). 24 of the patches are for MySQL. I highly advise anyone using MySQL or any Oracle product, including Java, to  update their software immediately.

Its a simple message, but worth repeating. Yesterday I came across the website of a major internet security firm making a few first-day-on-the-job mistakes. While I am not going to "out" them before contacting them directly, what they did is silly enough that it warrants a bit of discussion in the abstract. Display_errors was enabled in their web server's php.ini. As a result, a few helpful messages were displayed briefly at the top of several of pages on the site 1. The name of the database 2. The name of the table in use by that page 3. A list of every column in that table 4. An error indicating that the table is exceeding its maximum allowable size of 4GB The site collects information about its users - IP address, browser info, referrer, etc, and stores that information to a table in a MySQL database - we know from the error itself that database is running on a server using a 32 bit operating system. With the structure of the database, we have everything we

So this is a weird one. I recently installed phpmyadmin 3.5.1 in a MySQL 5.1 / IIS 7.5 environment. Everything was going well until I realized that following the installation (which was fully functional) I could not login to MySQL (from the CLI) without referencing the hostname (-h flag). I figured that maybe the .sql script included with the installer messed with my grants, but a quick show grants revealed I still had the same permissions granted to root as when I started. So I figured that I would update the grants on root to what was displayed in show grants just in case. This produced an insufficient permissions error even though root had "full" privileges. To resolve this I added skip-grant-tables to my.ini, restarted the mysql service, logged in as root, flushed privileges, and again updated grants to what was displayed in "show grants". I then removed skip-grant-tables and restarted, and I was again able to login locally. I'm still not certain what caus