wolfSSL before 5.4.0 allows remote attackers to cause a denial of service via DTLS because a check for return-routability can be skipped.

Note:  
\*\* Future releases of wolfSSL will turn off TLS 1.1 by default  
\*\* Release 5.4.0 made SP math the default math implementation. To make an equivalent build as –disable-fastmath from previous versions of wolfSSL, now requires using the configure option –enable-heapmath instead.

Release 5.4.0 of wolfSSL embedded TLS has bug fixes and new features including:

**Vulnerabilities**

*   \[High\] Potential for DTLS DoS attack. In wolfSSL versions before 5.4.0 the return-routability check is wrongly skipped in a specific edge case. The check on the return-routability is there for stopping attacks that either consume excessive resources on the server, or try to use the server as an amplifier sending an excessive amount of messages to a victim IP. If using DTLS 1.0/1.2 on the server side users should update to avoid the potential DoS attack. CVE-2022-34293
*   \[Medium\] Ciphertext side channel attack on ECC and DH operations. Users on systems where rogue agents can monitor memory use should update the version of wolfSSL and change private ECC keys. Thanks to Sen Deng from Southern University of Science and Technology (SUSTech) for the report.
*   \[Medium\] Public disclosure of a side channel vulnerability that has been fixed since wolfSSL version 5.1.0. When running on AMD there is the potential to leak private key information with ECDSA operations due to a ciphertext side channel attack. Users on AMD doing ECDSA operations with wolfSSL versions less than 5.1.0 should update their wolfSSL version used. Thanks to professor Yinqian Zhang from Southern University of Science and Technology (SUSTech), his Ph.D. student Mengyuan Li from The Ohio State University, and his M.S students Sen Deng and Yining Tang from SUStech along with other collaborators; Luca Wilke, Jan Wichelmann and Professor Thomas Eisenbarth from the University of Lubeck, Professor Shuai Wang from Hong Kong University of Science and Technology, Professor Radu Teodorescu from The Ohio State University, Huibo Wang, Kang Li and Yueqiang Cheng from Baidu Security and Shoumeng Yang from Ant Financial Services Group.  
    CVE-2020-12966 https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1013 CVE-2021-46744 https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1033

**New Feature Additions****DTLS 1.3**

*   Support for using the new DTLSv1.3 protocol was added
*   Enhancements to bundled examples for an event driven server with DTLS 1.3 was added

**Ports**

*   Update for the version of VxWorks supported, adding in support for version 6.x
*   Support for new DPP and EAP-TEAP/EAP-FAST in wpa\_supplicant
*   Update for TSIP version support, adding support for version 1.15 for RX65N and RX72N
*   Improved TSIP build to handle having the options WOLFSSL\_AEAD\_ONLY defined or NO\_AES\_CBC defined
*   Added support for offloading TLS1.3 operations to Renesas RX boards with TSIP

**Misc.**

*   Constant time improvements due to development of new constant time tests
*   Initial translation of API headers to Japanese and expansion of Japanese help message support in example applications
*   Add support for some FPKI (Federal PKI) certificate cases, UUID, FASC-N, PIV extension for use with smart cards
*   Add support for parsing additional CSR attributes such as unstructured name and content type
*   Add support for Linux getrandom() when defining the macro WOLFSSL\_GETRANDOM
*   Add TLS 1.2 ciphersuite ECDHE\_PSK\_WITH\_AES\_128\_GCM\_SHA256 from RFC 8442
*   Expand CAAM support with QNX to include i.MX8 boards and add AES-CTR support
*   Enhanced glitching protection by hardening the TLS encrypt operations

**Math and Performance****SP Math Additions**

*   Support for ARMv3, ARMv6 and ARMv7a
    *   Changes and improvements to get SP building for armv7-a
    *   Updated assembly for moving large immediate values on ARMv6
    *   Support for architectures with no ldrd/strd and clz
*   Reworked generation using common asm ruby code for 32bit ARM
*   Enable wolfSSL SP math all by default (sp\_int.c)
*   Update SP math all to not use sp\_int\_word when SQR\_MUL\_ASM is available

**SP Math Fixes**

*   Fixes for constant time with div function
*   Fix casting warnings for Windows builds and assembly changes to support XMM6-15 being non-volatile
*   Fix for div\_word when not using div function
*   Fixes for user settings with SP ASM and ED/Curve25519 small
*   Additional Wycheproof tests ran and fixes
*   Fix for SP math ECC non-blocking to always check hashLen
*   Fix for SP math handling edge case with submod

**Improvements and Optimizations****Compatibility Layer**

*   Provide access to "Finished" messages outside of compatibility layer builds
*   Remove unneeded FIPS guard on wolfSSL\_EVP\_PKEY\_derive
*   Fix control command issues with AES-GCM, control command EVP\_CTRL\_GCM\_IV\_GEN
*   Add support for importing private only EC key to a WOLFSSL\_EVP\_PKEY struct
*   Add support for more extensions to wolfSSL\_X509\_print\_ex
*   Update for internal to DER (i2d) AIPs to move the buffer pointer when passed in and the operation is successful
*   Return subject and issuer X509\_NAME object even when not set

**Ports**

*   Renesas RA6M4 example update and fixes
*   Support multi-threaded use cases with Renesas SCE protected mode and TSIP
*   Add a global variable for heap-hint for use with TSIP
*   Changes to support v5.3.0 cube pack for STM32
*   Use the correct mutex type for embOS
*   ESP-IDF build cleanup and enhancements, adding in note regarding ESP-IDF Version
*   Support for SEGGER embOS and emNET
*   Fix to handle WOLFSSL\_DTLS macro in Micrium build

**Build Options**

*   Support for verify only and no-PSS builds updated
*   Add the enable options wolfssh (mapped to the existing –enable-ssh)
*   Remove WOLFSSL\_ALT\_NAMES restriction on notBefore/notAfter use in Cert struct
*   Move several more definitions outside the BUILDING\_WOLFSSL gate with linux kernel module build
*   Modify --enable-openssh to not enable non-FIPS algos for FIPS builds
*   Remove the Python wrappers from wolfSSL source (use pip install instead of using wolfSSL with Python and our separate Python repository)
*   Add --enable-openldap option to configure.ac for building the OpenLDAP port
*   Resolve DTLS build to handle not having –enable-hrrcookie when not needed
*   Add an --enable-strongswan option to configure.ac for building the Strongswan port
*   Improve defaults for 64-bit BSDs in configure
*   Crypto only build can now be used openssl extra
*   Update ASN template build to properly handle WOLFSSL\_CERT\_EXT and HAVE\_OID\_ENCODING
*   Allow using 3DES and MD5 with FIPS 140-3, as they fall outside of the FIPS boundary
*   Add the build option --enable-dh=const which replaces setting the macro WOLFSSL\_DH\_CONST and now conditionally link to -lm as needed
*   Add the macro WOLFSSL\_HOSTNAME\_VERIFY\_ALT\_NAME\_ONLY which is used to verify hostname/ip address using alternate name (SAN) only and does not use the common name
*   WOLFSSL\_DTLS\_NO\_HVR\_ON\_RESUME macro added (off by default to favor more security). If defined, a DTLS server will not do a cookie exchange on successful client resumption: the resumption will be faster (one RTT less) and will consume less bandwidth (one ClientHello and one HelloVerifyRequest less). On the other hand, if a valid SessionID is collected, forged clientHello messages will consume resources on the server.
*   Misc.
*   Refactoring of some internal TLS functions to reduce the memory usage
*   Make old less secure TimingPadVerify implementation available
*   Add support for aligned data with clang LLVM
*   Remove subject/issuer email from the list of alt. Email names in the DecodedCerts struct
*   Zeroizing of pre-master secret buffer in TLS 1.3
*   Update to allow TLS 1.3 application server to send session ticket
*   Improve the sniffer asynchronous test case to support multiple concurrent streams
*   Clean up wolfSSL\_clear() and add more logging
*   Update to not error out on bad CRL next date if using NO\_VERIFY when parsing
*   Add an example C# PSK client
*   Add ESP-IDF WOLFSSL\_ESP8266 setting for ESP8266 devices
*   Support longer sigalg list for post quantum use cases and inter-op with OQS's OpenSSL fork
*   Improve AES-GCM word implementation of GMULT to be constant time
*   Additional sanity check with Ed25519/Ed448, now defaults to assume public key is not trusted
*   Support PSK ciphersuites in benchmark apps
*   FIPS in core hash using SHA2-256 and SHA2-384
*   Add ability to store issuer name components when parsing a certificate
*   Make the critical extension flags in DecodedCert always available
*   Updates to the default values for basic constraint with X509’s
*   Support using RSA OAEP with no malloc and add additional sanity checks
*   Leverage async code paths to support WANT\_WRITE while sending packet fragments
*   New azsphere example for continuous integration testing
*   Update RSA key generation function to handle pairwise consistency tests with static memory pools used
*   Resolve build time warning by passing in and checking output length with internal SetCurve function
*   Support DTLS bidirectional shutdown in the examples
*   Improve DTLS version negotiation and downgrade capability

**General Fixes**

*   Fixes for STM32 Hash/PKA, add some missing mutex frees, and add an additional benchmark
*   Fix missing return checks in KSDK ED25519 code
*   Fix compilation warnings from IAR
*   Fixes for STM32U5/H7 hash/crypto support
*   Fix for using track memory feature with FreeRTOS
*   Fixup XSTR processing for MICRIUM
*   Update Zephyr fs.h path
*   DTLS fixes with WANT\_WRITE simulations
*   Fixes for BER use with PKCS7 to have additional sanity checks and guards on edge cases
*   Fix to handle exceptional edge case with TFM mp\_exptmod\_ex
*   Fix for stack and heap measurements of a 32-bit build
*   Fix to allow enabling AES key wrap (direct) with KCAPI
*   Fix --enable-openssh FIPS detection syntax in configure.ac
*   Fix to move wolfSSL\_ERR\_clear\_error outside gate for OPENSSL\_EXTRA
*   Remove MCAPI project's dependency on zlib version
*   Only use \_\_builtin\_offset on supported GCC versions (4+)
*   Fix for c89 builds with using WOLF\_C89
*   Fix 64bit postfix for constants building with powerpc
*   Fixed async Sniffer with TLS v1.3, async removal of WC_HW_WAIT_E and sanitize leak
*   Fix for QAT ECC to gate use of HW based on marker
*   Fix the supported version extension to always check minDowngrade
*   Fix for TLS v1.1 length sanity check for large messages
*   Fixes for loading a long DER/ASN.1 certificate chain
*   Fix to expose the RSA public DER export functions with certgen
*   Fixes for building with small version of SHA3
*   Fix configure with WOLFSSL\_WPAS\_SMALL
*   Fix to free PKCS7 recipient list in error cases
*   Sanity check to confirm ssl->hsHashes is not NULL before attempting to dereference it
*   Clear the leftover byte count in Aes struct when setting IV

For additional vulnerability information visit the vulnerability page at:  
https://www.wolfssl.com/docs/security-vulnerabilities/

See INSTALL file for build instructions.  
More info can be found on-line at: https://wolfssl.com/wolfSSL/Docs.html

CVE-2022-34293: Release wolfSSL Release 5.4.0 (July 11, 2022) · wolfSSL/wolfssl

WordPress Testimonial Slider and Showcase plugin version 2.2.6 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Stored XSS in post_title parameter in WordPress Plugin "Testimonial Slider and Showcase" 2.2.6# Date: 05/08/2022# Exploit Author: saitamang , yunaranyancat , amd_syad# Vendor Homepage: wordpress# Software Link: https://wordpress.org/plugins/testimonial-slider-and-showcase/# Version: 2.2.6# Tested on: Centos 7 apache2 + MySQLWordPress Plugin "Testimonial Slider and Showcase" is prone to a cross-site scripting (XSS) vulnerability because it fails to properly sanitize user-supplied input. An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks. WordPress Plugin "Testimonial Slider and Showcase" version 2.2.6 is vulnerable; prior versions may also be affected.Login as Editor > Add testimonial > Under Title inject payload below ; parameter (post_title parameter) > Save Draft > Preview the postpayload --> test"/><img/src=""/onerror=alert(document.cookie)>The draft post can be viewed using Admin account and XSS will be triggered.

WordPress Testimonial Slider And Showcase 2.2.6 Cross Site Scripting

A race condition in the Linux kernel before 5.5.7 involving VT_RESIZEX could lead to a NULL pointer dereference and general protection fault.

CVE-2020-36558

Linus Torvalds says Retbleed has been addressed in the Linux kernel, but code complexity means the release will be delayed by a week to give more time for testing.

Linux kernel developers have successfully addressed Retbleed, the latest Spectre-like speculative execution attack against older AMD and Intel processors, Linus Torvalds wrote in a message to the Linux Kernel Mailing List on Sunday. However, the difficult repair process means there will be a delay of the release for Linux version 5.19 by a week.

"I think we've got the retbleed fallout all handled (knock wood)," Torvalds wrote.

The complexity of the fix wasn't the only reason for the release; there were two other development trees that independently asked for an extension. The other trees that needed the extension involve the btrfs filesystems and firmware for Intel GPU controllers.

"When we've had one of those embargoed \[hardware\] issues pending, the patches didn't get the open development, and then as a result missed all the usual sanity checking by all the automation build and test infrastructure we have," Torvalds explained. "So, 5.19 will be one of those releases that have an additional rc8 next weekend before the final release."

Last week, researchers at ETH Zurich announced the discovery of Retbleed, an addition to the family of speculative execution attacks that began with Meltdown and Spectre. The researchers named the family of these vulnerabilities Spectre-BTI after the attack method: via a branch target injection.

Unlike its siblings, Retbleed does not proceed via indirect jumps or calls, but instead uses return instructions. This is significant because it undermines some of the current Spectre-BTI protections, the researchers wrote.

In response, Intel and AMD issued advisories describing mitigations for CVE-2022-29901 (Intel CPUs) and CVE-2022-2990 (AMD CPUs).

**Speculative Execution Exploits Here to Stay**

The discovery follows Hertzbleed, discovered in June, which exploited a side-channel flaw in Intel and AMD processors, allowing remote attackers with low privileges to infer sensitive information by observing power-throttling changes in the CPU.

The attacks leverage weaknesses in the speculative execution process, a performance optimization technique in modern CPUs.

Other major speculative execution vulnerability exploits uncovered in recent years include Meltdown, Spectre, and SWAPGS.

A team of Google researchers published a deep analysis of the issue back in 2019, positing that chip makers' focus on performance has left microprocessors open to numerous side-channel attacks that cannot be fixed by software updates.

Some experts believe exploits like Spectre and Meltdown will force customers to make tradeoffs between performance and security of applications. They predict these types of threats will become much more dangerous in cloud and virtual environments.

A 2019 survey from Login VSI found patches negatively impacted performance for a fifth of those who applied them, with at times substantial performance reductions.

Retbleed Fixed in Linux Kernel, Patch Delayed

With speculative execution attacks remaining a stubbornly persistent vulnerability ailing modern processors, new research has highlighted an "industry failure" to adopting mitigations released by AMD and Intel, posing a firmware supply chain threat.
Dubbed FirmwareBleed by Binarly, the information leaking assaults stem from the continued exposure of microarchitectural attack surfaces on the part

With speculative execution attacks remaining a stubbornly persistent vulnerability ailing modern processors, new research has highlighted an "industry failure" to adopting mitigations released by AMD and Intel, posing a firmware supply chain threat.

Dubbed **FirmwareBleed** by Binarly, the information leaking assaults stem from the continued exposure of microarchitectural attack surfaces on the part of enterprise vendors either as a result of not correctly incorporating the fixes or only using them partially.

"The impact of such attacks is focused on disclosing the content from privileged memory (including protected by virtualization technologies) to obtain sensitive data from processes running on the same processor (CPU)," the firmware protection firm said in a report shared with The Hacker News.

"Cloud environments can have a greater impact when a physical server can be shared by multiple users or legal entities."

In recent years, implementations of speculative execution, an optimization technique that predicts the outcome and target of branch instructions in a program's execution pipeline, have been deemed susceptible to Spectre\-like attacks on processor architectures, potentially enabling a threat actor to leak cryptographic keys and other secrets.

This works by tricking the CPU into executing an instruction that accesses sensitive data in memory that would normally be off-limits to an unprivileged application and then extracting the data after the operation is undone following a misprediction.

A key countermeasure to prevent the harmful effects of speculative execution is a software defense known as retpoline (aka "Return Trampoline"), which was introduced in 2018.

Although recent findings such as Retbleed have conclusively shown that retpoline by itself is insufficient against stopping such attacks in certain scenarios, the latest analysis shows a lack of consistency in even applying these mitigations in the first place.

Specifically, it takes aim at a best practice called Return Stack Buffer (RSB) stuffing introduced by Intel to avoid underflows when using retpoline. RSBs are address predictors for return (aka RET) instructions.

"Certain processors may use branch predictors other than the Return Stack Buffer (RSB) when the RSB underflows," Intel notes in its documentation. "This might impact software using the retpoline mitigation strategy on such processors."

"On processors with different empty RSB behavior, \[System Management Mode\] code should stuff the RSB with CALL instructions before returning from SMM to avoid interfering with non-SMM usage of the retpoline technique."

Intel is also recommending RSB stuffing as a mechanism to thwart buffer underflow attacks like Retbleed, alternatively urging vendors to "set \[Indirect Branch Restricted Speculation\] before RET instructions at risk of underflow due to deep call stacks."

The Binarly research, however, has identified as many as 32 firmware from HP, 59 from Dell, and 248 from Lenovo as having not included the RSB stuffing patches, underscoring a "failure in the firmware supply chain."

What's more, the deep code analysis has unearthed instances wherein mitigation was present in the firmware, but contained implementation mistakes that spawned security issues of its own, even in updates released in 2022 and for devices featuring the recent generation of hardware.

"Firmware supply chain ecosystems are quite complex and often contain repeatable failures when it comes to applying new industry-wide mitigations or fixing reference code vulnerabilities," the researchers said. "Even if a mitigation is present in the firmware, it doesn't mean it is applied correctly without creating security holes."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

New Study Finds Most Enterprise Vendors Failing to Mitigate Speculative Execution Attacks

Plus: A wild Indian cricket scam, an elite CIA hacker is found guilty of passing secrets to WikiLeaks, and more of the week's top security news.

The websites you visit can reveal (almost) everything about you. If you are looking up health information, reading about trade unions, or researching details around certain types of crime, then you can potentially give away a huge amount of detail about yourself that a malicious actor could use against you. Researchers this week have detailed a new attack, using the web’s basic functions, that can unmask anonymous users online. The hack uses common web browser features—included in every major browser—and CPU functions to analyze whether you’re logged in to services such as Twitter or Facebook and subsequently identify you.

Elsewhere, we detailed how the Russian “hacktivist” group Killnet is attacking countries that backed Ukraine but aren’t directly involved in the war. Killnet has launched DDoS attacks against official government websites and businesses in Germany, the United States, Italy, Romania, Norway, and Lithuania in recent months. And it’s only one of the pro-Russian hacktivist groups causing chaos.

We’ve also looked at a new privacy scandal in India where donors to nonprofit organizations have had their details and information handed to police without their consent. We also looked at the new “Retbleed” attack that can steal data from Intel and AMD chips. And we took stock of the ongoing January 6 committee hearings—and predicted what’s to come.

But that’s not all. Each week we round up the news that we didn’t break or cover in-depth. Click on the headlines to read the full stories. And stay safe out there!

For years, Amazon-owned security camera firm Ring has been building relationships with law enforcement. By the start of 2021, Amazon had struck more than 2,000 partnerships with police and fire departments across the US, building out a huge surveillance network with officials being able to request videos to help with investigations. In the UK, Ring has partnered with police forces to give cameras away to local residents.

This week, Amazon admitted to handing police footage recorded on Ring cameras without their owners’ permission. As first reported by Politico, Ring has given law enforcement officials footage on at least 11 occasions this year. This is the first time the firm has admitted to passing on data without consent or a warrant. The move will raise further concerns over Ring’s cameras, which have been criticized by campaign groups and lawmakers for eroding people’s privacy and making surveillance technology ubiquitous. In response, Ring says it doesn’t give anyone “unfettered” access to customer data or video but may hand over data without permission in emergency situations where there is imminent danger of death or serious harm to a person.

In 2017, the Vault 7 leaks exposed the CIA’s most secretive and powerful hacking tools. Files published by WikiLeaks showed how the agency could hack Macs, your router, your TV, and a whole host of other devices. Investigators soon pointed the finger at Joshua Schulte, a hacker in the CIA’s Operations Support Branch (OSB), which was responsible for finding exploits that could be used in the CIA’s missions. Schulte has now been found guilty of leaking the Vault 7 files to Wikileaks and is potentially facing decades in prison. Following an earlier mistrial in 2018, Schulte was this week found guilty on all nine charges against him. Weeks ahead of his second trial, _The New Yorker_ published this comprehensive feature exploring Schulte’s dark history and how the CIA’s OSB operates.

Hackers linked to China, Iran, and North Korea have been targeting journalists and media outlets, according to new research from security firm Proofpoint. Alongside efforts to compromise the official accounts of members of the press, Proofpoint says, multiple Iranian hacking groups have posed as journalists and tried to trick people into handing over their online account details. The Iranian-linked group Charming Kitten has sent detailed interview requests to its potential hacking targets, and they have also tried to impersonate multiple Western news outlets. “This social engineering tactic successfully exploits the human desire for recognition and is being leveraged by APT actors wishing to target academics and foreign policy experts worldwide, likely in an effort to gain access to sensitive information,” Proofpoint says.

In any company or organization, items will go missing from time to time. Usually these are misplaced phones, security passes, and files occasionally being left at bus stops by mistake. Losing any of these things may open up security risks if devices are insecure or if sensitive information is made public. Less commonly lost are desktop computers—unless you’re the FBI. According to FBI records obtained by VICE’s _Motherboard_, the agency lost 200 desktop machines between July and December 2021. Also lost, or in some cases stolen, were pieces of body armor and night-vision scopes.

Scams don’t get much more elaborate than this. This week, police in India busted a fake “Indian Premier League” cricket tournament. A group of alleged scammers set up the fake league in the western Indian state of Gujarat and hired young men to play cricket matches, posing as professional teams while they livestreamed the matches for people to bet on. According to police, the group hired a fake commentator, created onscreen graphics showing real-time scores, and played crowd noises downloaded from the internet. To hide the fact that the matches took place on a farm instead of inside a large stadium, the videofeed only showed closeups of the action. Police said they caught the gang as a quarterfinal match was being played. Police believe the gang was potentially running multiple leagues and was planning to expand to a volleyball league, too. The match footage is worth watching.

Amazon Handed Ring Videos to Cops Without Warrants

"Retbleed" bypasses a commonly used mechanism for protecting against a certain kind of side-channel attack.

Researchers at ETH Zurich have found a way to overcome a commonly used defense mechanism against so-called speculative execution attacks targeting modern microprocessors.

In a technical paper published this week, the researchers described how attackers could use their technique — dubbed "Retbleed" — to steal sensitive data from the memory of systems with Intel and AMD microprocessors that are vulnerable to the issue. The researchers built their proof-of concept code for Linux but said some Windows and Apple computers with the affected microprocessors likely have the issue as well.

Their discovery prompted Intel and AMD to issue advisories this week describing mitigations against the new attack method. In an emailed statement, Intel said it had worked with industry partners, the Linux community, and Virtual Machine Manager (VMM) vendors to make mitigations available to customers. "Windows systems are not affected as they already have these mitigations by default," Intel noted.

AMD said the issue the researchers had identified potentially allows arbitrary speculative code execution under certain microarchitecture conditions. "As part of its ongoing work to identify and respond to new potential security vulnerabilities, AMD is recommending software suppliers consider taking additional steps to help guard against Spectre-like attacks," AMD said in an emailed statement. "That guidance is found in a new AMD whitepaper now available."

Both chipmakers said they were not aware of any active exploits in the wild related to the issue that the researchers at ETH Zurich discovered and reported.

**A Dangerous Attack Vector**

Security researchers consider speculative execution attacks as dangerous because they give attackers a way to access and steal sensitive data — including passwords and encryption keys — in a computer's memory. It's an issue that is especially of concern in shared environments such as public cloud services and shared enterprise infrastructure.

Speculative execution is a performance-enhancing mechanism in modern microprocessors where instructions in code are executed in advance of when they are needed, without waiting for previous instructions to be completed. The technique can help speed up microprocessor performance. If the microprocessor guesses wrong and executes an instruction that is not needed, it discards that instruction. But in doing so, it sometimes leaves artifacts from system memory in the processor's buffers or cache.

Threat actors have taken advantage of this fact to devise so-called side channel attacks where they get the microprocessor to speculatively execute code in such a way as to get it to access — and reveal — sensitive information in the system memory. The issue became a major concern in 2018 with the disclosure of the Spectre and Meltdown vulnerabilities in most microprocessors used in everything from servers to PCs, laptops, and mobile devices.

Since then, chipmakers like Intel and AMD have introduced changes and mitigations to make it harder for adversaries to carry out speculative execution side-channel attacks.

One widely used mitigation against speculative execution attacks is called "Retpoline," a Google-developed approach for controlling how a microprocessor performs speculation when handling certain instructions — so-called indirect "jumps" and "calls".

**'Crazy Trick'**

Retpolines work by replacing indirect jumps and calls with the "return" function, says Johannes Wikner, one of the researchers at ETH Zurich who developed the new exploit. "Retpoline replaces indirect jumps with returns using a crazy trick," Wikner says. "It tricks the processor to believe there has been a 'call' made from the location where the indirect jump was intended to lead."

The motivation for replacing indirect jumps and calls with returns was because the return function was considered impractical to exploit, he says.

But that is not the case, Wikner says. Their research showed that it is possible to trigger microarchitectural conditions on Intel and AMD CPUs that force the return function to be speculatively executed just like was possible with indirect jumps and calls. "Retpoline does not \[consider\] the fact the returns can be exploited, into account," he says. "This allows us to bypass the Retpoline defense."

Wikner says it took the researchers some work to exploit the issue on Intel microprocessors and required their finding a sequence of deep function call stacks to trigger it. "We found on AMD that all returns can be exploited regardless of the function call stack," he says. "We built a framework to make it easy also on Intel."

Bogdan Botezatu, director of threat research at Bitdefender, which last year developed a side-channel attack of its own against Intel CPUs, says Retbleed appears to be a side-channel attack as well one that bypasses a mitigation set in place for Spectre. "This is yet another way in which modern CPUs can be exploited to inadvertently leak information that should be considered secret — and for which hardware defenses are burnt into the silicon," he says.

He says two things are worth mentioning when talking about this type of attack. Conceptually, it beats measures built into chips to prevent data from leaking from one realm to the other. "In the hands of a patient and properly positioned attacker, this vulnerability can exfiltrate important information from shared computers or virtualized servers. This is bad," he says.

**Complex to Execute**

At the same time, such attacks require significant knowledge and logistics to successfully result in exfiltration of the data sought by a potential attacker. High-profile targets should be worried about the existence of this vulnerability and should deploy Intel and AMD's recommended mitigations. "Side-channel attacks are effective, but difficult to execute and exfiltrate exactly that piece of information that attackers are after," Botezatu says.

Intel said that two security advisories it published Tuesday address the research. One of them is here and the other here. The company described the issue as impacting some of its Skylake generation processors that do not have a feature called enhanced Indirect Branch Restricted Speculation (eIBRS). "Intel worked with the Linux community and VMM vendors to provide customers with software mitigations to enable Indirect Branch Restricted Speculation (IBRS), and enhanced Indirect Branch Restricted Speculation (eIBRS) where supported."

Windows systems are not affected because they use IBRS by default, the Intel statement noted.

Researchers Devise New Speculative Execution Attacks Against Some Intel, AMD CPUs

The exploit can leak password information and other sensitive material, but the chipmakers are rolling out mitigations.

Some microprocessors from Intel and AMD are vulnerable to a newly discovered speculative execution attack that can covertly leak password data and other sensitive material, sending both chipmakers scrambling once again to contain what is proving to be a stubbornly persistent vulnerability.

Researchers from ETH Zurich have named their attack Retbleed because it exploits a software defense known as retpoline, which chipmakers introduced in 2018 to mitigate the harmful effects of speculative execution attacks. Speculative execution attacks, also known as Spectre, exploit the fact that when modern CPUs encounter a direct or indirect instruction branch, they predict the address for the next instruction they’re about to receive and automatically execute it before the prediction is confirmed. Spectre works by tricking the CPU into executing an instruction that accesses sensitive data in memory that would normally be off-limits to a low-privileged application. Retbleed then extracts the data after the operation is canceled.

Is It a Trampoline or a Slingshot?

Retpoline works by using a series of return operations to isolate indirect branches from speculative execution attacks, in effect erecting the software equivalent of a trampoline that causes them to safely bounce. Stated differently, a retpoline works by replacing indirect jumps and calls with returns, which many researchers presumed weren’t susceptible. The defense was designed to counter variant 2 of the original speculative execution attacks from January 2018. Abbreviated as BTI, the variant forces an indirect branch to execute so-called gadget code, which in turn creates data to leak through a side channel.

Some researchers have warned for years that retpoline isn’t sufficient to mitigate speculative execution attacks because the returns retpoline used were susceptible to BTI. Linux creator Linus Torvalds famously rejected such warnings, arguing that such exploits weren’t practical.

The ETH Zurich researchers have conclusively shown that retpoline is insufficient for preventing speculative execution attacks. Their Retbleed proof-of-concept works against Intel CPUs with the Kaby Lake and Coffee Lake microarchitectures as well as with AMD Zen 1, Zen 1+, and Zen 2 microarchitectures.

“Retpoline, as a Spectre-BTI mitigation, fails to consider return instructions as an attack vector,” researchers Johannes Wikner and Kaveh Razavi wrote. “While it is possible to defend return instructions by adding a valid entry to the RSB return stack buffer before executing the return instruction, treating every return as potentially exploitable in this way would impose a tremendous overhead. Previous work attempted to conditionally refill the RSB with harmless return targets whenever a perCPU counter that tracks the call stack depth reaches a certain threshold, but it was never approved for upstream. In the light of Retbleed, this mitigation is being re-evaluated by Intel, but AMD CPUs require a different strategy.”

In an email, Razavi explained it this way:

_Spectre variant 2 exploited indirect branches to gain arbitrary speculative execution in the kernel. Indirect branches were converted to returns using the retpoline to mitigate Spectre variant 2._

_Retbleed shows that return instructions unfortunately leak under certain conditions similar to indirect branches. These conditions are unfortunately common on both Intel (Skylake and Skylake-based) and AMD (Zen, Zen+ and Zen2) platforms. This means that retpoline was unfortunately an inadequate mitigation to begin with._

In response to the research, both Intel and AMD advised customers to adopt new mitigations that the researchers said will add as much as 28 percent more overhead to operations.

Retbleed can leak kernel memory from Intel CPUs at about 219 bytes per second and with 98 percent accuracy. The exploit can extract kernel memory from AMD CPUs with a bandwidth of 3.9 kB per second. The researchers said that it’s capable of locating and leaking a Linux computer’s root password hash from physical memory in about 28 minutes when running the Intel CPUs and in about six minutes for AMD CPUs.

Retbleed works by using code that essentially poisons the branch prediction unit that CPUs rely on to make their guesses. Once the poisoning is complete, this BPU will make mispredictions that the attacker can control.

“We found that we can inject branch targets that reside inside the kernel address-space, even as an unprivileged user,” the researchers wrote in a blog post. “Even though we cannot access branch targets inside the kernel address-space—branching to such a target results in a page fault—the Branch Prediction Unit will update itself upon observing a branch and assume that it was legally executed, even if it's to a kernel address.”

Intel and AMD Respond

Both Intel and AMD have responded with advisories. Intel has confirmed that the vulnerability exists on Skylake-generation processors that don’t have a protection known as enhanced Indirect Branch Restricted Speculation (eIBRS) in place.

“Intel has worked with the Linux community and VMM vendors to provide customers with software mitigation guidance which should be available on or around today's public disclosure date,” Intel wrote in a blog post. “Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users. Intel is not aware of this issue being exploited outside of a controlled lab environment.”

AMD, meanwhile, has also published guidance. “As part of its ongoing work to identify and respond to new potential security vulnerabilities, AMD is recommending software suppliers consider taking additional steps to help guard against Spectre-like attacks,” a spokesman wrote in an email. The company has also published a white paper.

Both the researchers’ research paper and blog post explain the microarchitectural conditions necessary to exploit Retbleed:

_**Intel**. On Intel, returns start behaving like indirect jumps when the Return Stack Buffer, which holds return target predictions, is underflowed. This happens upon executing deep call stacks. In our evaluation we found over a thousand of such conditions that can be triggered by a system call. The indirect branch target predictor for Intel CPUs has been studied in_ _previous work__._

_**AMD**. On AMD, returns will behave like an indirect branch regardless of the state of their Return Address Stack. In fact, by poisoning the return instruction using an indirect jump, the AMD branch predictor will assume that it will encounter an indirect jump instead of a return and consequentially predict an indirect branch target. This means that any return that we can reach through a system call can be exploited—and there are tons of them._

In an email, Razavi added: “Retbleed is more than just a retpoline bypass on Intel, specially on AMD machines. AMD is in fact going to release a white paper introducing Branch Type Confusion based on Retbleed. Essentially, Retbleed is making AMD CPUs confuse return instructions with indirect branches. This makes exploitation of returns very trivial on AMD CPUs.”

The mitigations will come at a cost that the researchers measured to be between 12 percent and 28 percent more computational overhead. Organizations that rely on affected CPUs should carefully read the publications from the researchers, Intel, and AMD, and be sure to follow the mitigation guidance.

_This story originally appeared on_ _Ars Technica__._

New ‘Retbleed’ Attack Can Swipe Key Data From Intel and AMD CPUs

Security researchers have uncovered yet another vulnerability affecting numerous older AMD and Intel microprocessors that could bypass current defenses and result in Spectre-based speculative-execution attacks.
Dubbed Retbleed by ETH Zurich researchers Johannes Wikner and Kaveh Razavi, the issues are tracked as CVE-2022-29900 (AMD) and CVE-2022-29901 (Intel), with the chipmakers releasing

Security researchers have uncovered yet another vulnerability affecting numerous older AMD and Intel microprocessors that could bypass current defenses and result in Spectre-based speculative-execution attacks.

Dubbed **Retbleed** by ETH Zurich researchers Johannes Wikner and Kaveh Razavi, the issues are tracked as CVE-2022-29900 (AMD) and CVE-2022-29901 (Intel), with the chipmakers releasing software mitigations as part of a coordinated disclosure process.

Retbleed is also the latest addition to a class of Spectre attacks known as Spectre-BTI (CVE-2017-5715 or Spectre-V2), which exploit the side effects of an optimization technique called speculative execution by means of a timing side channel to trick a program into accessing arbitrary locations in its memory space and leak private information.

Speculative execution attempts to fill the instruction pipeline of a program by predicting which instruction will be executed next in order to gain a performance boost, while also undoing the results of the execution should the guess turn out to be wrong.

Attacks like Spectre take advantage of the fact that these erroneously executed instructions — a result of the misprediction — are bound to leave traces of the execution in the cache, resulting in a scenario where a rogue program can trick the processor into executing incorrect code paths and infer secret data pertaining to the victim.

Put differently, Spectre is an instance of transient execution attack, which relies on hardware design flaws to "influence" which instruction sequences are speculatively executed and leak encryption keys or passwords from within the victim's memory address space.

This, in turn, is achieved through microarchitectural side channels like Flush+Reload that measures the time taken to perform memory reads from the cache that's shared with the victim, but not before flushing some of the shared memory, resulting in either fast or slow reads depending on whether the victim accessed the monitored cache line since it was evicted.

While safeguards like Retpoline (aka "return trampoline") have been devised to prevent branch target injection (BTI), Retbleed is designed to get around this countermeasure and achieve speculative code execution.

"Retpolines work by replacing indirect jumps \[branches where the branch target is determined at runtime\] and calls with returns," the researchers explained.

"Retbleed aims to hijack a return instruction in the kernel to gain arbitrary speculative code execution in the kernel context. With sufficient control over registers and/or memory at the victim return instruction, the attacker can leak arbitrary kernel data."

The core idea, in a nutshell, is to treat return instructions as an attack vector for speculation execution and force the returns to be predicted like indirect branches, effectively undoing protections offered by Retpoline.

As a new line of defense, AMD has introduced what's referred to as Jmp2Ret, while Intel has recommended using enhanced Indirect Branch Restricted Speculation (eIBRS) to address the potential vulnerability even if Retpoline mitigations are in place.

"Windows operating system uses IBRS by default, so no update is required," Intel said in an advisory, noting it worked with the Linux community to make available software updates for the shortcoming.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

New 'Retbleed' Speculative Execution Attack Affects AMD and Intel CPUs

Microsoft released its monthly round of Patch Tuesday updates to address 84 new security flaws spanning multiple product categories, counting a zero-day vulnerability that's under active attack in the wild.
Of the 84 shortcomings, four are rated Critical, and 80 are rated Important in severity. Also separately resolved by the tech giant are two other bugs in the Chromium-based Edge browser, one

Microsoft released its monthly round of Patch Tuesday updates to address 84 new security flaws spanning multiple product categories, counting a zero-day vulnerability that's under active attack in the wild.

Of the 84 shortcomings, four are rated Critical, and 80 are rated Important in severity. Also separately resolved by the tech giant are two other bugs in the Chromium-based Edge browser, one of which plugs another zero-day flaw that Google disclosed as being actively exploited in real-world attacks.

Top of the list of this month's updates is CVE-2022-22047 (CVSS score: 7.8), a case of privilege escalation in the Windows Client Server Runtime Subsystem (CSRSS) that could be abused by an attacker to gain SYSTEM permissions.

"With this level of access, the attackers are able to disable local services such as Endpoint Detection and Security tools," Kev Breen, director of cyber threat research at Immersive Labs, told The Hacker News. "With SYSTEM access they can also deploy tools like Mimikatz which can be used to recover even more admin and domain level accounts, spreading the threat quickly."

Very little is known about the nature and scale of the attacks other than an "Exploitation Detected" assessment from Microsoft. The company's Threat Intelligence Center (MSTIC) and Security Response Center (MSRC) have been credited with reporting the flaw.

Besides CVE-2022-22047, two more elevation of privilege flaws have been fixed in the same component — CVE-2022-22026 (CVSS score: 8.8) and CVE-2022-22049 (CVSS score: 7.8) — that were reported by Google Project Zero researcher Sergei Glazunov.

"A locally authenticated attacker could send specially crafted data to the local CSRSS service to elevate their privileges from AppContainer to SYSTEM," Microsoft said in an advisory for CVE-2022-22026.

"Because the AppContainer environment is considered a defensible security boundary, any process that is able to bypass the boundary is considered a change in Scope. The attacker could then execute code or access resources at a higher integrity level than that of the AppContainer execution environment."

Also remediated by Microsoft include a number of remote code execution bugs in Windows Network File System (CVE-2022-22029 and CVE-2022-22039), Windows Graphics (CVE-2022-30221), Remote Procedure Call Runtime (CVE-2022-22038), and Windows Shell (CVE-2022-30222).

The update further stands out for patching as many as 32 issues in the Azure Site Recovery disaster recovery service. Two of these flaws are related to remote code execution and the remaining 30 concern privilege escalation.

"Successful exploitation \[...\] requires an attacker to compromise admin credentials to one of the VMs associated with the configuration server," the company said, adding the flaws do not "allow disclosure of any confidential information, but could allow an attacker to modify data that could result in the service being unavailable."

On top of that, Microsoft's July update also contains fixes for four privilege escalation vulnerabilities in the Windows Print Spooler module (CVE-2022-22022, CVE-2022-22041, CVE-2022-30206, and CVE-2022-30226) after a brief respite in June 2022, underscoring what appears to be a never-ending stream of flaws plaguing the technology.

Rounding off the Patch Tuesday updates are two notable fixes for tampering vulnerabilities in the Windows Server Service (CVE-2022-30216) and Microsoft Defender for Endpoint (CVE-2022-33637) and three denial-of-service (DoS) flaws in Internet Information Services (CVE-2022-22025 and CVE-2022-22040) and Security Account Manager (CVE-2022-30208).

**Software Patches from Other Vendors**

In addition to Microsoft, security updates have also been released by other vendors since the start of the month to rectify several vulnerabilities, including —

*   Adobe
*   AMD
*   Android
*   Apache Projects
*   Cisco
*   Citrix
*   Dell
*   Fortinet
*   GitLab
*   Google Chrome
*   HP
*   Intel
*   Lenovo
*   Linux distributions Debian, Oracle Linux, Red Hat, SUSE, and Ubuntu
*   MediaTek
*   Qualcomm
*   SAP
*   Schneider Electric
*   Siemens, and
*   VMware

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Tag

#amd