-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block port 989, 990 (ftps-data and ftp) #1250
Conversation
I support blocking 989 and 990. As discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=1197149 it won't fix the most serious vulnerabilities, but it seems like a good precaution. I will do some investigation of port 2525. |
WPT change coming via gecko-wpt-sync whenever it runs next 🤞 |
Will you also file a Safari bug? (See https://bugs.webkit.org/enter_bug.cgi?product=WebKit, any component will do.) Should we have a follow-up issue for port 2525? |
https://bugs.webkit.org/show_bug.cgi?id=226971 (also updated at the top of this pull request) |
In whatwg/fetch#1250 the ports 989 (ftps-data) and 990 (ftps) were added to the list of blocked ports. Add them to kRestrictedPorts to align with the standard. Also add the ports to the "ExplicitlyAllowedNetworkPorts" enterprise policy to permit them to be temporarily unblocked. The expiry date is 2022/02/01, allowing approximately 6 months with a bit extra to avoid end-of-year holidays. Also tweak the description of the enterprise policy slightly to reduce confusion. BUG=1197149,1219499 Change-Id: Iee413582ee218f5310d3e3b4e7702541f7965942 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2964893 Commit-Queue: Adam Rice <ricea@chromium.org> Reviewed-by: Matt Menke <mmenke@chromium.org> Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org> Cr-Commit-Position: refs/heads/master@{#893322}
https://bugs.webkit.org/show_bug.cgi?id=226971 <rdar://problem/79287147> Reviewed by Geoffrey Garen. LayoutTests/imported/w3c: Re-sync some WPT tests from upstream d41f24f to gain test coverage from: - web-platform-tests/wpt#29343 * web-platform-tests/fetch/api/request/request-bad-port.any-expected.txt: * web-platform-tests/fetch/api/request/request-bad-port.any.js: * web-platform-tests/fetch/api/request/request-bad-port.any.worker-expected.txt: * web-platform-tests/tools/wptserve/wptserve/utils.py: (isomorphic_decode): (isomorphic_encode): (is_bad_port): (http2_compatible): * web-platform-tests/websockets/Create-blocked-port.any-expected.txt: * web-platform-tests/websockets/Create-blocked-port.any.js: * web-platform-tests/websockets/Create-blocked-port.any.worker-expected.txt: * web-platform-tests/websockets/constants.sub.js: Added. (url_has_variant): (else.url_has_flag): (url_has_flag): (IsWebSocket): (CreateWebSocketNonAbsolute): (CreateWebSocketNonWsScheme): (CreateWebSocketNonAsciiProtocol): (CreateWebSocketWithAsciiSep): (CreateWebSocketWithBlockedPort): (CreateWebSocketWithSpaceInUrl): (CreateWebSocketWithSpaceInProtocol): (CreateWebSocketWithRepeatedProtocols): (CreateWebSocketWithRepeatedProtocolsCaseInsensitive): (CreateWebSocket): Source/WTF: Prevent connecting to ports 989 & 990 as per: - whatwg/fetch#1250 * wtf/URL.cpp: (WTF::portAllowed): Canonical link: https://commits.webkit.org/239016@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@279099 268f45cc-cd09-0410-ab3c-d52691b4dbfc
From my preliminary data from the Chrome dev channel, out of ports 26, 989, 990 and 2525, 99% of requests are for port 2525. The absolute numbers are small so it's not very meaningful. Still, it makes sense to me that blocking 2525 would be the most difficult. |
https://bugs.webkit.org/show_bug.cgi?id=226971 <rdar://problem/79287147> Reviewed by Geoffrey Garen. LayoutTests/imported/w3c: Re-sync some WPT tests from upstream d41f24fb67a2d65c to gain test coverage from: - web-platform-tests/wpt#29343 * web-platform-tests/fetch/api/request/request-bad-port.any-expected.txt: * web-platform-tests/fetch/api/request/request-bad-port.any.js: * web-platform-tests/fetch/api/request/request-bad-port.any.worker-expected.txt: * web-platform-tests/tools/wptserve/wptserve/utils.py: (isomorphic_decode): (isomorphic_encode): (is_bad_port): (http2_compatible): * web-platform-tests/websockets/Create-blocked-port.any-expected.txt: * web-platform-tests/websockets/Create-blocked-port.any.js: * web-platform-tests/websockets/Create-blocked-port.any.worker-expected.txt: * web-platform-tests/websockets/constants.sub.js: Added. (url_has_variant): (else.url_has_flag): (url_has_flag): (IsWebSocket): (CreateWebSocketNonAbsolute): (CreateWebSocketNonWsScheme): (CreateWebSocketNonAsciiProtocol): (CreateWebSocketWithAsciiSep): (CreateWebSocketWithBlockedPort): (CreateWebSocketWithSpaceInUrl): (CreateWebSocketWithSpaceInProtocol): (CreateWebSocketWithRepeatedProtocols): (CreateWebSocketWithRepeatedProtocolsCaseInsensitive): (CreateWebSocket): Source/WTF: Prevent connecting to ports 989 & 990 as per: - whatwg/fetch#1250 * wtf/URL.cpp: (WTF::portAllowed): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@279099 268f45cc-cd09-0410-ab3c-d52691b4dbfc
CC @ricea, @youennf, @annevk
Taking out our imperfect ban hammer again.
In the light of the recently published ALPACA attack, it might be worthwhile disallowing ports 989 and 990. We consider this the least controversial ports to add to the list, given they are assigned and below 1024.
One could also block port 2525, but that's... trickier?
Would be great if you, @ricea, could help us gather some numbers.
I know Microsoft did something in https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31971 and Chromium was considering something in https://bugs.chromium.org/p/chromium/issues/detail?id=1197149
Preview | Diff