1299881 - Extend gBadPortList in nsIOService to include memcached, redis and elasticsearch

Status: NEW

(Core :: Networking, defect, P3)

Description

[Frederik Braun [:freddy]]

nsIOService contains a list of bad ports that we shouldn't connect to. This helps preventing cross-protocol attacks against the user and their intranet.
The list can be seen here: https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIOService.cpp#97

Bug 1262128 explains why it's possible to abuse legacy HTTP/0.9 support and dns rebinding. It was also re-discovered and went through some news websites. See also <http://bouk.co/blog/hacking-developers/>.

On top of the rebinding & HTTP/0.9 fixes discussed in bug 1262128, I suggest expanding our block list to include the ports of the software discussed in the aforementioned blog post:

elasticsearch: 9200
redis: 6379, possibly also 16379, 26379? 
memchached: 11211


Blocking those ports should not break things for our users as none of these services do speak HTTP.
It would be great if someone who's actually used those service for more than just an exploit could confirm that blocking these ports is effective.

Comment 1

[Frederik Braun [:freddy]]

Contributor kpcyrd on #security in IRC mentioned that the service behind elasticsearch port 9200 is in fact a RESTful interface.

Comment 2

[Daniel Veditz [:dveditz]]

(In reply to Frederik Braun [:freddyb] from comment #0)
> Blocking those ports should not break things for our users as none of these
> services do speak HTTP.

The problem isn't whether those services speak HTTP, but whether there are also legitimate HTTP services using those ports. How standard are those ports? are they reserved? With ports < 1024 we're on pretty solid ground, and even then adding some of those services broke people (Estonian banks, for example, when we blocked smtp+ssl).

Comment 3

[Andrei Boros]

Chrome 55 has disabled HTTP/0.9 for other ports and this has effectively killed listening to any Shoutcast radio station on the internet. 

See more details here: https://bugs.chromium.org/p/chromium/issues/detail?id=669800&can=2&start=0&num=100&q=audio&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=#

IMO this should be handled in a way that does not affect such services.

Comment 4

[Tom S [:evilpie]]

Please open an issue https://github.com/whatwg/fetch/issues if you want to change the port blocklist.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[Gian-Carlo Pascutto [:gcp]]

>The problem isn't whether those services speak HTTP, but whether there are also legitimate HTTP services using those ports. How standard are those ports? are they reserved? 

11211 is reserved:

memcache 	11211 	tcp 	Memory cache service 	[Trond_Norbye] 	[Trond_Norbye] 	2009-02-09 	

6379 is reserved:

redis 	6379 	tcp 	An advanced key-value cache and store 	[Salvatore_Sanfilippo] 	[Itamar_Haber] 	2015-04-23

From comment 1 I gather we can't actually block the elasticsearch port anyway.

dveditz, would it be OK to prepare a patch for those two and test fallout on Nightly or so? How do you want to proceed?

Comment 8

[Daniel Veditz [:dveditz]]

Sure, that sounds reasonable. But we should definitely add this to the beta release notes so it will be less mysterious if we do happen to break people.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

Unassigning bugs owned by Patrick.