Chrome 87 Released With Fix for NAT Slipstream Attacks, Broader FTP Deprecation (zdnet.com) 38
Google has released today version 87 of its Chrome browser, a release that comes with a security fix for the NAT Slipstream attack technique and a broader deprecation of the FTP protocol. From a report: Todays' release is available for Windows, Mac, Linux, Chrome OS, Android, and iOS. Users can update to the new version via Chrome's built-in update utility. While in previous versions, Google has shipped some changes to Chrome settings and UI elements, almost all the major new Chrome 87 features are aimed at web developers. In Chrome 87, we have new APIs and updates to Chrome's built-in Developer Tools, such as: Support for the new Cookie Store API; new features to allow easier modification of web fonts via CSS; a new feature to let websites enumerate all the locally installed fonts; support for pan, tilt, and zoom controls on webcam streams; and, support for debugging WebAuthn operations via the Chrome DevTools.
Fingerprinting (Score:5, Insightful)
"let websites enumerate all the locally installed fonts"
The only reason to allow such misfeatures is to actively encourage fingerprinting.
Re: (Score:3)
Re: (Score:2, Troll)
You dont belong on slashdot and neither does anyone who modded you up.
Re: (Score:2)
Why do you care what someone is saying, when the fact on the table is "let websites enumerate the locally installed fonts" You dont belong on slashdot and neither does anyone who modded you up.
From Merk's link the feature sounds like it requires user opt-in, just like when a website wants to access your webcam or mic.
I know reading the article, links or even the summary isn't considered "cool" here, but come on now.
Re: (Score:2)
Or to allow web-based office suites to actually offer more than the paltry amount of fonts they do? After all, it's by Google who has Google Docs and no application based office suite.
Of course, it is already misused (see panopticlick by EFF) so I'm guessing there will be support for it in things liek ScriptSafe.
Removing ftp (Score:4, Insightful)
I don't see what problem removing ftp support is supposed to be solving.
Sure, it's an old and not-particularly-secure way to transfer files, but there's a ton of stuff that uses it.
Is it just to make users complain so "someone in charge" will change their systems to use a protocol other than ftp? Why?
Re:Removing ftp (Score:5, Insightful)
Re: (Score:2)
If by 'open web' you mean 'all communications unencrypted' or 'insecure protocols' then you are right.
Re:Removing ftp (Score:5, Informative)
Re: (Score:3)
Re: (Score:2)
this was foreseen ten years ago. (Score:2, Insightful)
someone asked why Chromium failed to support Gopher which was actively used at his university. he said, "But I'm worried with the comment made by eroman@chromium.org: if 'other clients can be used for that purpose' is a valid reason to refuse a protocol, then why does Chromium support FTP? There are other clients for that, too!"
Never let it be said that Google is deaf to user feedback! They solved this problem good by getting rid of FTP.
Re: (Score:3)
I don't see what problem removing ftp support is supposed to be solving.
Sure, it's an old and not-particularly-secure way to transfer files, but there's a ton of stuff that uses it.
Is it just to make users complain so "someone in charge" will change their systems to use a protocol other than ftp? Why?
I was a bit more annoyed when Filezilla started acting like plain FTP connectivity is a terrible thing to expect from an FTP client.
everything is security now i guess (Score:3)
i am very torn about this.
i love the simplicity of ftp, telnet, smtp, html, these are the whole foundational ethos of the internet - the replacement of overly complex over engineered hierarchical network systems with plain, simple stuff that anyone can wrap their head around in a few minutes. you used to be able to telnet to an email server and send an email
but .... i feel like that was some kind of civilization of a distant past age, ... before the bandit hordes came crashing over the cities and burning ev
Re:Removing ftp (Score:4, Informative)
FTP is a handy protocol for NAT slipstreaming. They can play whack-a-mole whenever a new security issue appears, or they can simply drop the support and leave FTP to FTP clients. The latter seems like the easier option.
Re: (Score:2)
Re:Removing ftp (Score:4, Insightful)
Re: (Score:2)
Who wants to use a web browser for FTP, though? That's a file manager's job.
Re: (Score:1)
Who wants to use a web browser for ftp?
The guy who just found the file that he needs with a search engine using his web browser and wants to click the link to download it. Sure, he could to copy the link and fire up a different program and download it that way, but it's a lot more work than "click-and-there-you-have-it."
Re: (Score:1)
Unstable.. (Score:1)
#DeleteFacebook while using "Google" Chrome (Score:1)
WebRTC lunacy and slipstream (Score:2)
I have not been able to quite understand why browser vendors sought it as a good idea to release browsers which by DEFAULT divulge every users internal network addresses to any yahoo on the Internet requesting it. (Firefox media.peerconnection.ice.no_host). Great for chatting with people in the same office or household but these are exceptional cases that do not warrant mass enablement by default.
Also just wanted to highlight the fact NAT ALGs suck. If you wanted a reason why SPI is better than 1:m NAT...
Re: (Score:2)
The way I see it, there's not a lot of difference between say fe80::d447:3eef:8752:1838 and 2a02:c7f:1f08:cc00:d447:3eef:8752:1838 as the latter is exposed to the world and the former can only be accessed from behind my router but they both give off the same identifying info. Likewise, giving out 172.16.18.19 alongside say 94.0.155.81 isn't going to hurt.
At the end of the day a computer can and will identify itself to many othe
Re: (Score:2)
...and how does knowing some rando's local network IP compromise anything?
While TFA pointed to one way that can happen "NAT slipstream" the salient issue is unnecessary privacy infringement for no gain.
The way I see it, there's not a lot of difference between say fe80::d447:3eef:8752:1838 and 2a02:c7f:1f08:cc00:d447:3eef:8752:1838 as
The reason IPv6 privacy addresses exist (and are enabled by default on most Operating systems) is explicitly to prevent exposure of the users MAC address.
There are no benefits to users in allowing these protections to be bypassed.
the latter is exposed to the world and the former can only be accessed from behind my router but they both give off the same identifying info.
Behind your router like from where your web browser is located? Any site you visit can cause your browser to access http accessible systems behind your
Re: (Score:2)
This is incorrect. The only requirement for Internet communications are unique globally addressable network identifiers. You've failed to enumerate even a single coherent reason why internal addresses must be leaked for ANYTHING to work. The fact of the matter is there is no upside in doing so and only downsides for users.
On IPv4, there is a benefit when you have many computers potentially using the same ports from multiple private hosts behind a NAT. SIP "leaks" private IPs too, by design. So does the use of any protocol which makes use of STUN.
On IPv6, the benefit is clear. People have Static IP addresses for a myriad of reasons, including smoother IPSec integration, site-to-site VPNs and to be able to use older secure RPC protocols. IPv6 Privacy Extensions provide temporary IPs, giving you all the down sides of having
Re: (Score:2)
On IPv4, there is a benefit when you have many computers potentially using the same ports from multiple private hosts behind a NAT.
This makes no sense. NATs don't concurrently reuse the same src/dst+ip/port tuples internally or externally and ports alone are not session identifying. Local candidates only need to be advertised to establish local communications.
On IPv6, the benefit is clear. People have Static IP addresses for a myriad of reasons, including smoother IPSec integration, site-to-site VPNs and to be able to use older secure RPC protocols. IPv6 Privacy Extensions provide temporary IPs, giving you all the down sides of having a Dynamic IP.
In the real world most people with IPv6 connectivity are using IPv6 privacy addresses because that is what happens by default when you plug the little wire into the little plastic box your ISP gave you or connect wifi to whatever the little sticker on the little plastic box says
Re: (Score:2)
This makes no sense. NATs don't concurrently reuse the same src/dst+ip/port tuples internally or externally and ports alone are not session identifying. Local candidates only need to be advertised to establish local communications.
Have you never had legacy SIP phones all listen and bind to the same ports behind one public IP, expecting that their private IP be part of the wider Internet? The solution is STUN, which allows for one to negotiate a working data stream per-device over the NAT. This is what WebRTC uses and where the source of the issue lies because WebRTC by design is controlled by JavaScript APIs, which provide visibility of both sides of the connection, allowing someone to associate a private IP to a public IP.
The re
Re: (Score:2)
Have you never had legacy SIP phones all listen and bind to the same ports behind one public IP, expecting that their private IP be part of the wider Internet? The solution is STUN, which allows for one to negotiate a working data stream per-device over the NAT. This is what WebRTC uses and where the source of the issue lies because WebRTC by design is controlled by JavaScript APIs, which provide visibility of both sides of the connection, allowing someone to associate a private IP to a public IP.
The real security issue here is people allowing JavaScript to be executed within a web browser in the first place, as there are a myriad of identifiers one can synthesize by creating new, unique data or derive from existing data already in the browser to create a unique fingerprint. Likewise for internal network attacks as a result of using applications which only need public network access - even iOS is implementing this basic form of security.
All that matters to my remarks is that local non-routable addresses are being advertised in SDP messages to the peer from the browser. The only use of internal addresses by their peer is in establishing a direct connection when both peers are on the same local network. Knowledge of Internal addresses are not used to "associate a private IP to a public IP". The only things doing that are black box machinery inside NATs and in-band proxies.
Arguing that because fingerprinting is possible by other means that
Re: (Score:2)
A browser could for example implement a policy that says if the URL is a global address then no subsequent requests to local addresses would be allowed from anything following from the URL. A host firewall can't do that.
Yes it can. Ignoring iOS for a moment, on Windows the Base Filtering Engine (and by extension, Windows Firewall) supports all manner of tokens being used to control the allowing and denying of network access and the AppContainer integrity level already bans most types of loopback connections by default (at least for UWP apps) on the basis that not doing so would allow sandbox escape.
This means that an installer could easily set up appropriate rules during installation and then the main browser could eas
Re: (Score:2)
Privacy preserving features and design (privacy.resistFingerprinting..etc) may not be perfect yet this is no excuse to make things worse when there is no practical upside and only downsides for most people in doing so.
We all complained when Pentium CPUs started shipping with unique serial numbers. People complained as it could be used to deanonymise devices, so Intel stopped doing that. Fast forward a couple of years and along came motherboard serial numbers and pseudo-randomly generated device UUIDs. The moral of the story is that not everybody wants or needs anonymity and over the past 2-3 years people have begun conflating the idea of not being identifiable with privacy. Thanks to my devices being more identifiable t
Re: (Score:2)
We all complained when Pentium CPUs started shipping with unique serial numbers. People complained as it could be used to deanonymise devices, so Intel stopped doing that. Fast forward a couple of years and along came motherboard serial numbers and pseudo-randomly generated device UUIDs. The moral of the story is that not everybody wants or needs anonymity and over the past 2-3 years people have begun conflating the idea of not being identifiable with privacy. Thanks to my devices being more identifiable than ever before, they're also more reliable than ever before and I don't need to go around seeking out certified drivers by hand. ....
Things that everyday people need and expect to be able to use in a simple, standard, transparent way across a wide range of potential configurations necessitates deanonymisation in some form, ditto for supporting backwards compatibility as technology adapts.
WTF is this shit? This is fucking crazy. Hopping from one disjoined idea to another to another to another to another... Instead of addressing the actual issue at hand which is why is it necessary for local addresses to be announced in SDP ... you go on and on about CPUs and UUIDs and then fucking certified drivers.. what the fucking hell? Seriously enough of the bullshit. Either address the specific issue of local addresses in SDP or don't the sidecars are fucking annoying as shit and do nothing to a
Re: (Score:2)
Instead of addressing the actual issue at hand which is why is it necessary for local addresses to be announced in SDP
Simple example: Thousands of computers at multiple sites linked via MPLS, each site presenting the same public IP as their Internet connections all end up at the same point; advertising all IPs means that one can take the most logical route (i.e. not sending traffic to be processed at the edge of the network). Those peers need to talk across a WAN, their addresses aren't local but they still use an IPv4 private IP range as one would on a home LAN.
More complicated example: A bunch of networks, each with
Slipstream attack (Score:3)
The Slipstream attack is extremely clever, but isn't it really a bug in the NAT box? If the "fragment offset" of an IP packet is non-zero, the NAT box should not try to interpret it for connection-tracking. Am I missing something?
Now with Ads! (Score:2)
Re: (Score:2)
Just installed it. My new tabs now contain two ads in my "top sites" list.
Supporting documentation. [mozilla.org]
Ambivalent on this (Score:2)
While it is a bad thing and indented to fark people over I have alwasy though a web browser was a dumb thing to be doing ftp in.
I also on the whoole do not touch chrome with a barge pole.
It is not even installed on my win box (firefox, pale moon, and chromy edge are as far as I go). (and this is coming from me a person very entwined in google (well half google half amazon, maybe a bit of ms)).
I don't even use it on android. Thats firefox too mainly. Some google apps do ignore my preference though. (and same