Google Chrome minted a new release to fix a trio of bugs on Monday, with exploit code already in the wild for one of them. The first two bugs don’t have much information published yet. They are an integer-overflow problem in Unicode internationalization, and a memory access issue in streams. The third issue, type confusion in V8, was also fixed quietly, but a team at Exodus Intel took the time to look at the patches and figure out what the problem was.
The Chrome Problem that Wasn’t
A second Chrome story came across my desk this week: Chrome 80 introduces a new feature, ScrollToTextFragment. This useful new feature allows you to embed a string of text in a URL, and when loading that address, Chrome will scroll the page to make that text visible. For certain use cases, this is an invaluable feature. Need to highlight a specific bit of text in a big document online?
The following bookmarklet code by [Paul Kinlan] is the easy way to start using this feature. Paste this code into the URL of a bookmark, put it on the bookmark bar, highlight some text in a webpage, and then run the bookmarklet. It should open a new tab with the new URL, ready to use or send to someone.
Since we’re talking about it in the security column, there must be more to the story. A privacy guru at Brave, [Peter Snyder], raised concerns about privacy implications of the feature. His argument has been repeated and misrepresented in a few places. What argument was he making? Simply put, that it’s not normal user behavior to immediately scroll to an exact position on the page. Because modern web pages and browsers do things like deferred loading of images, it could be possible to infer where in the page the link was pointing. He gives the example of a corporate network where DNS is monitored. This isn’t suggesting that the entire URL is leaked over DNS, but rather that DNS can indicate when individual components of a page are loaded, particularly when they are embedded images from other sites.
While this concern isn’t nonsensical, it seems to me to be a very weak argument that is being over-hyped in the press.
Whatsapp Groups Searchable on Google
It’s not new for search engines to index things that weren’t intended to be public. There is a bit of mystery surrounding how Google finds URLs to index, and StackExchange is full of plenty of examples of webadmins scratching their heads at their non-public folders showing up in a Google search.
That said, a story made the rounds in the last few days, that WhatsApp and Telegram group invites are being indexed by Google. So far, the official word is that all the indexed links must have been shared publicly, and Google simply picked them up from where they were publicly posted.
It appears that WhatsApp has begun marking chat invitation links as “noindex”, which is a polite way to ask search engines to ignore the link.
If it’s shown that links are getting indexed without being posted publicly online, then we have a much bigger story. Otherwise, everything is working as expected.
Letsencrypt Makes Attacks Harder
Letsencrypt has rolled out an invisible change to their validation process that makes a traffic redirection attack much harder. The new feature, Multi-Perspective Validation, means that when you verify your domain ownership, Letsencrypt will test that verification from multiple geographic regions. It might be possible to spoof ownership of a domain through a BGP attack, but that attack would be much harder to pull off against traffic originating from another country, or multiple countries simultaneously. Letsencrypt is currently using different regions of a single cloud, but plans to further diversify and use multiple cloud providers for even stronger validation.
Brought to us by the researchers at Eset, Krook (PDF) is a simple flaw in certain wireless chips. So far, the flaw seems to be limited to WPA2 traffic sent by Broadcom and Cypress chips. They discovered Kr00k while doing some followup research on KRACK.
Let’s talk about WPA2 for a moment. WPA2 has a 4-way handshake process that securely confirms that both parties have the shared key, and then establishes a shared Temporal Key, also known as a session key. This key is private between the two devices that performed the handshake, meaning that other devices on the same wireless network can’t sniff traffic sent by other devices.
When a device disconnects, or disassociates, that session key is reset to all 0s, and no packets should be sent until another handshake is performed. Here’s the bug: The packets already in the output buffer are still sent, but are encrypted with the zeroed key, making them trivially decrypted. As it’s simple to trigger deauthentication events, an attacker can get a sampling of in-the-clear packets. The ubiquity of TLS is a saving grace here, but any unencrypted traffic is vulnerable. Eset informed vendors about the flaw in 2019, and at least some devices have been patched.
Microsoft Exchange got a security patch this past Tuesday that addressed a pair of bugs that together resulted in a remote code execution vulnerability. The first bug was an encryption key that is generated on Exchange server installation. That generation seemed to lack a good source of entropy, as apparently every Exchange install uses the the exact same key.
The second half of this bug is a de-serialization problem, where an encrypted payload can contain a command to run. Because the encryption key is known, any user can access the vulnerable endpoint. The process of exploitation is so trivial, be sure to patch your server right away.
TODO: Remove Vulnerabilities
This one is just humorous. An Intel virtualization feature appears to have been pushed into the Linux kernel before it was finished. Know what unfinished code tends to contain? Bugs and vulnerabilities. CVE-2020-2732, in this case. It’s unclear how exactly an exploit would work, but the essence is that a virtual guest is allowed to manipulate system state in unintended ways.