Live data from Hacker News

Hacking with environment variables

elttam.com

61–67 of 67 posts

Re: Hacking with environment variables

#61
post #31

Earlier quoted context omitted.

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.

I do get your sentiment but it's not really addressing what I believe the GPs point to be, which is redundant framework bloat for personal blogs. Take the sites I personally run, one of them is written in markdown and "compiled" to HTML using `pandoc` (a CLI document conversion tool) and then it's pushed to S3. Some of the others are run on dynamic CMSs and have modern frameworks used to "help speed up development". But you know which site was actually the quickest to develop? It's also the site which which loads the quickest, costs the least to host and requires the least upkeep -- it's the one which doesn't use any frameworks at all, just a few lines of hand-crafted CSS. It doesn't even have any Javascript.

I'm not saying everyone has to go that minimal but my (and I suspect the GPs) point is that people can get carried away when designing their personal blogs, and in fact sites in general, and miss the point of what their site is actually trying to achieve in the process. If someone feels they need a loading screen to serve a static blog then I suspect they've probably fallen into that trap themselves.

Re: Hacking with environment variables

#62

Earlier quoted context omitted.

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?

Typically, yes.

But I just want to be clear on this reason: it’s a fundamentally bad technique that slows things down and harms accessibility, both of which are far more important than your website potentially appearing slightly imperfectly while it loads, like just >99.4% of websites. (And if you’re doing something that means that your page looks worse than most while loading, you’re probably loading your resources in the wrong way somehow, e.g. putting a critical stylesheet at the end of the document rather than in the head.)

Other reasons for doing this are:

• A splash screen sort of experience. Yeah, there are still some around doing this, though it’s fortunately uncommon. It’s often a precursor to this second reason:

• A misguided desire to animate things into place at the right time (kind of an extension of the FOUC, I guess). Gratuitous animating-in of content as you scroll, which this meshes with, is a horrible thing to do, by the way: although it’s decidedly popular on homepages, most people dislike it (ranging from mild displeasure to rage-quitting the site), because it’s distracting, slows things down and adds nothing. Just don’t do it.

In short, I see no legitimate reason to ever set document opacity to zero or to put a loading spinner on top of everything else, in CSS. (In JavaScript, maybe—there are defensible reasons; but never in CSS.)

Re: Hacking with environment variables

#63
post #21

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.

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.

Yep, I misunderstood then - definitely vulnerable on its own!

Re: Hacking with environment variables

#64
post #8

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

Oh you're right.

Re: Hacking with environment variables

#65

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.

My university let students put procmail files in their home directories to filter their incoming email. I created a .procmailrc file which set a DISPLAY env variable and then spawned an xterm process. That popped up a terminal on the machine I was sitting at with a shell on the mail server which had write access to every student's home directory.

Re: Hacking with environment variables

#66
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?

I said nothing about sudo or setuid; I simply meant what I wrote: A Python program runnable by more than one user, where I meant user as in uid.

Re: Hacking with environment variables

#67
post #66

Earlier quoted context omitted.

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?

I said nothing about sudo or setuid; I simply meant what I wrote: A Python program runnable by more than one user, where I meant user as in uid.

That makes even less sense then. Are you trying to protect users from attacking themselves? What specific threat do you think you'd mitigate by doing that?
Post reply on HN