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

Researcher finds building blocks for privilege escalation: Can they be assembled to create a 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

Researchers also devise a Spectre-like attack with no known mitigation.

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

Almost everyone has now migrated to TLS 1.2, and a few have moved to TLS 1.3.

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

Google taking new steps to prevent malicious Chrome extensions

Company plans stricter rules for developers, and greater control for users.

Article intro image

Google has announced plans to further restrict Chrome extensions in a bid to crack down on the number of malicious extensions found in the Chrome Web Store.

We've seen a spate of malicious extensions this year; the extensions do things like steal credentials and participate in click fraud schemes. The malicious extensions take advantage of the considerable access to Web pages that extensions have.

Google has already taken some steps to limit malicious extensions. Last year, a stricter multi-process model was applied to extensions to limit the impact of security flaws in the browser, and earlier this year Google deprecated the ability for extensions to offer installation from third-party websites (instead forcing all installations to go via the Chrome Web Store). This feature will be fully removed in Chrome 71 in December.

Read 5 remaining paragraphs | Comments