Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Spectre. Show all posts

Zen 1 Vulnerability AMD Patchwork Proved Weak, Second Pass Issued


While AMD engineers have already patched their Zen 1 “Division by Zero” bug, it was not the end of their problems, as the company may have released a patch quickly, but perhaps a little too quickly: claims Borislav Petkov, an AMD Linux Engineer. He apparently fixed the issue concerning AMD with the original solution (mentioned in a statement published by Petkov). It is just another example of the challenges in protecting against potential attack routes.

According to the findings, AMD's CPU may have kept "stale quotient data" within its registers even after the patchwork was over, consequently providing attackers with a window to retrieve private information. The original fix was to conduct a final “dummy division 0/1 before returning from the #DE exception handler.” The idea is quite straightforward: after completing the 0/1 division, which always yields zero results, any remaining old data would be eliminated.

The drawback of the fix, explained by Petkov, was that the speculative execution attack would have progressed too far by the time that the security feature took effect. There would already be some outdated data on AMD's divider, which the attackers could access before the dummy division kicked in. 

Petkov notes that his new solution now upholds that same division in several scenarios:

"Initially, it was thought that doing an innocuous division in the #DE handler would take care to prevent any leaking of old data from the divider but by the time the fault is raised, the speculation has already advanced too far and such data could already have been used by younger operations,” says Petkov. “Therefore, do the innocuous division on every exit to userspace so that userspace doesn't see any potentially old data from integer divisions in kernel space[…]Do the same before VMRUN too, to protect host data from leaking into the guest too,"

Similar instances indicate how busy this month turned out to be for vulnerabilities in the CPU realm, for both AMD and Intel. From Intel’s severe Downfall vulnerability (affecting Skylake through Tiger Lake/Rocket Lake) to AMD's SQUIP and Inception vulnerabilities and the now re-fixed "divide by zero" vulnerability, researchers have shown much determination in solving the issues. 

However, while these new issues are connected to speculative execution vulnerabilities, they still do not come close to the illustrious history of Meltdown and Spectre days. Speculative execution describes how contemporary CPUs attempt to foresee calculation steps before they are even required, ensuring that the essential data is already available in the event that the execution is asked for. Although several of those vulnerabilities' remedies resulted in (often significant) performance costs, it is at least encouraging that AMD's 0/1 dummy division does not have any additional expenses.

Spook.js: Chrome is Threatened by a New Spectre Like Attack

 

A newly found side-channel attack targeting Google Chrome might allow an attacker to use a Spectre-style attack to bypass the web browser's security protections and extract sensitive information. Spook.js is a novel transient execution side-channel attack that specifically targets Chrome. Despite Google's efforts to minimize Spectre by installing Strict Site Isolation, malicious JavaScript code can still extract information in some instances. 

An attacker-controlled webpage can learn which other pages from the same website a user is presently viewing, collect sensitive information from these pages, and even recover auto-filled login credentials (e.g., username and password). If a user downloads a malicious extension, the attacker may obtain data from Chrome extensions (such as credential managers). 

Spectre, which made news across the world in 2018, makes use of vulnerabilities in contemporary CPU optimization features to get around security measures that prohibit separate programmes from accessing one other's memory space. This enabled attackers to steal sensitive information across several websites by attacking how different applications and processes interact with processors and on-chip memory, allowing a wide range of attacks against different types of applications, including web apps. 

Strict Site Isolation was implemented by Google Chrome, which prohibits several web pages from sharing the same process. It also divided each process's address space into separate 32-bit sandboxes (despite being a 64-bit application). 

Site Isolation is a Chrome security feature that provides extra protection against some sorts of security vulnerabilities. It makes it more difficult for websites that aren't trustworthy to get access to or steal information from your accounts on other websites.

Despite these safeguards, Spook.js, according to researchers from the University of Michigan, University of Adelaide, Georgia Institute of Technology, and Tel Aviv University, "shows that these countermeasures are insufficient in order to protect users from browser-based speculative execution attacks." 

“More specifically, we show that Chrome’s Strict Site Isolation implementation consolidates webpages based on their eTLD+1 domain, allowing an attacker-controlled page to extract sensitive information from pages on other subdomains,” they said. "Next, we also show how to bypass Chrome’s 32-bit sandboxing mechanism. We achieve this by using a type confusion attack, which temporarily forces Chrome’s JavaScript engine to operate on an object of the wrong type."

“Web developers can immediately separate untrusted, user-supplied JavaScript code from all other content for their website, hosting all user-supplied JavaScript code at a domain that has a different eTLD+1," the study recommended. “This way, Strict Site Isolation will not consolidate attacker-supplied code with potentially sensitive data into the same process, putting the data out of reach even for Spook.js as it cannot cross process boundaries."

Google Issues a Warning about Spectre Attacks using JavaScript

 

It's been over a long time since researchers uncovered a couple of security vulnerabilities, known as Spectre and Meltdown, that further revealed fundamental flaws in how most present-day PC processors handle the information to maximize efficiency. While they influence a cosmic number of computing devices, the so-called speculative execution bugs are generally hard to misuse in practice. However, presently researchers from Google have built up a proof-of-concept that shows the risk Spectre assaults pose to the browser—in hopes of motivating a new generation of defenses. 

Google in 2018 detailed two variations of Spectre, one of which – named variation 1 (CVE-2017-5753) – concerned JavaScript exploitation against browsers. Google released the PoC for engineers of web applications to comprehend why it's critical to send application-level mitigations. At a high level, as detailed in a Google document on W3C, a developer's "data must not unexpectedly enter an attacker's process". 

While the PoC shows the JavaScript Spectre assault against Chrome 88's V8 JavaScript engine on an Intel Core i7-6500U 'Skylake' CPU on Linux, Google notes it can without much of a stretch be changed for different CPUs, browser versions, and operating systems. It was even successful on Apple's M1 Arm CPU with minor alterations. The assault can leak information at a pace of 1kB each second. The chief components of the PoC are a Spectre version 1 "device" or code that triggers attacker-controlled transient execution, and a side-channel or "a way to observe side effects of the transient execution". 

"The web platform relies on the origin as a fundamental security boundary, and browsers do a pretty good job at preventing explicit leakage of data from one origin to another," explained Google's Mike West. "Attacks like Spectre, however, show that we still have work to do to mitigate implicit data leakage. The side-channels exploited through these attacks prove that attackers can read any data which enters a process hosting that attackers' code. These attacks are quite practical today, and pose a real risk to users."

Google has likewise released another prototype Chrome extension called Spectroscope that scans an application to discover assets that may require enabling additional defenses.

Spectre Rises Yet Again With a Vulnerability In Tow


Spectre ,a class of vulnerabilities in the theoretical execution mechanism utilized in present day modern processor chips, is indeed living up to its name by ending up being unkillable.

In the midst of a progression of alleviations proposed by Intel, Google and others, the on-going claims by Dartmouth computer scientists to have comprehended Spectre variation 1, and a proposed chip configuration fix called Safespec, new variations and sub-variations continue showing up.

The discoveries likewise restore questions about whether the present and past chip plans can ever be really fixed. Just two weeks back, new data-stealing exploits named Ghost 1.1 and 1.2 were made public by specialists Vladimir Kiriansky and Carl Waldspurger. 


Presently there's another called SpectreRSB that endeavors the return stack buffer (RSB), a framework in the current modern CPUs utilized to help anticipate the return addresses, rather than the branch predictor unit.

In a paper titled Spectre Returns! Speculation Attacks utilizing the Return Stack Buffer , circulated through pre-print server ArXiv, boffins Esmaeil Mohammadian Koruyeh, Khaled Khasawneh, Chengyu Tune, and Nael Abu-Ghazaleh detail another class of Spectre Attack that accomplished the similar from Spectre variation 1 – enabling pernicious programming software to take passwords, keys, and other sensitive data, from memory it shouldn't be permitted to contact.

These specialists by coincidence, are among the individuals who built up the SafeSpec mitigation in the first place.

The most recent data-theft burglary system includes constraining the processor to misspeculate utilizing the RSB. Utilizing a call direction on x86, SpectreRSB enables an attacker to push an incentive to the RSB with the goal that the return address for the call guideline never again coordinates with the contents of the RSB.

The paper, dated July 20, plots the steps associated with the SpectreRSB attack, which itself has six variations:         

"(1) after a context switch to the attacker, s/he flushes shared address entries (for flush reload). The attacker also pollutes the RSB with the target address of a payload gadget in the victim’s address space; (2) the attacker yields the CPU to the victim; (3) The victim eventually executes a return, causing speculative execution at the address on the RSB that was injected by the attacker. Steps 4 and 5 switch back to the attacker to measure the leakage."

Multiple New Spectre CPU Flaws Revealed


According to a report by C’T magazine, researchers have found several data-leaking Spectre CPU vulnerabilities in Intel chips, which they are calling “Spectre Next Generation” or Spectre-NG.

There are reportedly eight new CVE-listed vulnerabilities, which Intel has not confirmed for now. The company, however, has confirmed the reservation of Common Vulnerabilities and Exposures (CVE) numbers, which is part of the investigation and mitigation of possible issues.

"So far we only have concrete information on Intel's processors and their plans for patches. However, there is initial evidence that at least some ARM CPUs are also vulnerable," the report read.

According to the report, further research is also underway on whether the “closely related AMD processor architecture is also susceptible to the individual Spectre-NG gaps,” and to what extent.

The report also says that Intel is already working on its own patches for Spectre-NG and others in cooperation with the operating system manufacturers.

The company is reportedly planning on two waves of patches: first in May and another in August.

“We believe strongly in the value of coordinated disclosure and will share additional details on any potential issues as we finalize mitigations. As a best practice, we continue to encourage everyone to keep their systems up-to-date,” Leslie Culbertson, Executive Vice President and General Manager of Product Assurance and Security at Intel Corporation, said in a statement on Thursday, addressing questions regarding security issues.