6 ms·

This looked innocuous at first glance, but this "antigravity" Easter egg has been found to have security implications. See "Hacking with Environment Variables"

by isp 5y ago

This looked innocuous at first glance, but this "antigravity" Easter egg has been found to have security implications. See "Hacking with Environment Variables", which specifically exploits the antigravity module for arbitrary code execution - https://www.elttam.com/blog/env/#content https://www.elttam.com/blog/env/#content Previous HN comments: https://news.ycombinator.com/item?id=23828045 https://news.ycombinator.com/item?id=23828045

deleted 5y ago
[deleted]
chias 5y ago
I'm unconvinced. "The ability to turn this into arbitrary code execution depends on what other executables are available on the system" is doing a LOT of heavy lifting here. Remember: you have control over only the environment variables, and you do not have the ability to alter the arguments. In order for this to represent arbitrary code execution, you need for the system to have an executable on it that, when executed with the argument "https://xkcd.com/353/ https://xkcd.com/353/", grants you arbitrary code execution. So, you have full control over the environment variables, and that's it. How do you turn effectively [binary] "https://xkcd.com/353/" into arbitrary code execution, where [binary] is an executable already on the machine?
- 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.
- deleted 5y ago
  [deleted]
- marcinzm 5y ago
  The next section of the link literally goes into how to achieve all of that using a call to perl.
thebeardisred 5y ago
Related to the idea "innocuous at first glance", that time when folks got cute with the man command: https://git.savannah.nongnu.org/cgit/man-db.git/commit/src/man.c?id=002a6339b1fe8f83f4808022a17e1aa379756d99 https://git.savannah.nongnu.org/cgit/man-db.git/commit/src/m... Turns out it was breaking a users automated tests - https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030 https://unix.stackexchange.com/questions/405783/why-does-man...
oyf 5y ago
If you have the ability to set environment variables then it's basically already game over, with or without the existence of the antigravity module. You could set PATH to change which files are executed in certain scenarios. You could set SSLKEYLOGFILE which logs session keys to an arbitrary file, essentially nullifying TLS/SSL protections. On Linux you can just set PROMPT_COMMAND to whatever you want and it'll be executed any time a bash prompt is printed. It's an interesting attack vector, but a vulnerability requires impact, and I'm not sure this has very much.

by isp 5y ago

deleted 5y ago

[deleted]

chias 5y ago

I'm unconvinced. "The ability to turn this into arbitrary code execution depends on what other executables are available on the system" is doing a LOT of heavy lifting here. Remember: you have control over only the environment variables, and you do not have the ability to alter the arguments. In order for this to represent arbitrary code execution, you need for the system to have an executable on it that, when executed with the argument "https://xkcd.com/353/ https://xkcd.com/353/", grants you arbitrary code execution. So, you have full control over the environment variables, and that's it. How do you turn effectively [binary] "https://xkcd.com/353/" into arbitrary code execution, where [binary] is an executable already on the machine?

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.
deleted 5y ago
[deleted]
marcinzm 5y ago
The next section of the link literally goes into how to achieve all of that using a call to perl.

thebeardisred 5y ago

Related to the idea "innocuous at first glance", that time when folks got cute with the man command: https://git.savannah.nongnu.org/cgit/man-db.git/commit/src/man.c?id=002a6339b1fe8f83f4808022a17e1aa379756d99 https://git.savannah.nongnu.org/cgit/man-db.git/commit/src/m... Turns out it was breaking a users automated tests - https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030 https://unix.stackexchange.com/questions/405783/why-does-man...

oyf 5y ago

If you have the ability to set environment variables then it's basically already game over, with or without the existence of the antigravity module. You could set PATH to change which files are executed in certain scenarios. You could set SSLKEYLOGFILE which logs session keys to an arbitrary file, essentially nullifying TLS/SSL protections. On Linux you can just set PROMPT_COMMAND to whatever you want and it'll be executed any time a bash prompt is printed. It's an interesting attack vector, but a vulnerability requires impact, and I'm not sure this has very much.