Live data from Hacker News

Hacking with environment variables

elttam.com

51–60 of 67 posts

Re: Hacking with environment variables

#51
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.

Not to take away from your point, but it seems like automated testing should easily detect issues like this one?

Re: Hacking with environment variables

#52

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.

Not to take away from your point, but it seems like automated testing should easily detect issues like this one?

Depends how you write your tests, but in this case, I'd say it'd be just as easy to carry the typo into your tests as not.

Unless you're fuzzing, automated testing could've easily missed this.

Re: Hacking with environment variables

#53
post #40
post #36

Earlier quoted context omitted.

> On a recent project we gained the ability to specify environment variables > We were also unable to control the contents of a file on disk From the first and second sentence.

That's my point. What "recent project"? Is there a CVE?

Elttam are a security firm who offer (among other things) pentesting - so they would usually be working privately with, say, a client's website.

One wouldn't usually file a CVE in these circumstances, if only the client is affected.

Re: Hacking with environment variables

#54

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…

More recently at SpamAndFlags CTF there was a similar challenge, where an innocent looking shell script was to be exploited multiple times, each time by a different environment variable. There is a nice writeup at https://github.com/p4-team/ctf/tree/master/2020-05-10-spam-a...

Re: Hacking with environment variables

#55
post #32

When you control environment variables, can't you also LDPRELOAD scary stuff?

The second sentence of the blog post states: We were also unable to control the contents of a file on disk, and bruteforcing process identifiers (PIDs) and file descriptors found no interesting results, eliminating remote LD_PRELOAD exploitation.

Oops, have overseen that one.

Re: Hacking with environment variables

#56
post #10

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

Delete the first element in the body, , which sits on top of the rest and blocks it from view. This is one of the two standard failure techniques. (I glom and the likes in the same category as this site.) The other category is where the body has no content, and JavaScript injects it. I’m undecided which is worse, but I think that it’s probably this one, because the developer pretty much went out of their way to slow…

Is that to avoid the FOUC?

Re: Hacking with environment variables

#57
Regarding Python scripts: All Python scripts runnable by more than one user should really have the “-I” option on the shebang line; this, among other things, ignores all PYTHON* environment variables. (Note: Python 3 only.)

Re: Hacking with environment variables

#58
post #31
post #10

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

That explains why I got a loading screen for a page that was just static text. I don’t get why people use those kind of shitty frameworks for sites that don’t require interactive content.

Because it's their website and they can publish their free content however they want? You are always welcome to not consume it.

Re: Hacking with environment variables

#59
post #21

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.

This is flat wrong. You can cause it to run an arbitrary binary by setting the BROWSER environment variable, as they demonstrate in the article. They chained it with perl environment variable vulnerability listed earlier to achieve execution.

Re: Hacking with environment variables

#60
post #57

Regarding Python scripts: All Python scripts runnable by more than one user should really have the “-I” option on the shebang line; this, among other things, ignores all PYTHON* environment variables. (Note: Python 3 only.)

Why? Isn't it safer to just have sudo always handle resetting the environment? Or do you mean if you're using a custom setuid wrapper?
Post reply on HN