Closed Bug 1715684 Opened 3 years ago Closed 3 years ago

Block port 990 and others to prevent/reduce "ALPACA" attacks

Categories

(Core :: Networking, task)

task

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: dveditz, Assigned: freddy)

References

()

Details

Attachments

(1 file)

The recently released ALPACA-attack paper describes a general class of cross-protocol confusion attacks carried out on TLS channels. The long-range fix involves upgrading clients and a whole lot of different kinds of server software and then deploying it everywhere. Our part of that is covered in bug 1683710. It's going to take a long time to fix the internet that way.

In the mean time there's a lot of similarities between this attack and the old cross-protocol vulnerabilities that resulted in the "port blocking" feature in browsers (referenced in the paper). It appears we missed some commonly vulnerable ports and as a short-term hack we could add them now.

Port 990 for FTPS seems worth blocking. It's a reserved port for this service, and < 1024 so less likely to be squatted on.

In addition to port 990 for FTPS, should we also block 989, the FTPS-data port? We've blocked the analogous FTP-data port 20.

The paper mentions that SMTP can be found on ports 26 and 2525 in addition to the 25, 465, and 587 we already block.

Risk: port blocking can break sites even if "it shouldn't" because the port is reserved for another service. for example, bug 347393 (Baltic banks). That's much rarer these days when most people use hosting services that push them in standard directions.

I can find lots and lots of mentions that SMTP is commonly run on the two non-reserved ports we don't already block, but I couldn't find much data on numbers. Anyone have a shodan account?

The Alpaca-attacks site says

Microsoft Internet Explorer blocked more non-HTTP server ports and disabled content sniffing for HTTP requests to non-standard ports (CVE-2021-31971).

I can't find any information on which ports they blocked though.

Blocking 990 and 989 have low risk. The risk of blocking a sub-1024 port that has been assigned to a widely-deployed protocol is not zero, but it is probably low enough if others are doing the same.

Blocking port 26 is slightly riskier. That's an unassigned port.

Blocking port 2525 is riskier still as that is above 1024.

Ideally we do some testing on each of these (a check with shodan might be enough), but I'd be comfortable with following Microsoft without that if they have blocked port 990 as speculated. We should ask them. Dan, do you have a contact you can use? I can try the long route if necessary.

FWIW, the long-range fix is even further out: the specifications need to be updated first. That doesn't make it much worse, but it means that relying on that fix is even less realistic.

Flags: needinfo?(dveditz)

Admittedly, blocking ports is a weird and not very efficient hammer, but it is a hammer we are wielding regularly enough.
The main advantage of implementing port blocking that I see is that it's pragmatic. It's an imperfect protection, but it's better than relying on everyone on the web to upgrade their servers (update the server software, change certificate, domains or ports).

I've made recent changes to our necko code and coordinated with other vendors through changes to the fetch spec (there's a list https://fetch.spec.whatwg.org/#port-blocking) for other cross-protocol security issues (e.g. NAT slipstreaming).
I will take this for port 990 and 989 (and expand to 2525 in a follow-up once we have the data).

Assignee: nobody → fbraun

There's plenty of evidence on the web that 2525 is widely used for SMTP -- both instructions for using it and software that has that port as a built-in option. Apparently lots of ISPs block port 25 (or maybe low-numbered ports broadly?) and 2525 appears to be a de facto standard alternate. I'm kind of meh on blocking port 26 unless we see more evidence of use, but 2525 seems worth investigating further. Example web documentation:
https://www.sparkpost.com/blog/what-smtp-port/
https://www.authsmtp.com/thunderbird-v60/alternate-port.html

I've asked Adam Rice in https://github.com/whatwg/fetch/pull/1250 to see if he can gather numbers for port 2525 - not sure if he's going to implement a user counter or if he has existing data. Given how long it took us to agree on port 10080 being blocked, I'd rather move ahead with 989 and 990 without waiting. I'm filing a follow-up (unless Adam comes back with info before this one here is resolved fixed)

Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f58ca1eb4556
block port 989 and 990 for ftps-data and ftps r=necko-reviewers,valentin
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/29343 for changes under testing/web-platform/tests
Regressions: 1716010
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
Upstream PR merged by moz-wptsync-bot

I got an answer from Eric Lawrence about what MS did with IE:

For Internet Explorer, the update was to

  • Disable MIME Sniffing (force text/plain) for HTTP/0.9 responses from non-default ports (80, 443)
  • Block requests to three ports: FTPS 990, SMTPS 465 and POP3S 995.

Edge, like Chrome, has not made any changes yet, though they have long blocked HTTP/0.9 responses on non-default ports (unless it looked like shoutcast, because shoutcast was/is still a thing?)
https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_stream_parser.cc;l=1023;drc=8a7540697bf500749236bf717a3930ba99f15f3e

The Chrome folks are currently considering adding 26, 989, 990, 2525 to their block list. They landed telemetry but not a block.

Flags: needinfo?(dveditz)

Here's the Chromium commit to block ports 989 and 990 by default:
https://chromium-review.googlesource.com/c/chromium/src/+/2964893

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: