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

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

#331

Post by TheDong » Sat, Apr 26, 2025, 2:53 PM 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

The reason it's doomed to failure is because WAFs operate before your application, and don't have any clue what the data is.

Here is a WAF matching line: https://github.com/coreruleset/coreruleset/blob/943a6216edea...

Here's where that file is loaded: https://github.com/coreruleset/coreruleset/blob/943a6216edea...

It's loaded with '"@pmFromFile lfi-os-files.data"' which means "case-insensitive match of values from a file".

So yeah, the reason it can't resolve paths properly is because WAFs are just regex and substring matching trying to paper over security issues in an application which can only be solved correctly at the application level.

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

#332

Post by WesolyKubeczek » Sat, Apr 26, 2025, 3:07 PM UTC

gav wrote: post #39

paxys wrote: post #4

This isn't a "security vs usability" trade-off as the author implies. This has nothing to do with security at all. /etc/hosts See, HN didn't complain. Does this mean I have hacked into the site? No, Substack (or Cloudflare, wherever the problem is) is run by people who have no idea how text input works.

It's more so that Cloudflare has a WAF product that checks a box for security and makes people who's job it is to care about boxes being checked happy. For example, I worked with a client that had a test suite of about 7000 or so strings that should return a 500 error, including /etc/hosts and other ones such as: ../../apache/logs/error.log AND%20(SELECT%208203%20FROM%20(SELECT(SLEEP(5)))xGId) /../..//../..//../..//.…

Why in the world should those be 500 even? Those all are "40x client fuckup".

I guess someone was told, when compiling those strings, that they should observe this known-good implementation (that actually crashed upon receiving such things) and record whatever it returns, and then mandate it of everyone else from now on.

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

#333

Post by Habgdnv » Sat, Apr 26, 2025, 3:40 PM UTC

I have a lifetime Pastebin account that I hadn't used for some years. Last year I enrolled in a "linux administration" class and tried to use that pastebin (famous for sharing code) to share some code/configurations with other students. When I tried to paste my homework I kept getting a Cloudflare error page. I don't even remember what I was pasting, but it was normal linux stuff. I contacted pastebin support - of course I got ghosted.

I am sharing this in relation to the WAF comments and how much the companies implementing WAF care about your case.

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

#334

Post by vladvasiliu » Sat, Apr 26, 2025, 3:59 PM UTC

chimeracoder wrote: post #210

cratermoon wrote: post #135

Earlier quoted context omitted.

Sometime in the past few years I saw a new wrinkle: password must be changed every 90 days unless it is above a minimum length (12 or so as best I recall) in which case you only need to change it yearly. Since the industry has realized length trumps dumb "complexity" checks, it's a welcome change to see that encoded into policy.

> Sometime in the past few years I saw a new wrinkle: password must be changed every 90 days unless it is above a minimum length (12 or so as best I recall) in which case you only need to change it yearly. Since the industry has realized length trumps dumb "complexity" checks, it's a welcome change to see that encoded into policy. This is such a bizarre hybrid policy, especially since forced password rotations at fix…

I think the issue is that some people don't actually understand what's going on, so in an attempt at goodwill, they try to "compromise", and "split the difference" if you will. Hell, some people will consider the windows hello pin as a password and force a regular rotation. Combined with policies coming from outside (think insurance and other compliance stuff) which try to cover as much ground as possible, you end up with half-assed implementations like these.

One discourse I hear is that "people will just use the same password everywhere". To which I'll answer, "but we have mfa". "yeah, but the insurance guys".

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

#335

Post by sgarland » Sat, Apr 26, 2025, 4:05 PM UTC

swiftcoder wrote: post #78

mjr00 wrote: post #65

Earlier quoted context omitted.

> I disagree with other posts here, it is partially a balance between security and usability. And economics. Many people here are blaming incompetent security teams and app developers, but a lot of seemingly dumb security policies are due to insurers. If an insurer says "we're going to jack up premiums by 20% unless you force employees to change their password once every 90 days", you can argue till you're blue in th…

Not just economics, audit processes also really encourage adopting large rulesets wholesale. We're SOC2 + HIPAA compliant, which either means convincing the auditor that our in-house security rules cover 100% of the cases they care about... or we buy an off-the-shelf WAF that has already completed the compliance process, and call it a day. The CTO is going to pick the second option every time.

OS-level monitoring / auditing software also never ceases to amaze me (for how awful it is). Multiple times, at multiple companies, I have seen incidents that were caused because Security installed / enabled something (AWS GuardDuty, Auditbeat, CrowdStrike…) that tanked performance. My current place has the latter two on our ProxySQL EC2 nodes. Auditbeat is consuming two logical cores on its own. I haven’t been able to yet quantify the impact of CrowdStrike, but from a recent perf report, it seemed like it was using eBPF to hook into every TCP connection, which is quite a lot for a DB connection poolers.

I understand the need for security tooling, but I don’t think companies often consider the huge performance impact these tools add.

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

#336

Post by 3eb7988a1663 » Sat, Apr 26, 2025, 4:28 PM UTC

immibis wrote: post #308

jimmaswell wrote: post #271

Earlier quoted context omitted.

I do the same but write the number at the end of the password on the laptop in sharpie. I work from home so I've been thinking about making a usb stick that simulates a keyboard with a button to enter the password.

Dangerous. You might accidentally press the button in a group chat.

They would then have an excuse to get one of those mission control button covers.

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

#337

Post by awoimbee » Sat, Apr 26, 2025, 5:55 PM UTC

simonw wrote: post #50

"How could Substack improve this situation for technical writers?" How about this: don't run a dumb as rocks Web Application Firewall on an endpoint where people are editing articles that could be about any topic, including discussing the kind of strings that might trigger a dumb as rocks WAF. This is like when forums about web development implement XSS filters that prevent their members from talking about XSS! Learn…

I'm in the position where I have to run a WAF to pass security certifications. The only open source WAFs are modsecurity and it's beta successor, coraza. These things are dumb, they just use OWASP's coreruleset which is a big pile of unreadable garbage.

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

#338

Post by matt-p » Sat, Apr 26, 2025, 6:18 PM 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…

In my experience the pain of false positives required to outweigh the "WAF is best practice" is just very very heigh. Most big businesses would rather lose/frustrate a small percentage of customers, to be "safe".

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

#339

Post by mattrighetti » Sat, Apr 26, 2025, 7:03 PM UTC

This reminds me of that time I was discussing with friends about something we did in our computer science class that day and I realised writing toString in the Whatsapp client for macOS would crash the application. At the time I didn’t have the skills to understand why so I recorded the bug on my phone to share with friends :)

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

#340

Post by gusgus01 » Sat, Apr 26, 2025, 7:06 PM UTC

austhrow743 wrote: post #319

smithkl42 wrote: post #282

Earlier quoted context omitted.

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.

I've never had a complaint about anything I put in to a form requesting a quote for insurance. I just get the quote back. Did you write that in the comment expecting an insurance salesperson to call you up and argue passwords with you? Call their back office and say "hey this guy says our password question is crap, get our best guys on it!"? I just cant imagine any outcome other than it was translated to just a "no"…

I've also filled out insurance quote forms several times to see the interplay of the questions and price. Quite often many of the questions do not change the quote. So the existence of the question in a form does not imply a change in price, or any true guess at the magnitude of the change at all.