Untrusted Pointer Dereference [CWE-822]

Untrusted Pointer Dereference weakness occurs where software uses untrusted input as a pointer value.

Created: December 6, 2012
Latest Update: December 15, 2020

Table of Content

1. Description
2. Potential impact
3. Affected software
4. Severity and CVSS Scoring
5. Mitigations
6. References
7. Latest Related Security Advisories

Want to have an in-depth understanding of all modern aspects of
Untrusted Pointer Dereference [CWE-822]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

Untrusted pointer dereference weaknesses, as well as many other pointer relates issues, often fall under the general term of "memory corruption". This weakness occurs where software receives input from an untrusted source, converts its value to a pointer, and dereferences the resulting pointer. Depending on vulnerable code, this weakness can have impact on confidentiality, integrity, or availability.

If the untrusted pointer is used in a read operation, an attacker might be able to read sensitive portions of memory. In cases when such a pointer references a location in memory, which is not accessible to the program, or is larger than expected by read/write operation, application may terminate unexpectedly. If the untrusted pointer is used in write operations or function calls, it is possible to gain control over the application's flow and execute arbitrary code on the target system.

Untrusted pointer dereference issues usually appear when:

• The OS kernel or driver receives untrusted input from userspace as an argument. For example, the second parameter to the write system call is a pointer to a user buffer. This is a common issue within many operating systems;
• The untrusted pointer value is used in a function call directly;
• Software accepts pointer value from an untrusted source but is not designed to accept and handle untrusted input at all. This could result from a race condition or improper application design.

We will use the following example to demonstrate this weakness. Let’s take a look at the following HTML code:

This method receives a pointer from another function in order to call a method within the loaded ActiveX control.

The ActiveX Insecure.method01() method receives an input value that is not properly validated, and if it is used to dereference a function pointer, it could be possible for an attacker to load the ActiveX method with a crafted pointer and crash the application. In some cases a code execution could be possible.

After receiving a specially crafted value, the application does not validate input before using it in a function call.

The following assembly lines demonstrate what happens after malicious person takes advantage of this method. At the first line the passed value is stored in the stack and is later used to call a function at line 6.

1.- MOV ECX,DWORD PTR SS:[ESP+30]
2.- CMP ECX,EDI
3.- JE SHORT 10818B48
4.- MOV EDX,DWORD PTR DS:[ECX]
5.- MOV EAX,DWORD PTR DS:[EDX]
6.- CALL EAX


Figure - Code execution is possible after the supplied value is used to dereference a function

In the above example, the supplied data to the Insecure.method01() method is used to dereference a function. An attacker can redirect application's flow and execute arbitrary code located at attacker-controlled address (The EAX register on Figure 1).

2. Potential impact

This vulnerability could be used to disclose potentially sensitive data, cause application crash, or execute arbitrary code. In cases of local attack vector, it may be possible to elevate privileges.

3. Affected software

Software written in C/C++, Assembly or any other language that makes usage of pointers is potentially vulnerable to this type of weakness.

4. Severity and CVSS Scoring

This weakness can occur in different applications and should be scored according to maximum potential impact, access complexity and access vector. We will provide several scoring examples to cover common issues for this type of weakness.

Kernel memory information disclosure

Such weakness is usually locally exploitable and has the following score:
2.1 (AV:L/AC:L/Au:N/C:P/I:N/A:N) – Low severity.

This scoring means that a malicious user can read random data from memory locations.

In cases where attacker has control over locations to be read, such weakness should be scored as: 4.9 (AV:L/AC:L/Au:N/C:C/I:N/A:N) – Medium severity.

Note that the "C:C" metric is allowed with a kernel module or driver only. If the vulnerability exists in a software that runs with limited privileges, "Partial" confidentiality impact should be used instead.

Denial of service

A locally exploitable denial of service vulnerability in a privileged software that may lead to system crash should be scored as:
4.9 (AV:L/AC:L/Au:N/C:N/I:N/A:C) – Medium severity.

Denial of service vulnerability in a non-privileged software, however, results in application crash only and should be scored as:
2.1 (AV:L/AC:L/Au:N/C:N/I:N/A:P) – Low severity.

Code execution

In case of a privilege escalation vulnerability, this weakness is usually scored as:
7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) – High severity.

If the vulnerable application is an ActiveX control, this weakness should be scored as:
9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C) – Critical severity.

"AC:M" stands for additional actions that should be performed by a victim (e.g. visit a malicious webpage) in order to exploit this vulnerability.

We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.

5. Mitigations

There are no particular mitigations against this weakness. Developers are advised to pay attention to untrusted data and perform bounds checks on input to ensure that the supplied pointer points to the appropriate address or address range.

6. References

1. CWE-822: Untrusted Pointer Dereference [cwe.mitre.org]
2. Untrusted Pointer Dereference Vulnerability in Corel WordPerfect X6 [HTB23114] [htbridge.com]

7. Untrusted Pointer Dereference Vulnerabilities, Exploits and Examples

• HTB23131: Novell GroupWise Multiple Remote Code Execution Vulnerabilities
• HTB23114: Untrusted Pointer Dereference Vulnerability in Corel WordPerfect X6

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.

↑ Back to Top