I'd be very cautious here. It's highly unlikely that you would have made modifications to the MySQL driver included in that file either accidentally or on purpose - it's such a low-level system component that it's rarely modified by anyone (of course it IS possible, just unlikely).
As the other submitters indicated, the message you received is indicating that the file can not be patched. Normally there are two reasons this happens:
You (or someone on your team) modified this file so when the patch utility first compares the file to what expects to see in the original, it throws an error and says it can't patch the file. It logs the details in the lib/Varien/Db/Adapter/Pdo/Mysql.php.rej file for you to review.
The file is successfully compromised by an attacker.
The problem is that this file was one of the ones called out in the recent security patches that not only needed to be updated, but that was modified by attackers to compromise Magento installations. I saw it modified on several of the sites we evaluated and remediated after being compromised.
Given that this file failed on installation of the patch, you should assume your system was compromised before you installed the patch. I know that sounds horrible, but you can work through this and restore your site back to functioning properly.
Before I go into the details below, I want to encourage you to contact a security professional who can assist you if you have not spent a lot of time developing working on security issues or with systems that have been successfully attacked. You do not want to do this alone unless you have an expert on your team since it is difficult to know if you're going to expose your customers to additional risk until you've had a thorough scan and audit by someone who has experience dealing with both the technical considerations as well as the contractual and legal issues surrounding breaches and notification requirements and any laws dictating which law enforcement agencies you may need to notify where you are located.
All that said, it's unfortunate, as I discuss below, but installing the fixes will not resolve your problem if you are already compromised. They only stop future attacks, They DO NOT DO ANYTHING TO FIX A SYSTEM THAT IS ALREADY COMPROMISED.
We've documented our research to provide a list of known attack signatures so that you can check your systems for evidence of them and respond accordingly.
We're working on a toolkit to automate the remediation of these item but it may be a week or two until it's ready for distribution. In the meantime, we're sharing the knowledge we've acquired working through these compromises with everyone in the community in an effort to make sure everyone is as safe as can be expected.
You can't know what has or hasn't been compromised until you diff the files in your system against the default source code provided by Magento or a copy you have made in your (Git / Mercurial / SVN) repository. YOU SHOULD ASSUME that your database and logins have been compromised and go change them all.
Phase 1: Identify the scope of your compromise. Each and every one of the items I list below are signatures we've discovered on compromised Magento sites specifically relating to the SUPEE-5344 and SUPEE-5994 vulnerability announcements. After you've installed the most recent patches (and any others you may need to install from Magento), you need to go through each one and check to see if you find any evidence of the signature on your system. Many of them are enough by themselves to allow an attacker to re-enter your system after you patch it, so you'll have to be diligent and make sure you don't skip anything or fail to remediate it.
You can also use the online scanner from Magento, but by and large this only will tell you if you've installed the patches and prevented future compromises. If you've already been compromised, these won't scan for other back doors or attacks that may have been installed when you were first attacked. at least none of the ones we tested found the signatures we discovered. Defense in depth is the way to go, which means multiple scans and reviews from multiple tools and perspectives if you want to be confident in the results.
Phase 2: Delete what you must, and replace what you can : use the original files from your repository or the Magento source files. If you're not running one of the latest versions, you can still use the Magento download page to grab older version sources from their site.
Phase 3: RESET Credentials: Inventory every use of a login name and password remotely related to your deployment and reset them all, including
- Merchant Account Logins and API Keys
- Magento Admin Logins & Passwords
- Email account credentials
- LDAP / AD / Primary Authentication System
- Passwords
- EVERYTHING
- You can be reasonably sure that the preceding steps will help you purge infected fies but you can not know if passwords have been sniffed or key logged or the victim of some other attack, so resetting all related credentials is the safest option if you are going to attempt to remediate a compromised system.
The guide is too long to post in this response but the signature list can be downloaded immediately at our Magento Security Toolkit GitHub repository.
