Monthly Archives: March 2025

Cell Phone (iPhone, Android, windows mobile), Potential Risk of CVE

CVE-2025-0078: Ensuring that the identity of the requesting service is included and verified during inter-process communication (4th Mar 2025)

Leave a comment

Preface: The Gospel of Matthew 24:37

As it was in the days of Noah, so it will be at the coming of the Son of Man. For in the days before the flood, people were eating and drinking,..etc

Background: In Android, the ServiceManager is a key component in the Binder IPC (Inter-Process Communication) mechanism. It manages system services and provides a way for clients to obtain references to these services.

Here’s a brief overview of how the ServiceManager operates:

  1. Initialization: The ServiceManager is started by the init process during the system boot. It is defined in the init.rc script, which specifies the service and its executable path.
  2. Service Registration: When a service wants to register with the ServiceManager, it calls the addService method. This method takes the service name and a reference to the service’s Binder interface.
  3. Service Lookup: Clients can query the ServiceManager to get a reference to a registered service using the getService method. This method returns the Binder interface of the requested service.
  4. Security and Permissions: Starting from Android 8.1, SELinux policies have become stricter. Services must be defined in the plat_service_contexts file to be allowed to register with the ServiceManager. This ensures that only authorized services can be registered and accessed..
  5. Communication: Once a service is registered, clients can communicate with it through Binder IPC. The ServiceManager acts as a mediator, ensuring that the communication is secure and efficient.

Vulnerability details: local privilege escalation

Bug fixes: The setRequestingSid(true) method in the ServiceManager is used to enable the inclusion of the Security Identifier (SID) in service requests. This is part of the security framework in Android, ensuring that the identity of the requesting service is included and verified during inter-process communication (IPC).

Official announcement: Please refer to the vendor announcement for details – https://android.googlesource.com/platform/frameworks/native/+/c32d4defe0f4e5cad86437d6672de7a76caf1a79

IoT, Potential Risk of CVE

CVE-2020-24658: A year-old vulnerability is still hiding in embedded systems (3rd Mar 2025)

Leave a comment

Preface: Many programmers continue to use Arm Compiler 5 for several reasons:

Developers who have been using Arm Compiler 5 for years are familiar with its quirks and features, making it easier for them to continue using it rather than learning a new toolchain.

Furthermore, Arm Compiler 5 supports older ARM architectures that may not be fully supported by newer compilers.

Background: When compiling ARM code with stack protection, the –protect_stack option is used to safeguard against stack buffer overflows and potential malicious tampering. Here are the conditions under which a function is considered vulnerable and thus protected:

  1. Arm Compiler 5:
    A function is considered vulnerable if it contains a char or wchar_t array of any size1.
  2. Arm Compiler 6:
    With -fstack-protector, a function is considered vulnerable if it contains:
    -A character array larger than 8 bytes.
    -An 8-bit integer array larger than 8 bytes.
    -A call to alloca() with either a variable size or a constant size bigger than 8 bytes1.
    With -fstack-protector-strong, a function is considered vulnerable if it contains:
    -An array of any size and type.
    -A call to alloca().
    -A local variable that has its address taken1.

Using these options helps improve the overall security and integrity of your code by preventing stack buffer overflows

Vulnerability details: In certain circumstances the stack protection feature can be rendered ineffective, leaving the protected function vulnerable to stack-based buffer overflows.

An undetected stack overflow can lead to a function return address being overwritten, potentially causing a crash or hang or allowing an attacker to gain control over program execution.

Official announcement: Please refer to the vendor announcement for detail – https://developer.arm.com/documentation/110262/1-1/?lang=en

System

PAGE PREFETCHER ATTACK – AMD ID: AMD-SB-7040 (28-2-2025)

Leave a comment

Preface: Page prefetching is a technique used to improve performance by preloading data into the cache before it’s actually needed. However, the implementation and presence of a page prefetcher can vary depending on the CPU architecture and design.

Background: A page prefetcher attack is a type of side-channel attack that exploits the page prefetching mechanism in modern CPUs. Page prefetching is a performance optimization technique where the CPU predicts and loads pages of memory into the cache before they are actually needed. This can inadvertently create security vulnerabilities.

In a page prefetcher attack, an attacker can infer sensitive information by observing the patterns and timing of page prefetching operations. For example, the attacker might be able to determine which memory pages are being accessed by the victim, thereby gaining insights into the victim’s activities or extracting sensitive data.

About the topic: Researchers have disclosed to AMD a potential exploit, the page prefetcher attack (PPA), a prefetcher-based side-channel attack.

Manufacturer response: AMD has evaluated the paper and does not believe there are any new security implications. Please refer to the link – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7040.html