Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL)
-
None
Description
Summary
The database server daemon should create its PID file before dropping
privileges. This represents a minor security issue; additional factors
are needed to make it exploitable.
Description
The purpose of the PID file is to hold the PID of the running daemon,
so that later it can be stopped, restarted, or otherwise signalled
(many daemons reload their configurations in response to a SIGHUP).
To fulfill that purpose, the contents of the PID file need to be
trustworthy. If the PID file is writable by a non-root user, then he
can replace its contents with the PID of a root process. Afterwards,
any attempt to signal the PID contained in the PID file will instead
signal a root process chosen by the non-root user (a vulnerability).
This is commonly exploitable by init scripts that are run as root and
which blindly trust the contents of their PID files. If one daemon
flushes its cache in response to SIGUSR2 and another daemon drops all
connections in response to SIGUSR2, it is not hard to imagine a
denial-of-service by the user of the first daemon against the second.
Exploitation
There is only a risk of exploitation when some other user relies on
the data in the PID file. But you have to wonder, what's the point of
the PID file if not to provide the PID to other people? Any situation
where the PID file is used is therefore suspicious.
Attachments
Activity
By the way, thanks for the CVE id. In April 2018 CPU CVE-2018-2773 is attributed to you (mjo) and is listed as having
| Product | MySQL Server |
|---|---|
| Component | Client programs |
| Protocol | None |
| Remote Exploit without Auth.? | No |
| Base Score | 4.1 |
| Attack Vector | Local |
| Attack Complex | High |
| Privs Req'd | High |
| User Interact | None |
| Scope | Unchanched |
| Confidentiality | None |
| Integrity | None |
| Availability | High |
How's that "Client program", I wonder. And how can it affect availability of MySQL Server...
Ah, thanks. My original report had nothing to do with world-writable directories... makes you wonder =)
The original problem was fixed in October 2018 CPU as CVE-2018-3174. mjo is credited as reporter, and Client programs is again listed as the affected component.
MySQL fix:
https://github.com/mysql/mysql-server/commit/e1fdeb2468f3ee16e34e0c3af856edde128836e5
Re-implemented MariaDB fix:
https://github.com/MariaDB/server/commit/73e1ffdc6899aea69182c15930f712a178813660
mjo can you confirm CVE-2018-3174 really is for this issue? You either should have received the info from Oracle, or they should confirm the CVE id assignment if you ask. Thank you!
It's not really fixed, but I've given up. The fix that they shipped is to use
su mysql -s /bin/bash -c kill...
|
in the init scripts that are shipped with MySQL. It's not a good fix:
1. It doesn't address the design flaw... why is the PID file being created after dropping privileges in the first place? The sole purpose of the PID file is to aid SysV-style init scripts (if you're also using it as e.g. a lockfile: don't do that). There's no cross-platform way to drop privileges in an init script, so they all kill the process as root. Thus, the PID file should be root-owned.
2. It only works on Redhat/Oracle, and only if you use the script from the MySQL tarball. Everyone else has to invent their own OS-specific solution, or be vulnerable. Not that they'd ever know to do that.
I've already explained the issue to Oracle like 5 times and they don't get it. They go silent for 6 months and then come back with something like a hardcoded "su mysql" command that only works on Redhat.
MySQL 5.5.60 has this commit:
I'm sorry, but I don't see how it is MySQL vulnerability if one of the path
components in pid file location is world writable.