41–50 of 67 posts
I understand this kind of techniques were common to attack unsafe CGI web servers in the old time. I wonder whether it is still the case nowadays. Is CGI still being used?
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…
Why would you change "every cli Debian package" to setuid and not expect hundreds of exploits? Solution is not to do something so silly.
Of course some of them are trivial, you don't get any props for showing arbitrary file reading when you can run bash or perl as root. But exploiting readline that way is pretty interesting!
Earlier quoted context omitted.
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'.
See https://github.com/python/cpython/blob/master/Lib/webbrowser...
>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…
>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…
To be clear, an easter egg is only supposed to be a (pleasant) surprise to the consumer -- not a secret kept from the rest of the team, especially QA. You can and should absolutely test your easter eggs.
Yes, Excel's increasingly elaborate easter eggs[2] would probably find it hard to get past security review these days. But to say that easter eggs are bad because security doesn't make sense. Especially when companies include undocumented features in software all the time -- e.g., typing '=rand()' into newer versions of MS Word produces some random text, probably a lorem ipsum generator-like feature.
[1] https://www.google.com/search?hl=en&source=hp&q=askew&oq=ask...
[2] https://www.youtube.com/watch?v=Xb9AXBowb0E , https://www.youtube.com/watch?v=-gYb5GUs0dM , https://www.youtube.com/watch?v=PGZfuwsvIFQ
Earlier quoted context omitted.
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
Warning, website wont load at all unless JavaScript is enabled.
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 things down in the name of subjective prettiness (and perhaps just because they wrote the rest of the markup/styling/code badly), and thereby broke things. Whereas I can at least understand why you’d do the whole thing in JavaScript, even if it’s not something I’m willing to do.
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?
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.
I understand this kind of techniques were common to attack unsafe CGI web servers in the old time. I wonder whether it is still the case nowadays. Is CGI still being used?
For example, a sub-contractor at BigCo., Inc. could use a lot of this knowledge to exfiltrate stuff.
I mean, CGI web servers are still out there - but careful that you don't overlook a wider market for these sploits.