ISPs worry a new Chrome feature will stop them from spying on you

ISPs worry a new Chrome feature will stop them from spying on you

Enlarge (credit: Thomas Trutschel/Photothek via Getty Images)

When you visit a new website, your computer probably submits a request to the domain name system (DNS) to translate the domain name (like arstechnica.com) to an IP address. Currently, most DNS queries are unencrypted, which raises privacy and security concerns. Google and Mozilla are trying to address these concerns by adding support in their browsers for sending DNS queries over the encrypted HTTPS protocol.

But major Internet service providers have cried foul. In a September 19 letter to Congress, Big Cable and other telecom industry groups warned that Google's support for DNS over HTTPS (DOH) "could interfere on a mass scale with critical Internet functions, as well as raise data-competition issues."

On Sunday, the Wall Street Journal reported that the House Judiciary Committee is taking these concerns seriously. In a September 13 letter, the Judiciary Committee asked Google for details about its DOH plans—including whether Google plans to use data collected via the new protocol for commercial purposes.

Read 18 remaining paragraphs | Comments

Google, Microsoft work together for a year to figure out new type of Windows flaw

Google, Microsoft work together for a year to figure out new type of Windows flaw

Enlarge (credit: Marco Verch / Flickr)

One of the more notable features of Google Project Zero's (GPZ) security research has been its 90-day disclosure policy. In general, vendors are given 90 days to address issues found by GPZ, after which the flaws will be publicly disclosed. But sometimes understanding a flaw and developing fixes for it takes longer than 90 days—sometimes, much longer, such as when a new class of vulnerability is found. That's what happened last year with the Spectre and Meltdown processor issues, and it has happened again with a new Windows issue.

Google researcher James Forshaw first grasped that there might be a problem a couple of years ago when he was investigating the exploitability of another Windows issue published three years ago. In so doing, he discovered the complicated way in which Windows performs permissions checks when opening files or other secured objects. A closer look at the involved parts showed that there were all the basic elements to create a significant elevation of privilege attack, enabling any user program to open any file on the system, regardless of whether the user should have permission to do so. The big question was, could these elements be assembled in just the right way to cause a problem, or would good fortune render the issue merely theoretical?

The basic rule is simple enough: when a request to open a file is being made from user mode, the system should check that the user running the application that's trying to open the file has permission to access the file. The system does this by examining the file's access control list (ACL) and comparing it to the user's user ID and group memberships. However, if the request is being made from kernel mode, the permissions checks should be skipped. That's because the kernel in general needs free and unfettered access to every file.

Read 15 remaining paragraphs | Comments

Google: Software is never going to be able to fix Spectre-type bugs

Google: Software is never going to be able to fix Spectre-type bugs

Enlarge (credit: Aurich Lawson / Getty Images)

Researchers from Google investigating the scope and impact of the Spectre attack have published a paper asserting that Spectre-like vulnerabilities are likely to be a continued feature of processors and, further, that software-based techniques for protecting against them will both impose a high performance cost. In any case, the researchers continue, the software will be inadequate—some Spectre flaws don't appear to have any effective software-based defense. As such, Spectre is going to be a continued feature of the computing landscape, with no straightforward resolution.

The discovery and development of the Meltdown and Spectre attacks was undoubtedly the big security story of 2018. First revealed last January, new variants and related discoveries were made throughout the rest of the year. Both attacks rely on discrepancies between the theoretical architectural behavior of a processor—the documented behavior that programmers depend on and write their programs against—and the real behavior of implementations.

Specifically, modern processors all perform speculative execution; they make assumptions about, for example, a value being read from memory or whether an if condition is true or false, and they allow their execution to run ahead based on these assumptions. If the assumptions are correct, the speculated results are kept; if it isn't, the speculated results are discarded and the processor redoes the calculation. Speculative execution is not an architectural feature of the processor; it's a feature of implementations, and so it's supposed to be entirely invisible to running programs. When the processor discards the bad speculation, it should be as if the speculation never even happened.

Read 10 remaining paragraphs | Comments

Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0

A green exterior door is sealed with a padlock.

Enlarge (credit: Indigo girl / Flickr)

Apple, Google, Microsoft, and Mozilla have announced a unified plan to deprecate the use of TLS 1.0 and 1.1 early in 2020.

TLS (Transport Layer Security) is used to secure connections on the Web. TLS is essential to the Web, providing the ability to form connections that are confidential, authenticated, and tamper-proof. This has made it a big focus of security research, and over the years, a number of bugs that had significant security implications have been found in the protocol. Revisions have been published to address these flaws.

The original TLS 1.0, heavily based on Netscape's SSL 3.0, was first published in January 1999. TLS 1.1 arrived in 2006, while TLS 1.2, in 2008, added new capabilities and fixed these security flaws. Irreparable security flaws in SSL 3.0 saw support for that protocol come to an end in 2014; the browser vendors now want to make a similar change for TLS 1.0 and 1.1.

Read 2 remaining paragraphs | Comments