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

Hacking with environment variables

elttam.com

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Hacking with environment variables

#11

Post by NikolaeVarius »

userbinator wrote: post #7
NikolaeVarius wrote: post #5

Earlier quoted context omitted.

So... don't import antigravity, an obvious joke module.

Of course as a developer you (should) already have the power to run arbitrary code on your machine, so going through that route is silly. I think it's more in reference to locked-down environments like shared hosting, which want to run Python but restrict access to everything else. From that perspective, this ability looks like a sandbox escape.

If a sandbox includes the ability to load a link via a browser via standard event handler, how the hell is that an escape

Re: Hacking with environment variables

#12

Post by edoceo »

RcouF1uZ4gsC wrote: post #2

>An unexpected exception to this is the antigravity module. The Python developers included an easter egg in 2008 which can be triggered by running import antigravity. This import will immediately open your browser to the xkcd comic that joked that import antigravity in Python would grant you the ability to fly. > As for how the antigravity module opens your browser, it uses another module from the standard library ca…

At MS my team got our collective assws chewed for a egg in a cli tool that had our names listed - didn't make it into W2K :(

NLB still "rocks" tho :)

Re: Hacking with environment variables

#13

Post by mmastrac »

> A generic solution for Ruby has not been found yet. Ruby does accept an environment variable RUBYOPT to specify command-line options. The man page states that RUBYOPT can contain only -d, -E, -I, -K, -r, -T, -U, -v, -w, -W, --debug, --disable-FEATURE and --enable-FEATURE. The most promising option is -r which causes Ruby to load the library using require. However, this is limited to files with an extension of .rb or .so.

Interesting - could the -r option load a .so file with a .ctor section?

Re: Hacking with environment variables

#14

Post by dnautics »

NikolaeVarius wrote: post #11
userbinator wrote: post #7

Earlier quoted context omitted.

Of course as a developer you (should) already have the power to run arbitrary code on your machine, so going through that route is silly. I think it's more in reference to locked-down environments like shared hosting, which want to run Python but restrict access to everything else. From that perspective, this ability looks like a sandbox escape.

If a sandbox includes the ability to load a link via a browser via standard event handler, how the hell is that an escape

it's an escape because you can load an arbitrary script into the command, and if the sandbox crafter didn't think to lock down `import antigravity` then you can escape the sandbox.

Re: Hacking with environment variables

#15

Post by RcouF1uZ4gsC »

neolog wrote: post #8
userbinator wrote: post #7

Earlier quoted context omitted.

Of course as a developer you (should) already have the power to run arbitrary code on your machine, so going through that route is silly. I think it's more in reference to locked-down environments like shared hosting, which want to run Python but restrict access to everything else. From that perspective, this ability looks like a sandbox escape.

If the environment allows executing a browser, it allows executing a browser. Whether python is involved is irrelevant.

> If the environment allows executing a browser

From my reading of this, it allows executing any executable you can put in the BROWSER environment

Re: Hacking with environment variables

#16

Post by pentestercrab »

mmastrac wrote: post #13

> A generic solution for Ruby has not been found yet. Ruby does accept an environment variable RUBYOPT to specify command-line options. The man page states that RUBYOPT can contain only -d, -E, -I, -K, -r, -T, -U, -v, -w, -W, --debug, --disable-FEATURE and --enable-FEATURE. The most promising option is -r which causes Ruby to load the library using require. However, this is limited to files with an extension of .rb o…

Yes, that works fine. The hard part is finding a suitable .so already on the system. The following (credit to Tavis Ormandy) creates /tmp/testing

  $ RUBYOPT="-r/usr/lib64/libpcprofile.so" PCPROFILE_OUTPUT="/tmp/testing" ruby /dev/null

Re: Hacking with environment variables

#17

Post by cortesoft »

userbinator wrote: post #4
RcouF1uZ4gsC wrote: post #2

>An unexpected exception to this is the antigravity module. The Python developers included an easter egg in 2008 which can be triggered by running import antigravity. This import will immediately open your browser to the xkcd comic that joked that import antigravity in Python would grant you the ability to fly. > As for how the antigravity module opens your browser, it uses another module from the standard library ca…

It was the possibility of security vulnerabilities that made software companies (more specifically Microsoft[0]) eschew easter eggs. ...and yet there are plenty of horror stories about Win10 coming with lots of other "surprises" like Candy Crush installed by default, ads that fetch resources over the Internet, etc. I can almost hear a PM somewhere say "but they're not easter eggs, because they are documented somewher…

They aren't Easter eggs because they were probably paid to include them.

Re: Hacking with environment variables

#18

Post by pentestercrab »

neolog wrote: post #3
RcouF1uZ4gsC wrote: post #2

>An unexpected exception to this is the antigravity module. The Python developers included an easter egg in 2008 which can be triggered by running import antigravity. This import will immediately open your browser to the xkcd comic that joked that import antigravity in Python would grant you the ability to fly. > As for how the antigravity module opens your browser, it uses another module from the standard library ca…

This "vulnerability" requires "able to set an environment variable on a Python execution environment" and "opening a browser leads to RCE". Once you have that level of control over a system, I don't think `antigravity` will make or break an RCE.

It does not require opening a browser, it can cause a browser to open.

Re: Hacking with environment variables

#19

Post by cortesoft »

NikolaeVarius wrote: post #5
RcouF1uZ4gsC wrote: post #2

>An unexpected exception to this is the antigravity module. The Python developers included an easter egg in 2008 which can be triggered by running import antigravity. This import will immediately open your browser to the xkcd comic that joked that import antigravity in Python would grant you the ability to fly. > As for how the antigravity module opens your browser, it uses another module from the standard library ca…

So... don't import antigravity, an obvious joke module.

I am confused by your point... the article is trying to hack a system where they can only set environment variables, and they found an environment variable that can import arbitrary modules.

Are you trying to tell hackers to just not import the module?

Re: Hacking with environment variables

#20

Post by Rebelgecko »

neolog wrote: post #3
RcouF1uZ4gsC wrote: post #2

>An unexpected exception to this is the antigravity module. The Python developers included an easter egg in 2008 which can be triggered by running import antigravity. This import will immediately open your browser to the xkcd comic that joked that import antigravity in Python would grant you the ability to fly. > As for how the antigravity module opens your browser, it uses another module from the standard library ca…

This "vulnerability" requires "able to set an environment variable on a Python execution environment" and "opening a browser leads to RCE". Once you have that level of control over a system, I don't think `antigravity` will make or break an RCE.

I don't think you need a browser RCE. If you can set environment variables, can't you just change $BROWSER to point towards an arbitrary binary?
Post reply on HN