5 ms·

There is a proof of concept given, "Figure-4: arbitrary code execution achieved using multiple environment variables against Python 2 and Python 3": $ dock

by isp 5y ago

There is a proof of concept given, "Figure-4: arbitrary code execution achieved using multiple environment variables against Python 2 and Python 3": $ docker run -e 'PYTHONWARNINGS=all:0:antigravity.x:0:0' -e 'BROWSER=perlthanks' -e 'PERL5OPT=-Mbase;print(`id`);exit;' python:2.7.18 python /dev/null uid=0(root) gid=0(root) groups=0(root) Invalid -W option ignored: unknown warning category: 'antigravity.x' $ docker run -e 'PYTHONWARNINGS=all:0:antigravity.x:0:0' -e 'BROWSER=perlthanks' -e 'PERL5OPT=-Mbase;print(`id`);exit;' python:3.8.2 python /dev/null uid=0(root) gid=0(root) groups=0(root) Invalid -W option ignored: unknown warning category: 'antigravity.x'

ASalazarMX 5y ago
TL;DR: 'import antigravity' is fine, but Python can be tricked with environment variables to use Perl as the web browser, which has arbitrary code execution through environment variables.
- chias 5y ago
  Interesting, that's pretty cool. Thanks!
- shaded-enmity 5y ago
  Defense in depth would disagree that it is fine. I'm pretty sure this vulnerability can go much further if you combine it with, for example, the `https_proxy` environment variable.
- tyingq 5y ago
  And Perl (specifically "perlthanks") was just the first thing they found that worked. Bash had similar problems in the past, and I imagine there's other "installed by default" stuff that can be coaxed into running code in environment variables.
btown 5y ago
And specifically, although it is nowadays uncommon for Python scripts to be run the way old-school WSGI web services were, with a script being fired up for every request and mapping user-controlled query parameters to environment variables, this was at one time actually the motivating example for https://www.python.org/dev/peps/pep-0333/ https://www.python.org/dev/peps/pep-0333/ ! It's a common enough attack pattern that https://capec.mitre.org/data/definitions/77.html https://capec.mitre.org/data/definitions/77.html exists and specifically cautions applications against trusting environment variables. There are very few places in Python where upon importing a module, an environment variable is trusted and triggered; all of them should be seen as security holes.
- dpwm 5y ago
  Surely this is only a security risk if antigravity is imported? What cause would there be to import antigravity in a CGI service – or anything other than a terminal in which you could already execute arbitrary code? I am struggling to understand, even with the proof of concept, how the situation could arise where an attacker could realistically exploit this, based largely on the uselessness of the antigravity module.
  - jvanderbot 5y ago
    I left one window open, but what is to guarantee a burgler would use that window??
    - dpwm 5y ago
      Absolutely, I agree now that I see it, and these seem like numerous innocent-seeming footguns just waiting for abuse. Add the not-too-far-fetched-seeming assumption that it’s fine to let the Internet define your environment variables, and it’s a plausible exploit. This is why, as another commenter points out, defense in depth is so important.
  - geofft 5y ago
    See the "Making Progress With PYTHONWARNINGS" section in the article posted - setting the environment variable PYTHONWARNINGS to a value mentioning the antigravity module causes it to be imported, even if there's no "import antigravity" statement in the actual source.
    - dpwm 5y ago
      Not sure how I missed that – it was even in the proof of concept in the message I replied to. Thanks for the help. There are multiple failings that don’t seem like a big deal taken in isolation: - The PYTHONWARNINGS and whole Warning Filters system. - The webbrowser module executing a given executable from an environment variable. - The antigravity module running webbrowser.open() on import. All of these sort of seem a bit like sacrificing good taste for convenience. But in combination, in a situation where you don’t control the environment variables, they do lead to arbitrary code execution. In other words, it’s not all antigravity’s fault, but those side effects on import make this possible.
geofft 5y ago
If you can influence arbitrary environment variables, you usually have a lot more options - you could set PYTHONHOME or PYTHONPATH (influence where Python finds imports), LD_LIBRARY_PATH (influence where shared libraries come from), PATH (influence where the Python command itself comes from), etc. etc. In this particular case, they happened to be in a situation where they couldn't easily figure out how to create new files but they could set environment variables. From a design perspective, as a reviewer, I would not believe that this makes it safe to have attacker-controlled environment variables, although I admit I wouldn't know exactly how (and this post is a pretty clever approach to making the attack work).

by isp 5y ago

ASalazarMX 5y ago

TL;DR: 'import antigravity' is fine, but Python can be tricked with environment variables to use Perl as the web browser, which has arbitrary code execution through environment variables.

chias 5y ago
Interesting, that's pretty cool. Thanks!
shaded-enmity 5y ago
Defense in depth would disagree that it is fine. I'm pretty sure this vulnerability can go much further if you combine it with, for example, the `https_proxy` environment variable.
tyingq 5y ago
And Perl (specifically "perlthanks") was just the first thing they found that worked. Bash had similar problems in the past, and I imagine there's other "installed by default" stuff that can be coaxed into running code in environment variables.

btown 5y ago

And specifically, although it is nowadays uncommon for Python scripts to be run the way old-school WSGI web services were, with a script being fired up for every request and mapping user-controlled query parameters to environment variables, this was at one time actually the motivating example for https://www.python.org/dev/peps/pep-0333/ https://www.python.org/dev/peps/pep-0333/ ! It's a common enough attack pattern that https://capec.mitre.org/data/definitions/77.html https://capec.mitre.org/data/definitions/77.html exists and specifically cautions applications against trusting environment variables. There are very few places in Python where upon importing a module, an environment variable is trusted and triggered; all of them should be seen as security holes.

dpwm 5y ago
Surely this is only a security risk if antigravity is imported? What cause would there be to import antigravity in a CGI service – or anything other than a terminal in which you could already execute arbitrary code? I am struggling to understand, even with the proof of concept, how the situation could arise where an attacker could realistically exploit this, based largely on the uselessness of the antigravity module.
- jvanderbot 5y ago
  I left one window open, but what is to guarantee a burgler would use that window??
  - dpwm 5y ago
    Absolutely, I agree now that I see it, and these seem like numerous innocent-seeming footguns just waiting for abuse. Add the not-too-far-fetched-seeming assumption that it’s fine to let the Internet define your environment variables, and it’s a plausible exploit. This is why, as another commenter points out, defense in depth is so important.
- geofft 5y ago
  See the "Making Progress With PYTHONWARNINGS" section in the article posted - setting the environment variable PYTHONWARNINGS to a value mentioning the antigravity module causes it to be imported, even if there's no "import antigravity" statement in the actual source.
  - dpwm 5y ago
    Not sure how I missed that – it was even in the proof of concept in the message I replied to. Thanks for the help. There are multiple failings that don’t seem like a big deal taken in isolation: - The PYTHONWARNINGS and whole Warning Filters system. - The webbrowser module executing a given executable from an environment variable. - The antigravity module running webbrowser.open() on import. All of these sort of seem a bit like sacrificing good taste for convenience. But in combination, in a situation where you don’t control the environment variables, they do lead to arbitrary code execution. In other words, it’s not all antigravity’s fault, but those side effects on import make this possible.

geofft 5y ago

If you can influence arbitrary environment variables, you usually have a lot more options - you could set PYTHONHOME or PYTHONPATH (influence where Python finds imports), LD_LIBRARY_PATH (influence where shared libraries come from), PATH (influence where the Python command itself comes from), etc. etc. In this particular case, they happened to be in a situation where they couldn't easily figure out how to create new files but they could set environment variables. From a design perspective, as a reviewer, I would not believe that this makes it safe to have attacker-controlled environment variables, although I admit I wouldn't know exactly how (and this post is a pretty clever approach to making the attack work).