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.
Hacking with environment variables
51–60 of 67 posts
Re: Hacking with environment variables
#52Earlier 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?
Unless you're fuzzing, automated testing could've easily missed this.
Re: Hacking with environment variables
#53Earlier 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?
One wouldn't usually file a CVE in these circumstances, if only the client is affected.
Re: Hacking with environment variables
#54This 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…
Re: Hacking with environment variables
#55When 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.
Re: Hacking with environment variables
#56Warning, 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…
Re: Hacking with environment variables
#57Re: Hacking with environment variables
#58Warning, 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.
Re: Hacking with environment variables
#59Earlier 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.
Re: Hacking with environment variables
#60Regarding 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.)