Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing "/etc/hosts" breaks the Substack editor

scalewithlee.substack.com

Post reply on HN
Print view View original

221–230 of 370 posts

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

#221

Post by ZeroTalent »

rmccue wrote: post #194
swyx wrote: post #182

substack also does wonderful things like preserve weird bullet points, lack code block displays, and make it impossible to customize the landing page of your site beyond the 2 formats they give you. generally think that Substack has done a good thing for its core audience of longform newsletter writer creators who want to be Ben Thompson. however its experience for technical people, for podcasters, for people who wan…

Ben Thompson is working on Passport, which seems to be a self-hosted (WordPress-based) Substack: https://stratechery.com/2021/passport/ He gave a talk on it at WordCamp Asia at the start of last year, although I haven’t heard of any progress recently on it.

You're missing the point of Substack:

1. It's a social media platform with a network that is still easy to extract organic growth from.

2. 99% email deliverability without configuring anything. It's whitelisted everywhere.

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

#222

Post by afiori »

mjr00 wrote: post #65
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 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…

I believe that these kind of decisions are mostly downstream of security audits/consultants with varying level of up to date slideshows.

I believe that this is overall a reasonable approach for companies that are bigger than "the CEO knows everyone and trusted executives are also senior IT/Devs/tech experts" and smaller than "we can spin an internal security audit using in-house resources"

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

#223

Post by smj-edison »

joseda-hg wrote: post #117
mcoliver wrote: post #113

Earlier quoted context omitted.

entropy is stronger than complexity. https://xkcd.com/936/

I wonder how many people have used Correct Horse Battery Staple as a password thanks to this comic

> Makes password "xkcd.com/936"

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

#225

Post by godelski »

tryauuum wrote: post #195
godelski wrote: post #162

I don't get it. Why aren't those files just protected so they have no read or write permissions? Isn't this like the standard way to do things? Put the blog in a private user space with minimal permissions. Why would random text be parsed? I read the article but this doesn't make sense to me. They suggested directory transversal but your text shouldn't have anything to do with that and transversal is solved by permis…

this is the usual approach with web application firewalls, block all the 100500 known attacks. Doesn't matter if they are not applicable to your website. Some of them are obviously OS-depended (having .exe in the URLs) but it doesn't matter, it's blocked just in case I do understand this appoach. From the defence point of view it makes sense, if you have to create a solution to protect millions of websites it doesn't…

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 to an exploit in the first place. I can only understand this being a problem if arbitrary text is being executed. Which that would appear to be a HUGE security hole ripe for exploitation. But path access is handled by privileges. So even if arbitrary text is being executed, how can that lead to exploitation without already having a major security hole?

Maybe I'm not understanding substack? I've only been a reader. But why is the writer not in a container or chroot? If you want you be overly zealous why not use two vms? Put them in a vm to write, once they've edited then run tests and then use that as the image for the userspace in the ephemeral vm that is viewed by readers. Would this still be exploitable? I don't mean image for the whole vm, I really do mean a subimage so you can lock that up.

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

#226

Post by betaby »

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…

Password policy is something rather common, and 'standard' firewalls. Question is in the context of of WAF as in the article. WAF requirement is something more invasive to say the least.

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

#227

Post by betaby »

pjmlp wrote: post #202
kiitos wrote: post #173

Earlier quoted context omitted.

Directly following is question 4.3: "Are users always prevented from installing programs on end-user devices?" Totally bonkers stuff.

This is standard practice for years in big corporations. You install software via ticket requests to IT, and devs might have admin rights, but not root, and only temporary. This is nothing new though, back in the timesharing days, where we would connect to the development server, we only got as much rights as required for the ongoing development workflows. Hence why PCs felt so liberating.

It's a standard practice. And at $CURENT_JOB it's driven by semi-literate security folks, definitely not insurance.

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

#228

Post by nijave »

krferriter wrote: post #76
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 don't get why you'd have SQL injection filtering of input fields at the CDN level. Or any validation of input fields aside from length or maybe some simple type validation (number, date, etc). Your backend should be able to handle arbitrary byte content in input fields. Your backend shouldn't be vulnerable to SQL injection if not for a CDN layer that's doing pre-filtering.

The farther a request makes it into infrastructure, the more resources it uses.

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

#229

Post by 0xbadcafebee »

immibis wrote: post #180
SonOfLilit wrote: post #151

Earlier quoted context omitted.

You're being downvoted because WAFs work exactly like this, and it's intentional and their vendors think this is a good thing. A WAF vendor would say that a WAF parsing JSON makes it weaker.

They're being downvoted because they're saying the author is incorrect when the author is actually correct.

It's frightening that so many people are convinced the author is correct, when the author never proved they were correct.

The author just collected a bunch of correlations and then decided what the cause was. I've been doing this kind of work for many, many years. Just because it looks like it's caused by one thing, doesn't mean it is.

Correlation is not causation. That's not just a pithy quip, there's a reason why it's important to actually find causation.

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

#230

Post by jethro_tell »

PhilipRoman wrote: post #196
swyx wrote: post #183

Earlier quoted context omitted.

i think GP's point is how would you even sanitize the string "OutOfMemoryException" which presumably comes from a trusted system i guess demanding "Structured logs for everything or bust" is the answer? (i'm not a big o11y guy so pardon me if this is obvious)

Low tech example: escape all newlines in user supplied strings, then add a known prefix to all user supplied data (let's say a double hashtag ##, but anything else works too). When you want to search logs for strings coming from your system, remove/ignore everything after the marker. It all comes down to understanding whether the intersection of two grammars is empty.

The difficulty here is that in the example above, it's unlikely, given any amount of scale, that the two people were on the same team. They were doing different things with the same data and probably didn't know what the other was doing.

Sure you could add a convention to your 'how to log' doc that specifies that all user input should be tagged with double '#' but who reads docs until things break? convention is a shitty way to make things work.

There's 100 ways that you could make this work correctly. Only restarting on a much more specific string, i.e. including the app name in the log line etc . . . but that's all just reducing the likely hood that you get burned.

I've also written a OOM-Killer.sh myself, I'm not above that, but it's one of those edge cases that's impossible to do correctly, which is why parsing and acting on log data generally considered and anti-pattern.

Post reply on HN