Writing "/etc/hosts" breaks the Substack editor • Hacker News Board

Re: Writing "/etc/hosts" breaks the Substack editor

#281

Post by watusername » Sat, Apr 26, 2025, 12:53 AM UTC

augusto-moura wrote: post #83

Y_Y wrote: post #7

Does it block `/etc//hosts` or `/etc/./hosts`? This is a ridiculous kind of whack-a-mole that's doomed to failure. The people who wrote these should realize that hackers are smarter and more determined than they are and you should only rely on proven security, like not executing untrusted input.

How would that be hard? Getting the absolute path of a string is in almost all languages stdlibs[1]. You can just grep for any string containing slashes and try resolve them and voilá Resolving wildcards is trickier but definitely possible if you have a list of forbidden files [1]: https://nodejs.org/api/path.html#pathresolvepaths Edit: changed link because C's realpath has a slightly different behavior

> How would that be hard? Getting the absolute path of a string is in almost all languages stdlibs[1]. You can just grep for any string containing slashes and try resolve them and voilá

Be very, very careful about this, because if you aren't, this can actually result in platform-dependent behavior or actual filesystem access. They are bytes containing funny slashes and dots, so process them as such.

Edit: s/text/bytes/

Re: Writing "/etc/hosts" breaks the Substack editor

#282

Post by smithkl42 » Sat, Apr 26, 2025, 12:56 AM UTC

simonw wrote: post #148

betaby wrote: post #100

Earlier quoted context omitted.

> but a lot of seemingly dumb security policies are due to insurers. I keep hearing that often on HN, however I've personally never seen seen such demands from insurers. I would greatly appreciate if one share such insurance policy. Insurance policies are not trade secrets and OK to be public. I can google plenty of commercial cars insurance policies for example.

I found an example! https://retail.direct.zurich.ch/resources/definition/product... Questionnaire Zurich Cyber Insurance Question 4.2: "Do you have a technically enforced password policy that ensures use of strong passwords and that passwords are changed at least quarterly?" Since this is an insurance questionnaire, presumably your answers to that question affect the rates you get charged? (Found that with the help o…

We've been asked that question before on security questionnaires, and our answer has always been, "Forcing users to change passwords regularly is widely regarded as a very bad security practice, and we don't engage in bad security practices." We've never had anyone complain.

Re: Writing "/etc/hosts" breaks the Substack editor

#283

Post by decasia » Sat, Apr 26, 2025, 1:07 AM UTC

derektank wrote: post #134

josephcsible wrote: post #85

Earlier quoted context omitted.

Why wouldn't the IT people just tell the grumbling employees that exact explanation?

IT doesn't always hear the grumbles, hidden away as they frequently are behind a ticketing system; the help desk technicians who do hear the grumbles aren't always informed of the "why" behind certain policies, and don't have the time or inclination to go look them up if they're even documented; and it's a very unsatisfying answer even if one receives a detailed explanation. Information loss is an inherent property o…

> Information loss is an inherent property of large organizations.

That's such an interesting axiom, I'm curious if you would want to say more about it? It feels right intuitively - complexity doesn't travel easily across contexts and reaching a common understanding is harder the more people you're talking to.

Re: Writing "/etc/hosts" breaks the Substack editor

#284

Post by godelski » Sat, Apr 26, 2025, 1:08 AM UTC

Macha wrote: post #278

godelski wrote: post #225

Earlier quoted context omitted.

Can you help me understand the exploit here? I'd really like to understand. (What's below is written not as "this is how it should be done" but instead "what I understand should be done". To provide context to what I do and do not understand so that my misunderstandings can be more directly addressed) I understand being over zealous, an abundance of caution. But what I'm confused about is why normal text could lead t…

Misconfiguring your web server such that example.com/../../etc/passwd returned the actual file was a common vulnerability in the early 00s. Or cgi scripts that worked with real file paths but accepted any path WAFs blocking the string with the filename then is the "to make sure nobody ever accidentally leaves your gate open, we've replaced it with a concrete wall" solution to this problem. You might never have this p…

  > directory transversal attack

There's some serious miscommunication going on. I'm quite willing to believe it is from my end, but I thought I explained earlier that I'm well aware of directory transversal. The example did not clarify things to me when the author mentioned it

I asked why setting permissions was not a sufficient solution. Is someone gaining root? How?

I understand there's the user visiting substack and the person editing on substack. Certainly this is about the person editing. This is why I asked about the containerization side. That's an extra layer in permissions. Not only should that editor not have permissions to edit `/etc/passwd` (or some other file), but they wouldn't be able to do so even if gaining root. They'd need to gain root, break out of the container, and gain root again (hopefully that container is being run as a user and not root!).

But even there, I'm still confused about the exploits. How is a transversal even happening? Why is text even being executed? I understand we're sending POST requests but why is that POST request able to do anything other than input string literals into a text body? Isn't this a prepared statement? Why does that POST request have permission to access those files in the first place? Like even if a malicious editor circumvented defenses and was able to write injections, accessing those files shouldn't be possible from permissions, right?

My understanding is that for this solution to be effective then several other critical security flaws have to also have happened. And how far does this thing need to go? Isn't it defeatable if I chop up the keywords into benign ones, store as variables, and then expand them? I guess it stops very low hanging fruit attackers but again, isn't that also only in the situations where there are also low hanging fruit attacks available which can cause far more damage? That's where my confusion is coming from.

Re: Writing "/etc/hosts" breaks the Substack editor

#285

Post by Sharo2025 » Sat, Apr 26, 2025, 1:17 AM UTC

[flagged]

Re: Writing "/etc/hosts" breaks the Substack editor

#286

Post by stalfosknight » Sat, Apr 26, 2025, 1:18 AM UTC

swyx wrote: post #240

j1elo wrote: post #238

Earlier quoted context omitted.

Thanks. My mind started running the random string generator given those restrictions, like a puzzle game. But had no idea of what it meant until you wrote it. Who invented that stupid idea and thought it would be a good one?

because its easily googlable. counter point - people are going to use them, better to expose newbies early and often and then everyone is better off shorthands will always be in demand. we used to say “horseless carriage”, then “automobile”, then “car”. would you rather use Light amplification by stimulated emission of radiation or just “laser”s? etc in the new york times? sure, spell out observability. but on HN? co…

I've never seen it before.

Re: Writing "/etc/hosts" breaks the Substack editor

#287

Post by zelphirkalt » Sat, Apr 26, 2025, 1:34 AM UTC

hnlmorg wrote: post #141

jrockway wrote: post #14

Earlier quoted context omitted.

Yeah, and this seems like a common Fortune 500 mandatory checkbox. Gotta have a Web Application Firewall! Doesn't matter what the rules are, as long as there are a few. Once I was told I needed one to prevent SQL injection attacks... against an application that didn't use an SQL database. If you push back you'll always get a lecture on "defense in depth", and then they really look at you like you're crazy when you su…

I’m going through exactly this joy with a client right now. “We need SQL injection rules in the WAF” “But we don’t have an SQL database” “But we need to protect against the possibility of partnering with another company that needs to use the same datasets and wants to import them into a SQL database” In fairness, these people are just trying to do their job too. They get told by NIST (et al) and Cloud service provide…

If they want to do their job well, how about adding some thinking into the mix, for good measure? Good would also be,if they actually knew what they are talking about, before trying to tell the engineers what to do.

Re: Writing "/etc/hosts" breaks the Substack editor

#288

Post by zelphirkalt » Sat, Apr 26, 2025, 1:36 AM UTC

CoffeeOnWrite wrote: post #129

tough wrote: post #70

Earlier quoted context omitted.

I think the main point is the WAF companies must have lobbied to get that into the checklist the main point is you need to pay a third party

You can call your existing reverse proxy a WAF to check this checklist item. (Your point still stands, on the median companies may opt to purchase a WAF for various reasons.)

Often it is just pushing responsibility.

Re: Writing "/etc/hosts" breaks the Substack editor

#289

Post by halffullbrain » Sat, Apr 26, 2025, 1:48 AM UTC

At least, in this case, the WAF in question had the decency to return 403.

I've worked with a WAF installation (totally different product), where the "WAF fail" tell was HTTP status 200 (!) and "location: /" (and some garbage cookies), possibly to get browsers to redirect using said cookies. This was part of the CSRF protection. Other problems were with "command injection"-patterns (like in the article, expect with specific Windows commands, too - they clash with everyday words which the users submit), and obviously SQL injections which cover some relevant words, too.

The bottom line is that WAFs in their "hardened/insurance friendly" standard configs are set up to protect the company from amateurs exposing buggy, unsupported software or architectures. WAF's are useful for that, but you still gave all the other issues with buggy, unsupported software.

As others have written, WAFs can be useful to protect against emerging threats, like we saw with the log4j exploit which CloudFlare rolled out protection for quite fast.

Unless you want compliance more than customers, you MUST at least have a process to add exceptions to "all the rules"-circus they put in front of the buggy apps.

Whack-a-mole security filtering is bad, but whack-a-mole relaxation rule creation against an unknown filter is really tiring.

Re: Writing "/etc/hosts" breaks the Substack editor

#290

Post by oakwhiz » Sat, Apr 26, 2025, 1:57 AM UTC

matt_heimer wrote: post #36

The people configuring WAF rules at CDNs tend to do a poor job understanding sites and services that discuss technical content. It's not just Cloudflare, Akamai has the same problem. If your site discusses databases then turning on the default SQL injection attack prevention rules will break your site. And there is another ruleset for file inclusion where things like /etc/hosts and /etc/passwd get blocked. I disagree…

I've had the issue where filling out form fields for some company website triggers a WAF and then nobody in the company is able to connect me to the responsible party who can fix the WAF rules. So I'm just stuck.