Quote: Google warns 2.5B Gmail users to update passwords after data breach of one of its databases – https://nypost.com/2025/08/27/business/google-warns-2-5-billion-gmail-users-to-update-passwords-after-hackers-complete-successful-intrusions/

Preface: More than 2.5 billion Gmail users could be at risk following a massive cyberattack that compromised a Google database managed through Salesforce’s cloud platform. The attack, which began in June 2025, relied on social engineering tactics. According to Google’s Threat Intelligence Group (GTIG), scammers impersonated IT staff during convincing phone calls and persuaded a Google employee to approve a malicious application connected to Salesforce. This gave attackers the ability to exfiltrate contact details, business names, and related notes. (Source: Trend Micro) – https://news.trendmicro.com/2025/08/26/google-data-breach-gmail/

Background: BeyondCorp^® is a cybersecurity architecture developed at Google that shifts access control from the traditional network perimeter to individual devices and users. The goal is to enable users to securely work anytime, anywhere and on any device without having to use a virtual private network, or VPN, to access an organization’s resources.

Google uses OpenID Connect (OIDC) for its “Sign in with Google” functionality, as it is an OpenID Connect Provider that issues OIDC-formatted JSON Web Tokens (JWTs) to authenticate users and share identity information with client applications. This allows users to log into other websites and applications using their Google account, benefiting from a simplified and more secure single sign-on (SSO) experience.

OAuth 2.0 is an authorization framework, OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 to provide user authentication and identity information. OAuth 2.0 focuses on granting access to protected resources, while OIDC extends it to verify a user’s identity and share their profile information with third-party applications.

About the title: Please see the attached diagram.

Ref: Gmail utilizes a protocol called OpenID Connect (OIDC) for authentication, which is built on top of the OAuth 2.0 authorization framework. This protocol allows users to log in to various applications by authenticating with their Google Account without sharing their passwords directly, enabling both authentication (verifying identity) and authorization (granting access to specific data). For Gmail access, OAuth 2.0 is used for authorization, while OIDC provides the user authentication mechanism, returning an ID Token in addition to an access token for identity verification.

Preface: AppNeta, now part of Broadcom, is a SaaS-based network performance monitoring solution that provides IT and network operations teams with end-to-end visibility into application performance and network issues from the end-user perspective.

Why do developers need to customize Tcpreplay?

• Testing Firewalls and IDS/IPS: Tcpreplay allows you to replay captured traffic through network devices like firewalls and intrusion detection/prevention systems.
• Tuning Flow Expiry: You can optimize flow timeout settings to improve the accuracy of flow analysis and tuning for flow-based products.

Background: Tcpreplay is a suite of free, open-source command-line tools for replaying and editing network traffic captured in pcap files, which are created by tools like tcpdump and Wireshark. It’s used to test network devices such as intrusion detection systems (IDS), routers, and firewalls by replaying real-world traffic at specific speeds, or to simulate traffic for debugging and performance analysis.

AppNeta, on the other hand, is a commercial network performance monitoring solution. While AppNeta provides a comprehensive suite of features for network monitoring, including bandwidth monitoring, application management, and capacity management, its relationship with Tcpreplay is notable.

Vulnerability details: A vulnerability has been found in appneta tcpreplay up to 4.5.1. The impacted element is the function get_l2len_protocol of the file get.c of the component tcprewrite. Such manipulation leads to use after free. The attack must be carried out locally. The exploit has been disclosed to the public and may be used.

Remedy: Upgrading to version 4.5.2-beta3 is sufficient to resolve this issue. You should upgrade the affected component.

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2025-9386

Published: 2025-08-22

Updated: 2025-08-21

Preface: In Chrome, a sandbox is a security feature that isolates web content and processes into restricted environments, while serialization is the process of converting an object’s state into a format (like a byte stream) that can be stored or transferred. The sandbox focuses on security and isolation, whereas serialization is a data handling mechanism used within various Chrome features, such as interacting with hardware via the Serial AP.

Background: In Chrome, an unprivileged environment is a restricted sandbox where web content and extensions run with limited access to the operating system and local resources, designed to prevent malicious code from causing harm. Chrome uses sandboxing, process isolation, and a permissions system to enforce this isolation. Content running in an unprivileged environment generally cannot install programs, view or delete user data, or directly interact with system-level features unless the user explicitly grants specific permissions.

Ref: The “ipcz_driver” layer refers to a component in Google Chrome’s development that acts as a bridge between JavaScript and the Mojo API, enabling injected JavaScript to communicate with C++ components via the Chromium ipcz-based Mojo bindings. It functions as a communication layer, allowing for the high-bandwidth, zero-copy transfer of data between different parts of the browser’s architecture, particularly for communication between the browser’s user interface and its underlying components.

Vulnerability details: Incorrect handle provided in unspecified circumstances in Mojo in Google Chrome on Windows prior to 136.0.7103.113 allowed a remote attacker to potentially perform a sandbox escape via a malicious file.

Official announcement: Please see the link for details –

https://www.tenable.com/cve/CVE-2025-4609

Preface: While Kubernetes doesn’t directly expose net/sched as a configurable API, its network management and QoS features often rely on or interact with net/sched at the underlying Linux kernel level to achieve desired network behavior for containerized applications.

Background: net/sched is the Linux kernel subsystem responsible for traffic control (tc). It manages how packets are queued and scheduled for transmission on network interfaces using qdiscs (queueing disciplines). The default qdisc is typically pfifo_fast or fq_codel depending on the kernel version and distribution.

Vulnerability details: The vulnerability CVE-2025-38553 affects the Linux kernel’s net/sched subsystem, specifically the netem qdisc. It arises when multiple netem instances are added to the same qdisc tree, which can lead to:

• Soft lockups
• Out-of-memory (OOM) errors
• Infinite loops during packet dequeueing

The root cause is flawed duplication logic in netem_enqueue, especially when a netem is nested within another netem in a qdisc hierarchy. The fix restricts the addition of a duplicating netem if another netem already exists in the tree

Official announcement: Please see the link for details –

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=09317dfb681ac5a96fc69bea0c54441cf91b8270

Official Revision Date: 2025-08-12

Preface: AMD SEV-SNP is a confidential computing hardware technology present in AMD EPYC processors from generation 3 and newer. It is based on hardware virtualization extensions and achieves isolation by adding these measures: Full memory encryption.

SEV-SNP is not solely located in the firmware. While the firmware plays a crucial role in SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging), it’s a combination of hardware, firmware, and software working together to provide the security features. The firmware initializes the SEV-SNP context and performs attestation, but the core functionality also relies on the AMD processor’s hardware and the guest operating system’s software components. For example: SEV-SNP is supported on AMD EYPC processors starting with the AMD EPYC 7003 series processors. AMD SEV-SNP offers powerful and flexible support for the isolation of a guest virtual machine from an untrusted host operating system. It is very useful in public cloud and any untrusted host scenario.

Background: SEV-SNP is designed to prevent software-based integrity attacks and reduce risk associated with compromised memory integrity. The basic principle of SEV-SNP integrity is that if a VM is able to read a private (encrypted) page of memory, it must always read the value it last wrote.

AMD SEV-SNP allows the hypervisor to move encrypted guest pages, including swapping pages to disk, but this capability can also be exploited through ciphertext side-channel attacks, where the hypervisor monitors ciphertext changes to infer guest data.

The findings of the two research teams:

AMD has received reports from two research groups detailing methods by which a malicious hypervisor could potentially execute a side channel attack against a running secure encrypted virtualization – secure nested paging (SEV-SNP) guest.

The first report, titled “Relocate + Vote: Exploiting Ciphertext Side-Channels using Sparsity Information,” was submitted by researchers at the Toronto System Security Lab of the University of Toronto. 

A subsequent report from researchers at ETH Zurich titled “Chosen Plaintext Oracle against SEV-SNP,” outlines a similar exploitation technique that also leverages the ability to move or swap guest pages. 

Official announcement: For more information, please refer to the link:

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3021.html