Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Antigravity.py (2020)

github.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Antigravity.py (2020)

#31

Post by btown »

isp wrote: post #25
chias wrote: post #22

Earlier quoted context omitted.

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 execut…

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…

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/ ! It's a common enough attack pattern that 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.

Re: Antigravity.py (2020)

#32

Post by chias »

ASalazarMX wrote: post #29
isp wrote: post #25

Earlier quoted context omitted.

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…

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.

Interesting, that's pretty cool. Thanks!

Re: Antigravity.py (2020)

#33

Post by shaded-enmity »

ASalazarMX wrote: post #29
isp wrote: post #25

Earlier quoted context omitted.

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…

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.

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.

Re: Antigravity.py (2020)

#34

Post by dpwm »

btown wrote: post #31
isp wrote: post #25

Earlier quoted context omitted.

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…

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/ ! It's a common enough attack pattern that https://capec.mitre.org/data/definiti…

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.

Re: Antigravity.py (2020)

#35

Post by tyingq »

ASalazarMX wrote: post #29
isp wrote: post #25

Earlier quoted context omitted.

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…

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.

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.

Re: Antigravity.py (2020)

#36

Post by geofft »

shmageggy wrote: post #24
diogenesjunior wrote: post #6

I get a type error in line 13 running the code: TypeError: openssl_md5() takes no keyword arguments

From the docs > Changed in version 3.9: All hashlib constructors take a keyword-only argument usedforsecurity...

To add to this - antigravity is part of the Python standard library, and you want to run the version that's shipped with your version of Python, not the version from the latest development build. Do "python3 -m antigravity".

Re: Antigravity.py (2020)

#37

Post by geofft »

isp wrote: post #25
chias wrote: post #22

Earlier quoted context omitted.

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 execut…

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…

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).

Re: Antigravity.py (2020)

#38

Post by oyf »

isp wrote: post #10

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 Previous HN comments: https://news.ycombinator.com/item?id=23828045

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.

Re: Antigravity.py (2020)

#39

Post by jvanderbot »

dpwm wrote: post #34
btown wrote: post #31

Earlier quoted context omitted.

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/ ! It's a common enough attack pattern that https://capec.mitre.org/data/definiti…

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.

I left one window open, but what is to guarantee a burgler would use that window??

Re: Antigravity.py (2020)

#40

Post by chronolitus »

A description of what the code does:

First, the line

webbrowser.open("https://xkcd.com/353/")

is obvious, it opens a browser pointing to the relevant XKCD comic, containing a joke which inspired this code.

Then, a geohash function is declared which takes the user's current latitude/longitude, and the current date-time, and returns a target latitude/longitude. According to a previous comic (https://xkcd.com/426/) this corresponds to the game of 'geohashing' where players are supposed to physically travel to arbitrary locations and prove it.

Post reply on HN