←back to thread

Writing "/etc/hosts" breaks the Substack editor

(scalewithlee.substack.com)
603 points scalewithlee | 4 comments | 25 Apr 25 13:48 UTC | HN request time: 0s | source
Show context
Y_Y ◴[25 Apr 25 14:13 UTC] No.43793778[source]▶
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.
replies(6): >>43793862 #>>43793868 #>>43793954 #>>43794072 #>>43794473 #>>43802345 #
1. augusto-moura ◴[25 Apr 25 15:18 UTC] No.43794473[source]▶
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

replies(3): >>43797276 #>>43799951 #>>43804170 #
2. myflash13 ◴[25 Apr 25 18:51 UTC] No.43797276[source]▶
It’s not hard, but I think that’s more computation than a CDN should be doing on the edge. If your CDN layer is doing path resolution on all strings with slashes, that’s already some heavy lifting for a proxy layer.
3. watusername ◴[26 Apr 25 00:53 UTC] No.43799951[source]▶
> 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/

4. TheDong ◴[26 Apr 25 14:53 UTC] No.43804170[source]▶
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.