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

If your code accepts URIs as input, filter out “file://”

blog.steve.fi

Post reply on HN
Print view View original

91–100 of 161 posts

Re: If your code accepts URIs as input, filter out “file://”

#91

Post by throwawayReply »

3pt14159 wrote: post #88
throwawayReply wrote: post #31

Also make sure you don't follow 301/302, or someone can set up a http link which redirects to file:// .

Wait, what? Really!? Can this be used to get shell access somehow? I'm having trouble figuring out how you go from Chrome opening a remote file to _bad thing happens_.

It's not necessarily browsers, they often mitigate this.

The problem is with services that consume other content. For example you might have a service which generates thumbnails of sites.

That service might GET https://attacker.example.org/301.html which itself might 301 back to file:///etc/passwd . If there is insufficient validation then a screenshot of the contents of /etc/passwd might be returned by the service.

All of that happens outside the context of browsers and sandboxing.

For more of that kind of thing, here's an interesting write up on some vulnerabilities found in Pocket. https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-po...

Re: If your code accepts URIs as input, filter out “file://”

#92

Post by seszett »

nerdponx wrote: post #66
throwanem wrote: post #29

Earlier quoted context omitted.

I certainly am weary of bug branding...

I only started seeing this weary/wary misspelling in recent years. They don't sound alike, and they don't really look alike. Did cell phone spellcheckers give rise to this one?

> /ˈwɪəɹi/

> /wɛəɹ.i/

I'm not a native English speaker and I would never have guessed that they were not pronounced the same. (I'm still not even sure how it is pronounced as ɪ doesn't seem to exist in French and I always considered the examples I find were just "i").

I know English pronunciation is generally weird, but seriously how can you expect wary to sound like wear while weary sounds like something else?

Re: If your code accepts URIs as input, filter out “file://”

#93

Post by oldmanjay »

artursapek wrote: post #24
mootothemax wrote: post #6

Earlier quoted context omitted.

>Wrong way around: only allow http:// and https:// For myself, it's a subtle change in developer thinking - "what should I allow" vs "what should I exclude" - that's paid off massively over the years.

https://en.m.wikipedia.org/wiki/Robustness_principle

No, be strict, fail fast, and report the errors. Robustness is not achieved by muddling through on a misinterpretation, it is achieved by working toward correctness.

Re: If your code accepts URIs as input, filter out “file://”

#94

Post by nebulous1 »

rybosome wrote: post #62

The vulnerability is happening because the web server is running as a user with elevated permissions. If it were running as a user who only had permissions to read files from the webserver's serving directory this would obviate the problem. Not that you shouldn't also validate input (in a whitelist rather than blacklist as others have said): just goes to show that security is a multifaceted problem with lots of ways…

You don't need elevated privileges to read /etc/passwd

Re: If your code accepts URIs as input, filter out “file://”

#95

Post by SnacksOnAPlane »

hughperkins wrote: post #4

Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.

You seriously want to disallow gopher://? C'mon, man!

Re: If your code accepts URIs as input, filter out “file://”

#96

Post by Symbiote »

germanier wrote: post #79
kijin wrote: post #51

Earlier quoted context omitted.

If a user copied the URL from the address bar, it will be correctly percent-encoded already. You can put the same percent-encoded URL in the href attribute of a hyperlink. A properly encoded URL will not contain any character that requires escaping in an HTML context. When a user clicks on that link, the browser will navigate to the percent-encoded URL but display the snowman icon in the address bar. If the user copi…

I just tried doing that with a few domain names containing an umlaut (äöü) and every single time that letter was copied into the clipboard (even though behind the scenes at the request level it would have been encoded). This is what I expect as a regular user. They don't want to deal with encoded, unreadable URLs.

I tried with http://њњњ.срб , which Firefox copies correctly, but Chromium copies as http://xn--g2aaa.xn--90a3ac/ — not very useful.

This is a different mechanism to the path part, where both Firefox and Chromium give https://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D1%81%D1%81%D0%B8... rather than the readable https://ru.wikipedia.org/wiki/Россия

Re: If your code accepts URIs as input, filter out “file://”

#97

Post by zanny »

pawadu wrote: post #13
greenleafjacob wrote: post #10

This is the confused deputy problem. The most general solution to this class of vulnerabilities, SELinux, has been largely ignored. Does SELinux need more work to "bring it to market", or is it just too complicated and needs to be simplified?

configuring SELinux is way too complicated for the average user.

Then use one of the nowadays many alternatives - there is Apparmor, Tomoyo, and GRSec's RBAC all performing the same MAC job.

Re: If your code accepts URIs as input, filter out “file://”

#98

Post by 23andwalnut »

kuschku wrote: post #71
4ndr3vv wrote: post #69

Earlier quoted context omitted.

Agreed! Better get that karma before someone else does /snark

The issue is more that if so many people have already found it, who else has?

Disclosing it publicly before it's been fixed only increases the number.

Re: If your code accepts URIs as input, filter out “file://”

#99

Post by tonylucas »

throwawayReply wrote: post #31

Also make sure you don't follow 301/302, or someone can set up a http link which redirects to file:// .

For those using curl for this, it has flags to specify protocol filters for initial request and redirects

https://curl.haxx.se/libcurl/c/CURLOPT_PROTOCOLS.html

Re: If your code accepts URIs as input, filter out “file://”

#100

Post by daveloyall »

nebulous1 wrote: post #94
rybosome wrote: post #62

The vulnerability is happening because the web server is running as a user with elevated permissions. If it were running as a user who only had permissions to read files from the webserver's serving directory this would obviate the problem. Not that you shouldn't also validate input (in a whitelist rather than blacklist as others have said): just goes to show that security is a multifaceted problem with lots of ways…

You don't need elevated privileges to read /etc/passwd

That is correct.

    sebboh@namagiri:~$ ls -al /etc/passwd
    -rw-r--r-- 1 root root 1450 Jun  7 09:08 /etc/passwd
So, there's this idea of running publicly facing services as a user which has less privileges than a normal interactive user. This user might be called 'nobody' or 'apache', etc.

However, on your average distribution, /etc/passwd is accessible to the 'nobody' user or the 'apache' user.

There are various work arounds:

+ run your service in a chroot or jail.

+ employ some kind of SE Linux thing.

+ ...?

I've only ever used the first one.

Post reply on HN