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

21–30 of 67 posts

Re: Hacking with environment variables

#21

Post by Groxx »

pentestercrab wrote: post #18
neolog wrote: post #3

Earlier quoted context omitted.

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.

Which is not on its own a "vulnerability", you'd need to chain it to something usable in the browser / as a consequence of the browser being opened.

It increases your options, certainly, but it can't do anything dangerous as-is.

Re: Hacking with environment variables

#22

Post by netmare »

svnpenn wrote: post #10

Warning, website wont load at all unless JavaScript is enabled.

Not only that, it also caused the app I'm using (Readability) to go back to the article list. I usually get a blank screen, but this is first time I've seen it fail so spectacularly in years.

Does anyone know what the site's JavaScript doing to cause that?

Re: Hacking with environment variables

#23

Post by ragerino »

Groxx wrote: post #21
pentestercrab wrote: post #18

Earlier quoted context omitted.

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

Which is not on its own a "vulnerability", you'd need to chain it to something usable in the browser / as a consequence of the browser being opened. It increases your options, certainly, but it can't do anything dangerous as-is.

You can define any executable in the $BROWSER environment variable which will be executed whenever antigravity is imported.

You could execute a 'curl` which directly pipes into 'bash -c'.

Re: Hacking with environment variables

#24

Post by lunixbochs »

This was a huge component of a 2020 DEFCON CTF qualifier challenge that only Samurai and PPP solved, where you had to get code execution or arbitrary file read out of as many setuid binaries as possible, after installing basically every cli Debian package and changing them to setuid.

There are some very interesting ways to load shared objects or read files with environment variables, and we even found ways to leverage common libraries like readline and gconv to pop apps that used them.

Re: Hacking with environment variables

#25

Post by shanemhansen »

I did something like this once. My University had an full screen kiosk browser that was locked down. Well it turns out that you could "customize" Firefox, add in a missing button, get to the print screen and change the executable from "lpr" to $TERM which would immediately pop a shell.

Good times.

Re: Hacking with environment variables

#26

Post by cookiengineer »

awirth wrote: post #6

See also the sudo bad environment variable list[1], which I recently found a 15 year old typo in.[2] [1]: https://github.com/sudo-project/sudo/blob/master/plugins/sud... [2]: https://www.sudo.ws/repos/sudo/rev/bdf9c9e7f455

This is such a good example on why security is hard.

I mean, good intentions, should've worked, but a single mistake wasn't discovered among all of the features involved in locking it down as hard as possible.

Security is a fight nobody can win, because it's an N-1 relationship of reassuring your own mistakes vs. finding a single mistake as an opportunity.

Re: Hacking with environment variables

#27

Post by pentestercrab »

lunixbochs wrote: post #24

This was a huge component of a 2020 DEFCON CTF qualifier challenge that only Samurai and PPP solved, where you had to get code execution or arbitrary file read out of as many setuid binaries as possible, after installing basically every cli Debian package and changing them to setuid. There are some very interesting ways to load shared objects or read files with environment variables, and we even found ways to leverag…

Sounds very interesting, thanks for sharing. Do you have any more information or perhaps a URL to a write-up for this? Or do you remember the challenge name?

Re: Hacking with environment variables

#28

Post by hannob »

cookiengineer wrote: post #26
awirth wrote: post #6

See also the sudo bad environment variable list[1], which I recently found a 15 year old typo in.[2] [1]: https://github.com/sudo-project/sudo/blob/master/plugins/sud... [2]: https://www.sudo.ws/repos/sudo/rev/bdf9c9e7f455

This is such a good example on why security is hard. I mean, good intentions, should've worked, but a single mistake wasn't discovered among all of the features involved in locking it down as hard as possible. Security is a fight nobody can win, because it's an N-1 relationship of reassuring your own mistakes vs. finding a single mistake as an opportunity.

Isn't this more an example of "fail-open design is bad, use fail-close"? Or in other words "make an allowlist, not a blocklist"?

I mean look at those variables, this seems like a loosing battle. PERLLIB, PERL5LIB etc. - what if there's a PERL6LIB at some point or a NEWSCRIPTINGLANGUAGELIB variable?

Re: Hacking with environment variables

#29

Post by awirth »

hannob wrote: post #28
cookiengineer wrote: post #26

Earlier quoted context omitted.

This is such a good example on why security is hard. I mean, good intentions, should've worked, but a single mistake wasn't discovered among all of the features involved in locking it down as hard as possible. Security is a fight nobody can win, because it's an N-1 relationship of reassuring your own mistakes vs. finding a single mistake as an opportunity.

Isn't this more an example of "fail-open design is bad, use fail-close"? Or in other words "make an allowlist, not a blocklist"? I mean look at those variables, this seems like a loosing battle. PERLLIB, PERL5LIB etc. - what if there's a PERL6LIB at some point or a NEWSCRIPTINGLANGUAGELIB variable?

Yes. This is why running without `env_reset` is considered inherently insecure and the typo fix wasn't considered a security fix by the sudo maintainers.

The list is still relevant to this discussion though as a nice "greatest hits" cheat-sheet of fun environment variables to play with here.

Re: Hacking with environment variables

#30

Post by cookiengineer »

hannob wrote: post #28
cookiengineer wrote: post #26

Earlier quoted context omitted.

This is such a good example on why security is hard. I mean, good intentions, should've worked, but a single mistake wasn't discovered among all of the features involved in locking it down as hard as possible. Security is a fight nobody can win, because it's an N-1 relationship of reassuring your own mistakes vs. finding a single mistake as an opportunity.

Isn't this more an example of "fail-open design is bad, use fail-close"? Or in other words "make an allowlist, not a blocklist"? I mean look at those variables, this seems like a loosing battle. PERLLIB, PERL5LIB etc. - what if there's a PERL6LIB at some point or a NEWSCRIPTINGLANGUAGELIB variable?

Well, touche.

I think that the fail-close design (I know them as positive-style branching) should be embraced everywhere possible.

But can this be actually achieved without breaking the ecosystem in the sense of having to start all over again?

Post reply on HN