| Summary: | <dev-db/percona-toolkit-2.2.6 / <dev-db/xtrabackup-bin-2.1.7: remote code execution (CVE-2014-2029) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | trivial | CC: | idl0r, mysql-bugs |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2014/02/18/4 | ||
| Whiteboard: | ~2 [noglsa] | ||
| Package list: | Runtime testing required: | --- | |
innobackupex from dev-db/xtrabackup-bin-2.1.x is also affected. Both have been bumped/fixed. Fixed: >=dev-db/xtrabackup-bin-2.1.7 and >=dev-db/percona-toolkit-2.2.6 Please remove the affected version for dev-db/xtrabackup-bin (In reply to Agostino Sarubbo from comment #2) > Please remove the affected version for dev-db/xtrabackup-bin Already done. dev-db/xtrabackup-bin-2.0.8 is not affected. (In reply to Christian Ruppert (idl0r) from comment #4) > dev-db/xtrabackup-bin-2.0.8 is not affected. Ok, closing as noglsa |
From ${URL} : https://bugs.launchpad.net/percona-toolkit/+bug/1279502 https://bugzilla.novell.com/show_bug.cgi?id=864194 Quoting launchpad we have this gem: ------------------------------------------------------------------------------- Percona Toolkit 2.1 introduced --version-check to warn user about known vulnerabilities in the local MySQL instance and to check for PT updates. When this option is enabled - and it is enabled by default(!) - various information about local MySQL as well as other system binaries and packages are submitted to Percona along with the server's IP address. This not only exposes possibly sensitive information, but also does so without bringing it to user's attention or asking for their consent. It gets worse. The configuration for what information PT tools should collect is not hardcoded in the scripts. Instead, every time it's downloaded from http://v.percona.com/. One of the possible parameters is a binary file name to be executed, i.e. Percona can remotely execute arbitrary command - again, without making user aware of what or when is being executed. To be fair, the ability to run commands is limited to running "command -v", however that's only under the assumption that the command filters will always work. The configuration can also ask for any MySQL variable - not just the version string. In my opinion --version-check should never be enabled by default and if user wants to keep it enabled, the configuration (i.e. the list of checks) should be hardcoded and explicitly listed, and not downloaded from a remote location. Current workaround: To avoid confidential information being exposed, always use --no-version-check with every PT tool that includes 'version-check' feature (e.g. pt-query-digest, pt-diskstats). ------------------------------------------------------------------------------- Basically it is not just information leakage, but remote code execution if you can overtake the v.percona.com host or just be man in the middle. @maintainer(s): since the package has never been marked as stable, we don't need to stabilize it. After the bump, please remove the affected versions from the tree.