Hacker News Reader

Comment by cookiengineer | Hacker News Reader

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.

View on HN

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.

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?

Actually, there is such a thing as PERL6LIB: it's an environment variable still recognized by Raku (formerly known as Perl 6). As you may know, Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). FWIW, there is now also a RAKULIB environment variable :-)

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.

The typo almost looks malicious, to be honest.

Reply on news.ycombinator.com