arbitrary code execution or file overwrite when templates are loaded from /tmp
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| python-dbusmock |
Fix Released
|
Medium
|
Martin Pitt | ||
| python-dbusmock (Debian) |
Fix Released
|
Unknown
|
|||
| python-dbusmock (Fedora) |
Confirmed
|
Medium
|
|||
| python-dbusmock (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt | ||
| Trusty |
Fix Released
|
Medium
|
Unassigned | ||
| Utopic |
Fix Released
|
Medium
|
Unassigned | ||
| Vivid |
Fix Released
|
Medium
|
Unassigned | ||
| Wily |
Fix Released
|
Medium
|
Martin Pitt | ||
Bug Description
While investigating a (perhaps transient) build failure in a Debian derivative, I accidentally found a class of security vulnerabilities in python-dbusmock.
In python-dbusmock's build-time test_api test, this:
def load_module(name):
if os.path.
try:
m = os.path.
module = importlib.
finally:
return module
return importlib.
is invoked with name being the name of a NamedTemporaryFile. That's probably in /tmp or /var/tmp, so I see several things that could go wrong there. We could have any of these attack modes, either in python-dbusmock's own tests or in any other code that also puts its template in /tmp or some other world-writeable directory:
* the attacker creates a large fraction of the approximately 3.5e12
possible names matching /tmp/mymodule_
appropriate) as (symlinks to) their malicious code, and we execute
one: arbitrary code execution
(this is hard to do, since the complete set would be multiple
terabytes)
* the attacker creates a large fraction of those names as symlinks
to a file they want overwritten, and we overwrite it if Python
doesn't use atomic overwrite for .pyc (which I haven't checked)
(this is similarly hard to do)
* the attacker uses an inotify on /tmp for a more targeted version
of the same attack, racing to create their payload .pyc before
our Python interpreter loads it
(this is perhaps a more realistic attack)
* the attacker creates /tmp/foo.py where foo is the name of a module
that is imported (possibly by another thread!) while we are in
the 'try' block, and we execute it
(I don't know whether os.path and/or importlib guarantee not to
import other modules, but other threads certainly don't have
that guarantee)
CVE References
| Martin Pitt (pitti) wrote | #1 |
| Changed in python-dbusmock: | |
| status: | New → In Progress |
| importance: | Undecided → Medium |
| assignee: | nobody → Martin Pitt (pitti) |
| Changed in python-dbusmock (Ubuntu Wily): | |
| status: | New → In Progress |
| assignee: | nobody → Martin Pitt (pitti) |
| Marc Deslauriers (mdeslaur) wrote | #2 |
| Martin Pitt (pitti) wrote | #3 |
| information type: | Private Security → Public Security |
| Martin Pitt (pitti) wrote | #4 |
| Changed in python-dbusmock: | |
| status: | In Progress → Fix Released |
|
|
#13 |
|
|
#14 |
| Martin Pitt (pitti) wrote | #5 |
| Changed in python-dbusmock (Ubuntu Wily): | |
| status: | In Progress → Fix Committed |
| Martin Pitt (pitti) wrote | #6 |
| Changed in python-dbusmock (Ubuntu Vivid): | |
| status: | New → In Progress |
| Martin Pitt (pitti) wrote | #7 |
| Changed in python-dbusmock (Ubuntu Utopic): | |
| status: | New → In Progress |
| Changed in python-dbusmock (Ubuntu Wily): | |
| importance: | Undecided → Medium |
| Changed in python-dbusmock (Ubuntu Vivid): | |
| importance: | Undecided → Medium |
| Changed in python-dbusmock (Ubuntu Utopic): | |
| importance: | Undecided → Medium |
| Changed in python-dbusmock (Ubuntu Trusty): | |
| importance: | Undecided → Medium |
| Martin Pitt (pitti) wrote | #8 |
| Changed in python-dbusmock (Ubuntu Trusty): | |
| status: | New → In Progress |
| tags: | added: patch |
|
|
#18 |
| Launchpad Janitor (janitor) wrote | #9 |
| Changed in python-dbusmock (Ubuntu Wily): | |
| status: | Fix Committed → Fix Released |
|
|
#20 |
| Launchpad Janitor (janitor) wrote | #10 |
| Changed in python-dbusmock (Ubuntu Utopic): | |
| status: | In Progress → Fix Released |
| Launchpad Janitor (janitor) wrote | #11 |
| Changed in python-dbusmock (Ubuntu Vivid): | |
| status: | In Progress → Fix Released |
| Launchpad Janitor (janitor) wrote | #12 |
| Changed in python-dbusmock (Ubuntu Trusty): | |
| status: | In Progress → Fix Released |
| Changed in python-dbusmock (Debian): | |
| status: | Unknown → Fix Released |
|
|
#24 |
|
|
#25 |
|
|
#28 |
| Changed in python-dbusmock (Fedora): | |
| importance: | Unknown → Medium |
| status: | Unknown → Confirmed |
IMHO It's highly unrealistic that this actually gets exploited, as it requires a scenario where someone directly puts a module into /tmp/, not a subdir. Aside from dbusmock's own tests this is very unlikely as usually projects ship their own mocks in their source tree, and don't generate it on the fly. And then it can only happen when there are multiple and untrusted users on a machine (which isn't the case in CI systems either).
So, this does need to get fixed, but my gut feeling is that the severity is on the "low" side and doesn't warrant private
vendor-sec coordination with a coordinated release date. But I'll let our security team decide.
As discussed by mail already, this is the patch which I'll apply upstream. This includes a test case, too.