Introduction #
After a career break, I had the chance to go over the OpenSecurityTraining2 C-Family Software Implementation Vulnerabilities courses, and I decided to write these notes as an effort to consolidate some of the knowledge acquired from the content of these courses as well as notes from the excellent book The Art Of Software Security Assessment (Mark Dowd, John McDonald, Justin Schuh 2006) in combination with personal experience in auditing C/C++ code in a single place for future personal reference.
I would assume the reader already has some experience in code-auditing or vulnerability research and general system architecture, as I won’t be covering things such as what the Stack or the Heap is. In case you don’t, I would highly encourage Xeno Kovah’s courses as they have been proven to be extremely well structured and versed, and I personally found them to be a very valuable resource as well as TAOSSA for anybody in the field, despite experience level.
Before we move forward with the rest of these notes, first I would like to define some nomenclature which I really enjoyed – first introduced by Xeno Kovah in his courses – used to describe some concepts which we will be referencing throught these notes:
Nomenclatures #
ACID: Attacker-Controlled Input DataSACI: Semi-Attacker-Controlled Input
These two abbreviations will help to define what variables/data/memory an attacker can potentially control, and to what capacity in sample code snippets.
C String Manipulation Issues
Many of the most significant security vulnerabilities of the last decade are the result of memory corruption due to mishandling textual data, or logical flaws due to the misinterpretation of the content in textual data.
In C there is no native type for strings; instead, strings are formed by constructing arrays of char data type with the NUL character (0x00) marking the end of a string. Representing a string in this manner, entails that the length of the string is not associated with the buffer that contains it, and it is often not known until runtime.
This fact forces programmers to manage strings manually generally in one of two ways:
- To estimate how much memory to reserve for a statically sized array, or to dynamically allocate the amount of memory required when its known at runtime.
- The C++ standard provides a string class that abstracts the internals of C string memory handling, therefore making it a little safer and less likely to expose vulnerabilities that occur when dealing with characters in C.
However, there is a need for conversion between C++ and C strings. Therefore, even a C++ program can be subjected to C string vulnerabilities.
Most C string handling vulnerabilities are the result of the unsafe use of a handful of functions:
Unbounded String Functions
#
The main problem with the following functions is that they are unbounded. That is, the destination buffer’s size isn’t taken into account when performing a data copy. Code auditors must examine each appearance of these functions in a codebase to determine whetehr they are called in a unsafe manner – meaning, wether these functions can be reached when the destination buffer isn’t large enough to contain the source content.
scanf
#
- Prototype:
int scanf (const char *format, ...)
- Return Value: Number of successfully matched and assigned input items, or EOF on failure
- Similar Functions: _tscanf, wscanf, sscanf, fscanf, fwscanf, _snscanf
- Purpose: The scanf() function parses input according to the format specified in the
format argument.
- Common Misuse: When strings are specified in the format string (using the
%s format specifier), the corresponding destination buffer must bee large enough to contain the string read from the data stream.
An example misuse:
int sport, cport;
char user[32], rtype[32], addinfo[32];
char buffer[1024];
if (read(sockfd, buffer, sizeof(buffer)) <= 0) {
perror("read : %m");
return -1;
}
buffer[sizeof(buffer) - 1] = '\0';
sscanf(buffer, "%d:%d:%s:%s:%s", &sport, &cport, rtype, user, addinfo);
The user, rtype, and addinfo variables are only 32 bytes long, so if the client supplies any of those fields with a string larger than 32 bytes, a buffer overflow would occur.
In addition, scanf has interesting semantics:
- The scanf family of functions, follows whitespace-based tokenization when reading formatted input:
-
%s skips leading whitespace:
The %s specifier automatically discards leading whitespace characters (spaces, tabs, newlines, etc.).
This means if command starts with whitespace, scanf() will skip past them until it finds a non-whitespace character.
-
%s stops at the next whitespace:
It reads characters until it encounters another whitespace (including spaces, newlines, and tabs).
This means trailing whitespace is not skipped but acts as a delimiter, effectively making it behave like a null byte (\0).
In addition, the destination buffer has to take into account the trailing null byte. Given the following example:
char a[] = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; // Exactly 32 'A's
char b[32];
sscanf(a, "%32s", b);
This would lead to an off-by-one overflow, writting the null byte to adjacent memory pass b in the stack.
sprintf
#
- Prototype:
int sprintf (char *str, const char *format, ...)
- Return Value: Number of characters written (excluding the null terminator)
- Similar Functions: _stprintf, _sprintf, _vsprintf, swprintf, … etc
- Purpose: The sprintf function prints a formatted string to a destination buffer.
- Common Misuse: destination buffer may not be large enough to hold formatted string.
The following is an example misuse of vsprintf:
WriteToLog(jrun_request *r, const char *szFormat, ...) {
va_list list;
char szBuf[2048];
strcpy(szBuf, r->stringRep);
va_start(list, szFormat);
vsprintf(strchr(szBuf, '\0'), szFormat, list);
va_end(list);
...
vsprintf() does not limit the number of characters it writes to szBuf.
If szFormat and its formatted arguments exceed the remaining space in szBuf, it will overwrite adjacent memory.
Note: The _wsprintfA() and _wsprintfW() functions copy a maximum of 1024 characters into the destination buffer, as opposed to the other sprintf() family of functions, as they copy as many characters as required.
strcpy
#
- Prototype:
char* strcpy (char *dst, char *src)
- Return Value: Pointer to the destination string
- Similar Functions: tcscpy, lstrcpyA, wcscpy, mbscpy … etc
- Purpose: The strcpy function copies the string located at src to the destination dst. It ceases copying when it encounters an end of string character (a
NUL byte).
- Common Misuse: destination buffer may not be large enough to hold source string.
char user[32];
char buffer[1024];
if (read(sockfd, buffer, sizeof(buffer)) <= 0) {
perror("read : %m");
return -1;
}
buffer[sizeof(buffer) - 1] = '\0';
strcpy(user, buffer);
strcpy is the memcpy equivalent function for string manipulation. Every misuse of a memcpy could be reproduced with strcpy. In addition, the length of the source buffer is computed as the distance of the first appearance of a NUL byte from the beginning of the string.
Note: strlen returns the lenght of the string as a size_t, without counting the null byte terminator.
strcat
#
- Prototype:
char* strcat (char *dst, char *src)
- Return Value: Pointer to the destination string
- Similar Functions: tcscat, wcscat, mbscat … etc
- Purpose: The strcat function is responsible for concatenating two strings together. The src string is appended to dst.
- Common Misuse: destination buffer may not be large enough to hold resulting concatenated string.
The following is a unsafe use of strchar, and a patch applying appropiately size checks that would make its use safe:
#define DEFAULT_DOMAIN "aaaaaaaaaaaa.com"
char user[32];
char buffer[1024];
if (read(sockfd, buffer, sizeof(buffer)) <= 0) {
perror("read : %m");
return -1;
}
buffer[sizeof(buffer) - 1] = '\0';
if (!strchr(buffer, '.'))
+ size_t buffer_len = strlen(buffer);
+ size_t domain_len = strlen(DEFAULT_DOMAIN);
+
+ if (buffer_len + domain_len < sizeof(buffer)) {
strcat(buffer, DEFAULT_DOMAIN);
+ }
Note: strchr returns a pointer to first occurrence of the character in the string, or NULL if not found before the first encounter of a null-terminating character. If source buffer is not null-terminated and a match is found, this function could potentially return a pointer to adyacent memory from the src buffer.
Bounded String Functions
#
These bounded string functions were originally designed to give programmers a safer alternative to the functions discussed in the previous section. These functions include a parameter in order to designate the length (or bounds) of the destination buffer. However these functions are still susceptible to misuse in more subtle ways. For instance it is important to check that the specified lenght is in fact correct.
snprintf
#
- Prototype:
int snprintf (char *dst, size_t n, char *fmt, ...)
- Return Value: Number of characters that would have been written (excluding null terminator)
- Similar Functions: sntprintf, snprintf, snwprintf, vsnpritnf, vsnwprintf, … etc
- Purpose: Just like sprintf, but witg a size parameter
- Common Misuse: n parameter may not be accurate, failing to describe that the destination buffer may not be large enough to hold resulting formatted string.
An interesting caveat of this function is that it works slightly differently on Windows than UNIX. On Windows, if truncation occurs and theres not enough room to fit all the data into the resulting buffer, a value of -1 is returned and NUL termination is not guaranteed. On the other hand on UNIX implementations, its guaranteed NUL termination, and the return value denotes the number of characters that wpuld have been written had there been enough room. That is, if the resulting buffer isn’t big enough to hold all the data, the destination buffer is null-terminated, and a positive integer is returned thats larged that the supplied buffer.
This difference in implementations can cause bugs when code is being ported from one platform to another. The following is an example:
#define BUFSIZ 4096
int log(int fd, char *fmt, ...) {
char buffer[BUFSIZ];
int n;
va_list ap;
va_start(ao, fmt);
n = vsnprintf(buffer, sizeof(buffer), fmt, ap);
if (n >= BUFSIZ - 2)
buffer[sizeof(buffer) - 2] = '\0';
strcat(buffer, "\n");
va_end(ap);
write_log(fd, buffer, strlen(buffer));
return 0;
}
The previous code works fine in UNIX systems, it checks to ensure that at least two bytes still remain in the buffer to fit the trailing newline character or it shortens the buffer so that the call to strcat doesn’t overflow.
However in Windows, if buffer is filled, n is set to -1, so the length check pases and the newline character is written outside of the buffer bounds.
strncpy
#
- Prototype:
char* strncpy (char *dst, char *src, size_t n)
- Return Value: Pointer to the destination string
- Similar Functions: tcsncpy, csncpy, wcscpyn, mbsncpy, … etc
- Purpose: The strncpy function copies the string located at src to the destination dst. It ceases copying when it encounters an end of string character (
NUL byte) or when n characters have been written to the destination buffer.
- Common Misuse: n parameter may not be accurate, failing to describe that the destination buffer may not be large enough to hold source string.
The strncpy function does not guarantee null-termination of the destination string. If the source is larger than the destination buffer, this function copies as many bytes as indicated by the size parameter and ceases copying without null-termination.
An example vulnerability that could arise from this is the following:
int is_username_valid(char *username) {
char *delim;
int c;
delim = strchr(name, ':');
if (delim) {
c = *delim;
*delim = '\0';
}
/* ... do some processing on the username ... */
*delim = c;
return 1;
}
int authenticate(int sockfd) {
char user[1024], *buffer;
size_t size;
int n, cmd;
cmd = read_integer(sockfd);
size = read_integer(sockfd);
if (size > MAX_PACKET)
return -1;
buffer = (char *)calloc(size + 1, sizeof(char));
if (!buffer)
return -1;
read_string(buffer, size);
switch (cmd) {
case USERNAME:
strncpy(user, buffer, sizeof(user));
if (!is_username_valid(user))
goto fail;
break;
// ...
}
}
The previous code copies data into a buffer by using strncpy but fails to explicitly null-terminate the destination buffer. This buffer is then passed as an argument to the is_username_valid function, which performs a strchr on it, potentially dereferencing out of bounds memory as the username buffer is not null-terminated.
strncat
#
- Prototype:
char* strncat (char *dst, char *src, size_t n)
- Return Value: Pointer to the destination string
- Similar Functions: tcsncat, wcsncat, mbsncat … etc
- Purpose: The strcat function is responsible for concatenating two strings together. The src string is appended to dst. It copies at most n bytes.
- Common Misuse: misunderstanfing the meaning of the size parameter n in ways that can cause memory corruption
strncat is nearly as dangerous as strcat, in that it’s quite easy to misuse. Specifically the size parameter can be confusing–it indicates the amount of space left in the buffer.
The first common mistake to make is supplying the size of the entire buffer instead of the size remaining in the buffer. This mistake is shown in the example below:
int copy_data(char *username) {
char buf[1024];
strcpy(buf, "username is: ");
strncat(buf, username, sizeof(buf));
log("%s\n", buf);
return 0;
}
The previous code snippet incorrectly supplies the buffer’s total size rather than the remaining size, thus allowing someone who can control the username arguemnt to overflow.
In addition, a more subtle mistake can be made. As previously mentioned, the size arguemnt represents how many bytes remain in the buffer without taking into account the terminating NUL byte. Therefore, the size parameter must be the the amount of spaceleft in the buffer, minus one.
The following example showcases this:
```c
int copy_data(char *username) {
char buf[1024];
strcpy(buf, "username is: ");
strncat(buf, username, sizeof(buf) - strlen(buf));
log("%s\n", buf);
return 0;
}
The previous code snippet does not account for the trailing NUL byte, showcasing an off-by-one vulnerability.
strlcpy
#
- Prototype:
size_t strlcpy (char *dst, char *src, size_t n)
- Return Value: Number of characters that would have been copied (excluding null terminator). If truncation occurs, the return value helps determine the needed buffer size
- Similar Functions: None
- Purpose: The strlcpy function acts exactly as strncpy, except it guaranteed that the destination buffer is NUL-terminated. The length argument includes space for the trailing NUL-byte.
- Common Misuse: destination buffer may not be large enough to hold resulting concatenated string.
Is important to highlight that the size returned by this function is the length of the source string (not including the NUL-byte), so the return value can be larger than the destination buffer’s size. The following is an example of how this can go wrong:
int qualify_username(char *username) {
char buf[1024];
size_t length;
length = strlcpy(buf, username, sizeof(buf));
strncat(buf, "@127.0.0.1", sizeof(buf) - length);
}
The length return value from strlcpy is used incorrectly in the previous example. If the username parameter to this functioin is longer than 1024 bytes the strncat() size parameter underflows and allows data to be copied out of the buffers bounds.
Note: Unlike strncpy, strlcpy always null-terminates (if size > 0)
strlcat
#
- Prototype:
size_t strlcat (char *dst, char *src, size_t n)
- Return Value: Number of characters that would have been written (excluding null terminator). If truncation occurs, the return value helps determine the required buffer size.
- Similar Functions: None
- Purpose: concatenates two strings together in much the same way as strncat.
For this function’s implementation, the size parameter has been changes with respect to strncat, so that is simplier to use. The size parameter for strlcat is the total size of the destination buffer instead of the remainng space left in the destinaiton buffer. Like strlcpy, strlcat returns the string length of the destination buffer plus the string length of the source buffer.
#
C String Manipulation Issues
Many of the most significant security vulnerabilities of the last decade are the result of memory corruption due to mishandling textual data, or logical flaws due to the misinterpretation of the content in textual data.
In C there is no native type for strings; instead, strings are formed by constructing arrays of char data type with the NUL character (0x00) marking the end of a string. Representing a string in this manner, entails that the length of the string is not associated with the buffer that contains it, and it is often not known until runtime.
This fact forces programmers to manage strings manually generally in one of two ways:
- To estimate how much memory to reserve for a statically sized array, or to dynamically allocate the amount of memory required when its known at runtime.
- The C++ standard provides a string class that abstracts the internals of C string memory handling, therefore making it a little safer and less likely to expose vulnerabilities that occur when dealing with characters in C. However, there is a need for conversion between C++ and C strings. Therefore, even a C++ program can be subjected to C string vulnerabilities.
Most C string handling vulnerabilities are the result of the unsafe use of a handful of functions:
Unbounded String Functions #
The main problem with the following functions is that they are unbounded. That is, the destination buffer’s size isn’t taken into account when performing a data copy. Code auditors must examine each appearance of these functions in a codebase to determine whetehr they are called in a unsafe manner – meaning, wether these functions can be reached when the destination buffer isn’t large enough to contain the source content.
scanf #
- Prototype:
int scanf (const char *format, ...) - Return Value: Number of successfully matched and assigned input items, or EOF on failure
- Similar Functions: _tscanf, wscanf, sscanf, fscanf, fwscanf, _snscanf
- Purpose: The scanf() function parses input according to the format specified in the
formatargument. - Common Misuse: When strings are specified in the format string (using the
%sformat specifier), the corresponding destination buffer must bee large enough to contain the string read from the data stream.
An example misuse:
int sport, cport;
char user[32], rtype[32], addinfo[32];
char buffer[1024];
if (read(sockfd, buffer, sizeof(buffer)) <= 0) {
perror("read : %m");
return -1;
}
buffer[sizeof(buffer) - 1] = '\0';
sscanf(buffer, "%d:%d:%s:%s:%s", &sport, &cport, rtype, user, addinfo);
The user, rtype, and addinfo variables are only 32 bytes long, so if the client supplies any of those fields with a string larger than 32 bytes, a buffer overflow would occur.
In addition, scanf has interesting semantics:
- The scanf family of functions, follows whitespace-based tokenization when reading formatted input:
-
%sskips leading whitespace: The%sspecifier automatically discards leading whitespace characters (spaces, tabs, newlines, etc.). This means if command starts with whitespace,scanf()will skip past them until it finds a non-whitespace character. -
%sstops at the next whitespace: It reads characters until it encounters another whitespace (including spaces, newlines, and tabs). This means trailing whitespace is not skipped but acts as a delimiter, effectively making it behave like a null byte (\0).
-
In addition, the destination buffer has to take into account the trailing null byte. Given the following example:
char a[] = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; // Exactly 32 'A's
char b[32];
sscanf(a, "%32s", b);
This would lead to an off-by-one overflow, writting the null byte to adjacent memory pass b in the stack.
sprintf #
- Prototype:
int sprintf (char *str, const char *format, ...) - Return Value: Number of characters written (excluding the null terminator)
- Similar Functions: _stprintf, _sprintf, _vsprintf, swprintf, … etc
- Purpose: The sprintf function prints a formatted string to a destination buffer.
- Common Misuse: destination buffer may not be large enough to hold formatted string.
The following is an example misuse of vsprintf:
WriteToLog(jrun_request *r, const char *szFormat, ...) {
va_list list;
char szBuf[2048];
strcpy(szBuf, r->stringRep);
va_start(list, szFormat);
vsprintf(strchr(szBuf, '\0'), szFormat, list);
va_end(list);
...
vsprintf() does not limit the number of characters it writes to szBuf.
If szFormat and its formatted arguments exceed the remaining space in szBuf, it will overwrite adjacent memory.
Note: The _wsprintfA() and _wsprintfW() functions copy a maximum of 1024 characters into the destination buffer, as opposed to the other sprintf() family of functions, as they copy as many characters as required.
strcpy #
- Prototype:
char* strcpy (char *dst, char *src) - Return Value: Pointer to the destination string
- Similar Functions: tcscpy, lstrcpyA, wcscpy, mbscpy … etc
- Purpose: The strcpy function copies the string located at src to the destination dst. It ceases copying when it encounters an end of string character (a
NULbyte). - Common Misuse: destination buffer may not be large enough to hold source string.
char user[32];
char buffer[1024];
if (read(sockfd, buffer, sizeof(buffer)) <= 0) {
perror("read : %m");
return -1;
}
buffer[sizeof(buffer) - 1] = '\0';
strcpy(user, buffer);
strcpy is the memcpy equivalent function for string manipulation. Every misuse of a memcpy could be reproduced with strcpy. In addition, the length of the source buffer is computed as the distance of the first appearance of a NUL byte from the beginning of the string.
Note:
strlenreturns the lenght of the string as a size_t, without counting the null byte terminator.
strcat #
- Prototype:
char* strcat (char *dst, char *src) - Return Value: Pointer to the destination string
- Similar Functions: tcscat, wcscat, mbscat … etc
- Purpose: The strcat function is responsible for concatenating two strings together. The src string is appended to dst.
- Common Misuse: destination buffer may not be large enough to hold resulting concatenated string.
The following is a unsafe use of strchar, and a patch applying appropiately size checks that would make its use safe:
#define DEFAULT_DOMAIN "aaaaaaaaaaaa.com"
char user[32];
char buffer[1024];
if (read(sockfd, buffer, sizeof(buffer)) <= 0) {
perror("read : %m");
return -1;
}
buffer[sizeof(buffer) - 1] = '\0';
if (!strchr(buffer, '.'))
+ size_t buffer_len = strlen(buffer);
+ size_t domain_len = strlen(DEFAULT_DOMAIN);
+
+ if (buffer_len + domain_len < sizeof(buffer)) {
strcat(buffer, DEFAULT_DOMAIN);
+ }
Note: strchr returns a pointer to first occurrence of the character in the string, or NULL if not found before the first encounter of a null-terminating character. If source buffer is not null-terminated and a match is found, this function could potentially return a pointer to adyacent memory from the src buffer.
Bounded String Functions #
These bounded string functions were originally designed to give programmers a safer alternative to the functions discussed in the previous section. These functions include a parameter in order to designate the length (or bounds) of the destination buffer. However these functions are still susceptible to misuse in more subtle ways. For instance it is important to check that the specified lenght is in fact correct.
snprintf #
- Prototype:
int snprintf (char *dst, size_t n, char *fmt, ...) - Return Value: Number of characters that would have been written (excluding null terminator)
- Similar Functions: sntprintf, snprintf, snwprintf, vsnpritnf, vsnwprintf, … etc
- Purpose: Just like sprintf, but witg a size parameter
- Common Misuse: n parameter may not be accurate, failing to describe that the destination buffer may not be large enough to hold resulting formatted string.
An interesting caveat of this function is that it works slightly differently on Windows than UNIX. On Windows, if truncation occurs and theres not enough room to fit all the data into the resulting buffer, a value of -1 is returned and NUL termination is not guaranteed. On the other hand on UNIX implementations, its guaranteed NUL termination, and the return value denotes the number of characters that wpuld have been written had there been enough room. That is, if the resulting buffer isn’t big enough to hold all the data, the destination buffer is null-terminated, and a positive integer is returned thats larged that the supplied buffer.
This difference in implementations can cause bugs when code is being ported from one platform to another. The following is an example:
#define BUFSIZ 4096
int log(int fd, char *fmt, ...) {
char buffer[BUFSIZ];
int n;
va_list ap;
va_start(ao, fmt);
n = vsnprintf(buffer, sizeof(buffer), fmt, ap);
if (n >= BUFSIZ - 2)
buffer[sizeof(buffer) - 2] = '\0';
strcat(buffer, "\n");
va_end(ap);
write_log(fd, buffer, strlen(buffer));
return 0;
}
The previous code works fine in UNIX systems, it checks to ensure that at least two bytes still remain in the buffer to fit the trailing newline character or it shortens the buffer so that the call to strcat doesn’t overflow.
However in Windows, if buffer is filled, n is set to -1, so the length check pases and the newline character is written outside of the buffer bounds.
strncpy #
- Prototype:
char* strncpy (char *dst, char *src, size_t n) - Return Value: Pointer to the destination string
- Similar Functions: tcsncpy, csncpy, wcscpyn, mbsncpy, … etc
- Purpose: The strncpy function copies the string located at src to the destination dst. It ceases copying when it encounters an end of string character (
NULbyte) or when n characters have been written to the destination buffer. - Common Misuse: n parameter may not be accurate, failing to describe that the destination buffer may not be large enough to hold source string.
The strncpy function does not guarantee null-termination of the destination string. If the source is larger than the destination buffer, this function copies as many bytes as indicated by the size parameter and ceases copying without null-termination.
An example vulnerability that could arise from this is the following:
int is_username_valid(char *username) {
char *delim;
int c;
delim = strchr(name, ':');
if (delim) {
c = *delim;
*delim = '\0';
}
/* ... do some processing on the username ... */
*delim = c;
return 1;
}
int authenticate(int sockfd) {
char user[1024], *buffer;
size_t size;
int n, cmd;
cmd = read_integer(sockfd);
size = read_integer(sockfd);
if (size > MAX_PACKET)
return -1;
buffer = (char *)calloc(size + 1, sizeof(char));
if (!buffer)
return -1;
read_string(buffer, size);
switch (cmd) {
case USERNAME:
strncpy(user, buffer, sizeof(user));
if (!is_username_valid(user))
goto fail;
break;
// ...
}
}
The previous code copies data into a buffer by using strncpy but fails to explicitly null-terminate the destination buffer. This buffer is then passed as an argument to the is_username_valid function, which performs a strchr on it, potentially dereferencing out of bounds memory as the username buffer is not null-terminated.
strncat #
- Prototype:
char* strncat (char *dst, char *src, size_t n) - Return Value: Pointer to the destination string
- Similar Functions: tcsncat, wcsncat, mbsncat … etc
- Purpose: The strcat function is responsible for concatenating two strings together. The src string is appended to dst. It copies at most n bytes.
- Common Misuse: misunderstanfing the meaning of the size parameter n in ways that can cause memory corruption
strncat is nearly as dangerous as strcat, in that it’s quite easy to misuse. Specifically the size parameter can be confusing–it indicates the amount of space left in the buffer.
The first common mistake to make is supplying the size of the entire buffer instead of the size remaining in the buffer. This mistake is shown in the example below:
int copy_data(char *username) {
char buf[1024];
strcpy(buf, "username is: ");
strncat(buf, username, sizeof(buf));
log("%s\n", buf);
return 0;
}
The previous code snippet incorrectly supplies the buffer’s total size rather than the remaining size, thus allowing someone who can control the username arguemnt to overflow.
In addition, a more subtle mistake can be made. As previously mentioned, the size arguemnt represents how many bytes remain in the buffer without taking into account the terminating NUL byte. Therefore, the size parameter must be the the amount of spaceleft in the buffer, minus one.
The following example showcases this:
```c
int copy_data(char *username) {
char buf[1024];
strcpy(buf, "username is: ");
strncat(buf, username, sizeof(buf) - strlen(buf));
log("%s\n", buf);
return 0;
}
The previous code snippet does not account for the trailing NUL byte, showcasing an off-by-one vulnerability.
strlcpy #
- Prototype:
size_t strlcpy (char *dst, char *src, size_t n) - Return Value: Number of characters that would have been copied (excluding null terminator). If truncation occurs, the return value helps determine the needed buffer size
- Similar Functions: None
- Purpose: The strlcpy function acts exactly as strncpy, except it guaranteed that the destination buffer is NUL-terminated. The length argument includes space for the trailing NUL-byte.
- Common Misuse: destination buffer may not be large enough to hold resulting concatenated string.
Is important to highlight that the size returned by this function is the length of the source string (not including the NUL-byte), so the return value can be larger than the destination buffer’s size. The following is an example of how this can go wrong:
int qualify_username(char *username) {
char buf[1024];
size_t length;
length = strlcpy(buf, username, sizeof(buf));
strncat(buf, "@127.0.0.1", sizeof(buf) - length);
}
The length return value from strlcpy is used incorrectly in the previous example. If the username parameter to this functioin is longer than 1024 bytes the strncat() size parameter underflows and allows data to be copied out of the buffers bounds.
Note: Unlike strncpy, strlcpy always null-terminates (if size > 0)
strlcat #
- Prototype:
size_t strlcat (char *dst, char *src, size_t n) - Return Value: Number of characters that would have been written (excluding null terminator). If truncation occurs, the return value helps determine the required buffer size.
- Similar Functions: None
- Purpose: concatenates two strings together in much the same way as strncat.
For this function’s implementation, the size parameter has been changes with respect to strncat, so that is simplier to use. The size parameter for strlcat is the total size of the destination buffer instead of the remainng space left in the destinaiton buffer. Like strlcpy, strlcat returns the string length of the destination buffer plus the string length of the source buffer.
Integer Manipulation Issues
Two’s Complement: A Brief Overview
#
Two’s complement is a binary representation used for signed integers in modern computer architectures. It simplifies arithmetic operations by making addition and subtraction work the same way for both positive and negative numbers.
How Two’s Complement Works
#
- Positive Numbers: Represented as usual in binary.
- Negative Numbers: To get the two’s complement of a number:
- Invert all bits (one’s complement).
- Add 1 to the result.
Examples (8-bit Representation)
#
Decimal
Binary (Two’s Complement)
0
00000000
+1
00000001
+127
01111111
-1
11111111 (Invert 00000001 → 11111110, add 1)
-128
10000000
Integer Ranges in Two’s Complement
#
Different integer types have different bit-widths, defining their value ranges.
Type
Size (bits)
Minimum Value (Decimal / Hex)
Maximum Value (Decimal / Hex)
int8_t8
-128 (0x80)
127 (0x7F)
uint8_t8
0 (0x00)
255 (0xFF)
int16_t16
-32,768 (0x8000)
32,767 (0x7FFF)
uint16_t16
0 (0x0000)
65,535 (0xFFFF)
int32_t32
-2,147,483,648 (0x80000000)
2,147,483,647 (0x7FFFFFFF)
uint32_t32
0 (0x00000000)
4,294,967,295 (0xFFFFFFFF)
int64_t64
-9,223,372,036,854,775,808 (0x8000000000000000)
9,223,372,036,854,775,807 (0x7FFFFFFFFFFFFFFF)
uint64_t64
0 (0x0000000000000000)
18,446,744,073,709,551,615 (0xFFFFFFFFFFFFFFFF)
Key Properties of Two’s Complement
#
- The Most Significant Bit (MSB) acts as the sign bit (0 = positive, 1 = negative).
- Overflow occurs when an operation results in a number outside the representable range.
- Negative numbers have their highest bit set to 1.
This system is used because it simplifies hardware design for arithmetic operations while avoiding issues like separate subtraction logic or multiple representations of zero.
Integer Type Conversions
#
Practical rules of thumb for integer type conversions:
- When converting from a narrower signed type to a wider signed type, sign extension will take place but the value will be preserved
- When converting from a narrower unsigned type to a wider unsigned type, zero extension will take place and the value will be preserved
- When converting from a narrower signed type to a wider unsigned type, sign extension will take place and the value may change
- When converting from a wider type to a narrower type, truncation will take place and the value may change
- When converting between signed and unsigned types of the same width, the bit pattern stays the same and the value may change
Conversions commonly take place in:
- Casts
- Assignments
- Function call parameters
- Function call returns
Integer Promotions
#
Integer Promotions specify how a narrow integer type like a char or a short, gets converted to an int. This promotion is used for two different purposes:
- Certain operators in C require an integer operand of type int or unsigned int. For these operators narrower types get promoted to the right type – int or unsigned int
- Integer promotions are a critical component of C rules for handling arithmetic expressions aka usual arithmetic conversions. In these cases, integer promotions are commonly applied to both operands.
If an integer type is narrower than an int, integer promotions almost always convert it to an int.
Source Type
Result Type
Rationale
unsigned charintPromote; source rank less than int rank
charintPromote; source rank less than int rank
shortintPromote; source rank less than int rank
unsigned shortintPromote; source rank less than int rank
intintDon’t promote; source rank equal to int rank
unsigned intunsigned intDon’t promote; source rank equal to int rank
long intlong intDon’t promote; source rank greater than int rank
floatfloatDon’t promote; source not of integer type
char *char*Don’t promote; source not of integer type
Integer Promotion Applications
#
- Unary + Operator: Performs integer promotions on its operand. For example if bob variable is of type char, the resulting type of the expression (+bob) is int, ini contrast with the resulting type of the expression (bob) being char
- Unary - Operator: Performs an integer promotion on its operand and then does a negation. Regardless of whether the operand is signed after the promotion, a twos complement negation is performed.
- Unary ~ Operator: Performs a one complement after doing an integer promotion on its operand.
- Bitwise Shift Operators: The integer promotions are applied to both arguments of the operator, and the type of the result is the same as the promoted type of the left operand:
char a = 1;
char c = 16;
int bob = a << c;
mov w8, #1
strb w8, [sp, #11]
mov w8, #16
strb w8, [sp, #10]
ldrb w8, [sp, #11]
ldrb w9, [sp, #10]
lsl w8, w8, w9
str w8, [sp, #4]
a is converted to an integer, and c is converted to an integer. The promoted type of the left operand is an int, so the type of the result is an int. The integer representation of a is left-shifted 16 times.
- Switch statements: Integer promotions are used in a switch statements. First they are applied to the controlling expression (
switch (controlling expression) {) so that the expression has a promoted type. Then, all the integer constants are converted to the type of the promoted controlled expression.
Usual Arithmetic Conversions
#
In many situations, C is expected to take two operands of potentially divergent types and perform some arithmetic operations that involved both of them. The C standard specifies an algorithm for reconciling two types into a compatible type for this purpose. The goal of these conversions iis to transform both operands into a common real type, which is used for the actual operation and then as the type of the result. These conversions only apply to arithmetic types – integer and floating point types.
Rule 1. Floating Points Take Precedence
#
Floating point types take precedence over integer types, so if one of the arguments in an arithmetic expression is a floating point type, the other argument is converted to a floating point type.
If one floating point type is less precise than the other, the less precise argument iis promoted to the type of the more precise argument
Rule 2. Apply Integer Promotions
#
Integer promotions are performed on both operands if neither of them is a floating point type. This means that any integer type smaller than an int is converted to an int, and anything thats the same width as an int, larger than an int or not an integer type is left alone. Following is an example:
unsigned char a = 255;
unsigned char b = 255;
if ((a + b) > 300)
return 10
mov w8, #255
strb w8, [sp, #11]
strb w8, [sp, #10]
ldrb w8, [sp, #11]
ldrb w9, [sp, #10]
add w8, w8, w9
subs w8, w8, #300
b.le .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #10
str w8, [sp, #12]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #12]
b .LBB0_3
In the expression within the if statement, the + operator causes the usual arithmetic conversions to be applied to its operands. Therefore a and b are both converted to ints, the addition takes place, and the resulting type of the expressions is an int that holds the result of the addition (510). Therefore work() will be invoked, even though it looks like the addition could cause a numeric overflow. Here is another example:
unsigned short a = 1;
if ((a - 5) <= 0)
return 10;
mov w8, #1
strh w8, [sp, #10]
ldrh w8, [sp, #10]
subs w8, w8, #5
subs w8, w8, #0
b.gt .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #10
str w8, [sp, #12]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #12]
b .LBB0_3
One would imagine that subtracting 5 to an unsigned short with the value of 1 will cause an underflow. However due to usual arithmetic conversions, both operands of the expression are converted to ints (a gets converted from unsigned short -> int and then an int with the value of 5 gets subtracted to it, resulting in a value of -4)
Rule 3. Same Type After Integer Promotions
#
If the two operands have different types after the integer promotions are applied, but they share the same signed-ness, the narrower type is converted to the type of the wider type. In other words, if both operands are signed or both operands are unsigned, the type with the lesser integer conversion rank is converted to the type of the operand with the higher conversion rank. This rule has nothing to do with short integers or characters because they have already been converted to integers by integer promotions. This rule is more applicable to arithmetic involving types of larger sizes such as long long int or long int:
int a = 5;
long int b = 6;
long long int c = (a + b);
mov w8, #5
str w8, [sp, #24]
mov x8, #6
str x8, [sp, #16]
ldrsw x8, [sp, #24]
ldr x9, [sp, #16]
add x8, x8, x9
str x8, [sp, #8]
In the previous example, integer promotions do not change any of the types of the expression because they are equal or higher width than an int type. So this rule mandates that the int a be converted into a long int before addition occurs. The resulting long int type is converted into a long long int on the assignment to c.
Rule 5. Unsigned Type Wider Than or Same Width as Signed Type
#
If an unsigned operand is of greater integer conversion rank than the signed operand, or their ranks are equal, you convert the signed operand to the type of the unsigned operand. This behavior can be surprising as it leads to situations as follows:
int a = -5;
if (a <= sizeof(int))
return 10;
mov w8, #-5
str w8, [sp, #8]
ldrsw x8, [sp, #8]
subs x8, x8, #4
b.hi .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #10
str w8, [sp, #12]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #12]
b .LBB0_3
The comparison operator < causes the usual arithmetic conversions to be applied to both operands. Integer promotions are applied to a and to sizeof(int), but these conversions do not affect them. Then the type of a is evaluated to be a signed integer, and sizeof(int) returns a size_t which is an unsigned integer. Since size_t has a greater integer conversion rank, the unsigned type takes precedence by this rule, and a gets converted to an unsigned integer type, having the following:
if (4294967291 <= 4)
return 10;
Rule 6. Signed Type Wider Than Unsigned Type, Value Preservation Possible.
#
If the signed operand is of greater integer conversion rank than the unsigned operand, and value-preserving conversion can be made from the unsigned integer type to the signed type, everything gets converted to the signed integer type:
long long int a = 10;
unsigned int b = 5;
if (a + b <= 0)
return 1;
mov x8, #10
str x8, [sp, #16]
mov w8, #5
str w8, [sp, #12]
ldr x8, [sp, #16]
ldr w9, [sp, #12]
add x8, x8, x9
subs x8, x8, #0
b.gt .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #1
str w8, [sp, #28]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #28]
b .LBB0_3
The signed argument, a long long int can represent all the values of the unsigned argument, an unsigned int. So the compiler would convert both operands to the signed operand’s type – long long int
Rule 7. Signed Type Wider Than Unsigned Type, Value Preservation Impossible
#
If the signed integer type has a greater integer conversion rank than the unsigned integer type, the signed integer type gets converted to its corresponding unsigned integer representation, and then both operands get converted to that type:
unsigned int a = 10;
long int b = 20;
if (a + b <= 10)
return 1;
add r7, sp, #0
movs r3, #10
str r3, [r7, #4]
movs r3, #20
str r3, [r7]
ldr r2, [r7]
ldr r3, [r7, #4]
add r3, r3, r2
cmp r3, #10
bhi .L2
movs r3, #1
b .L3
For the purpose of this example, lets assume we are on a 32bit machine, such as the width of long int and unsigned int is the same of 4 bytes. The signed type (long int) is of higher rank than the unsigned type (unsigned int). The signed type cannot hold all the values of the unsigned type. Therefore, the signed operand type will be converted to unsigned (unsigned long int) and then convert both operands to this type. The addition expression will have a unsigned long int resulting value of 30.
Summary:
#
- If either operand is a floating point type, convert all operands to the operand’s floating point type with highest precision. Done
- Perform integer promotions to both operands. If the two operands are now of the same type, we are done.
- If the two operands share the same signed-ness, convert the operand with the lower integer conversion rank to the type of the operand with of the higher integer conversion rank. Done
- If the unsigned operand is of higher or equal higher conversion rank than the signed operand, convert the signed operand to the type of the unsigned operand. Done
- If the signed operand is of higher integer conversion rank than the unsigned operand, and you can perform a value-preserving conversion, convert the unsigned operand type to the signed operand type. Done
- If the signed operand is of higher integer conversion rank than the unsigned operand, but you can’t perform a value-preserving conversion, convert both operands to the unsigned type corresponding to the type of the signed operand.
Sign Extension
#
Sign extension occurs when a smaller signed integer type is converted to a larger type, and the machine propagates the sign bit of the smaller type through the unused bits of the larger type.
The intent of sign extension is that the conversion is value-preserving when going from a smaller signed type to a larger signed type.
Sign extension can occur in a number of ways:
- If a simple conversion is made from a small signed type to a larger type, with a typecast, assignment, or function call.
- if a signed type smaller than an integer is promoted via integer promotions
- if the usual arithmetic conversions is applied to a type after integer promotions, because a signed integer type could be promoted to a larger type, such as long long.
There are two main reasons why sign extension could be assess as a security issue:
- In certain cases, sign extension is a value-changing conversion that has an unexpected result.
- Developers often forget that the char and short types they use are signed
Its specially important to remember that sign conversion takes place when converting from a smaller signed type to a larger unsigned type.
The following example showcases an vulnerability due to sign conversion:
1unsigned short read_length(int sockfd) {
2 unsigned short len;
3
4 if (full_read(sockfd, (void*)&len, 2) != 2)
5 die("could not read length!\n");
6
7 return ntohs(len);
8}
9
10int read_packet(int sockfd) {
11 struct header hdr;
12 short length;
13 char *buffer;
14 size_t n;
15
16 length = read_length(sockfd);
17
18 if (length > 1024) {
19 error("read_packet: length too large: %d\n", length);
20 return -1;
21 }
22
23 buffer = (char*)malloc(length + 1);
24
25 if ((n = read(sockfd, buffer, length)) < 0) {
26 perror("read: %m");
27 free(buffer);
28 return -1;
29 }
30
31 buffer[n] = '\0';
32 return 0;
33}
Lets break the previous example down:
- At line 16, the result of
read_length returns an unsigned short, which is converted into a signed short and store in the variable length.
- In the following length check at line 18, both sides of the comparison are promoted to integers. If the value of
length is an negative number, it would bypass the if statement check that tests wteher it’s greater than 1024.
- At line 23, the value of length its added one and its passed as the first argument to
malloc. The length parameter is again sign-extended because its promoted to an integer for the addition. Therefore, if the specified length is 0xffff, it’s sign-extended to 0xffffffff.
- The addition of this value plus 1, wraps around to 0, and malloc(0) will potentially return a very small chunk.
- Finally, at line 25 the call to read causes the third argument, the
length parameter to be converted directly from a signed short to a size_t. Sign extension occurs here aswell because a smaller signed type its been converted to a larger unsigned type. Therefore the call to read allows to read a large number of bytes into the buffer, resulting into a buffer overflow
Sign extensions seems as though it should be ubiquiotous and mostly harmless in C code. However, programmers rarely intend for their smaller data types to be sign-extended when they are converted, and the presence of sign extension often indicates a bug.
Sign extensions are often difficult to locate in C/C++, but in some cases it shows up well in assembly code. Here are a few examples:
Sign-Extension Example:
#
int8_t c = -5;
unsigned int a = c;
ARM64 clang
mov w8, #251
strb w8, [sp, #15]
ldrsb w8, [sp, #15]
str w8, [sp, #8]
x86_64 clang
mov byte ptr [rbp - 1], -5
movsx eax, byte ptr [rbp - 1]
mov dword ptr [rbp - 8], eax
Zero-Extension Example:
#
uint8_t c = 5;
unsigned int a = c;
ARM64 clang
mov w8, #5
strb w8, [sp, #15]
ldrb w8, [sp, #15]
str w8, [sp, #8]
x86_64 clang
mov byte ptr [rbp - 1], 5
movzx eax, byte ptr [rbp - 1]
mov dword ptr [rbp - 8], eax
As you can observe, different architectures are more verbose than others when instructions are performing sign-extension operations. Therefore, we should be able to remmeber and to take into account the fundamental rules for sign-extension when auditing C/C++ code bases.
Truncation
#
Truncation occurs when a larger type is converted into a smaller type. Note that the usual airthmetic conversions and integer promotions are never really call for a large type to be converted to a smaller type.
Therefore, truncation can only occur as the result of an assignment, a typecase, or a function call involving a prototype.
The following is an example of truncation:
int a = 0x12345678;
short b = a;
When a is assigned to b the top 16 bits of the value are truncated, and h has a value of 0x5678.
This lost in precision could potentially lead into security failures. The following is an example:
void assume_privs(unsigned short uid) {
seteuid(uid);
setuid(uid);
}
int become_user(int uid) {
if (uid == 0)
die("root isn't allowed\n");
assume_privs(uid);
}
if attackers could pass arbitrary uid parameter to the become_user function, they could pass the uid of 0x10000 (65536), which after truncation to an unsigned short, the uid would have the value of 0, and attackers could gain root privileges.
The following is another example:
unsigned short len;
char mybuf[1024];
char *userstr = getuserstr();
len = strlen(userstr);
if (len > sizeof(mybuf) - 5)
die("string too long!");
strcpy(mybuf, userstr);
In the previous example, if the result of the previous strlen call would return 0x10000, the variable len after integer truncation will hold the value of 0, bypassing the len check, but cause a buffer overflow on the strcpy call.
here is a last example:
1char custom_strcmp(const char *str1, const char *str2) {
2 unsigned int *ptr1 = (unsigned int*)str1;
3 unsigned int *ptr2 = (unsigned int*)str2;
4 unsigned int i = 0;
5
6 size_t len1 = strlen(str1);
7 size_t len2 = strlen(str2);
8
9 if (len1 != len2 || strlen(len1) != 10)
10 return -1;
11
12 for (i = 0; i < len1 / 4; i++) {
13 if (ptr1[i] != ptr2[i])
14 return ptr1[i] - ptr2[i];
15 }
16
17 i *= 4;
18
19 for (i; i < len1; i++) {
20 if (str1[i] != str2[i])
21 return str1[i] - str2[i]
22 }
23
24 return 0;
25
26}
27
28void main(int argc, char **argv) {
29 if (argc != 2)
30 return;
31
32 if (!custom_strcmp(SECRET, argv[1])) {
33 puts("Success");
34 } else {
35 puts("Failure");
36 }
37
38 return;
39}
In the previous snippet, we can observe the implementation of a custom strcmp function. This function is used against the first supplied console argument to the program, and its compared against a custom secret string. Both the user supplied input and the secret string are 10 characters long.
The custom strcmp function is splitted into two different for loops. An initial one that is meant to compare pairs of integers from the secret string and the user supplied input. The second for loop goes over the last index that was divisible by four in the user supplied input (8), and it will iterate for 2 more iterations until it reaches the size of 10.
If one takes a close look at the function prototype of custom_strcmp, we can observe that its meant to return a char type. However we can observe that at line 11, its returning an unsigned int, that then later is truncated to a byte. This means that the original intent of that initial top for-loop was to compare 4 bytes of the input string against the secret string at a time. However due to integer truncation, only the last significant byte will be evaluated. Therefore this condition makes this function bruteforcable, as due to this integer truncation we can brute-force the first byte of the password until the "Success" string gets printed.
More Integer Vulnerability Examples
#
CVE-2019-14196
#
1// Globals
2static char filefh[NFS3_FHSIZE]; /* NFSv2 / NFSv3 file handle */
3static int filefh3_length; /* (variable) length of filefh when NFSv3 */
4
5////ACID: pkt
6static int nfs_lookup_reply(uchar *pkt, unsigned len)
7{
8 struct rpc_t rpc_pkt;
9
10 debug("%s\n", __func__);
11
12 memcpy(&rpc_pkt.u.data[0], pkt, len);
13
14// ...
15
16 if (supported_nfs_versions & NFSV2_FLAG) {
17 memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
18 } else { /* NFSV3_FLAG */
19 filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
20 if (filefh3_length > NFS3_FHSIZE)
21 filefh3_length = NFS3_FHSIZE;
22 memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length);
23 }
24
25 return 0;
26}
This is a classic wrong integer size check or also known as “signed size insanity check” due to confussion of signess.
The global variable filefh3_length is of type int, therefore it can hold negative values. At line 19, filefh3_length is initialized by the result of ntohl against rpc_pkt.u.reply.data[1] which is ACID.
If the value returned turns out to be negative, the check at line 20 won’t hold, and on line 22 filefh3_length will be implicitly converted from an int to a size_t for the third parameter of memcpy, making the memcpy size field a very large unsigned integer therefore leading to a buffer overflow on filefh, as it of size NFS3_FHSIZE.
CVE-2021-33909
#
////NOTE: Start reading the code at seq_read_iter()
/**
* seq_has_overflowed - check if the buffer has overflowed
* @m: the seq_file handle
*
* seq_files have a buffer which may overflow. When this happens a larger
* buffer is reallocated and all the data will be printed again.
* The overflow state is true when m->count == m->size.
*
* Returns true if the buffer received more than it can hold.
*/
static inline bool seq_has_overflowed(struct seq_file *m)
{
return m->count == m->size;
}
//------------------------------------------------------------------------
135 static int show_mountinfo(struct seq_file *m, struct vfsmount *mnt) //KC: called by "m->op->show(m, p)"
136 {
...
150 seq_dentry(m, mnt->mnt_root, " \t\n\\");
//------------------------------------------------------------------------
523 int seq_dentry(struct seq_file *m, struct dentry *dentry, const char *esc)
524 {
525 char *buf;
526 size_t size = seq_get_buf(m, &buf);
...
529 if (size) {
530 char *p = dentry_path(dentry, buf, size);
//------------------------------------------------------------------------
380 char *dentry_path(struct dentry *dentry, char *buf, int buflen)
381 {
382 char *p = NULL;
...
385 if (d_unlinked(dentry)) { //KC: assume true
386 p = buf + buflen;
387 if (prepend(&p, &buflen, "//deleted", 10) != 0)
//------------------------------------------------------------------------
11 static int prepend(char **buffer, int *buflen, const char *str, int namelen)
12 {
13 *buflen -= namelen;
14 if (*buflen < 0)
15 return -ENAMETOOLONG;
16 *buffer -= namelen;
17 memcpy(*buffer, str, namelen);
//------------------------------------------------------------------------
////ACID: Assume the attacker can control the underlying seq_file to cause the while(1) loop to occur as many times as they want
168 ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
169 {
170 struct seq_file *m = iocb->ki_filp->private_data;
...
205 /* grab buffer if we didn't have one */
206 if (!m->buf) { //KC: assume this is NULL on the first iteration
207 m->buf = seq_buf_alloc(m->size = PAGE_SIZE); //KC: m->size is a size_t
...
210 }
...
220 // get a non-empty record in the buffer
...
223 while (1) {
...
227 err = m->op->show(m, p); //KC: This calls to show_mountinfo()
...
236 if (!seq_has_overflowed(m)) // got it
237 goto Fill;
238 // need a bigger buffer
...
240 kvfree(m->buf);
...
242 m->buf = seq_buf_alloc(m->size <<= 1);
...
246 }
An attacker can gain control over the variable seq_file at line 170 in seq_read_iter, it then allocates a page size for m->buf, and then it iterates indefinitely on the while loop at line 223.
At this point we see that m->op->show(m, p) gets invoked, which results in show_mountinfo() being invoked. We can see that show_mountinfo() invokes seq_dentry() with our controlled seq_file, m.
In seq_dentry() at line 256, we can se that is fetching the m->buf via seq_get_buf(), and the return value will be the buffer’s size size stored as a size_t. If size is not 0, dentry_path() will be invoked passing our m->buf and its size as the second and third parameters buf and size respectively.
We can immediately note by dentry_path() prototype, that the third parameter buflen is of type int. This means that with respect to the original type of size passed to dentry_path() as a size_t, by the time execution-flow reaches dentry_path, size will be truncated to a 32-bit integer from a 64bit size_t, but also interpreted as a signed integer.
On line 386 we can see how the variable p is initlized as the buf base being a (char *) plus buflen, which if its a negative integer value (say 0x80000000 (-2147483648)), this would result in faulty pointer arithmetic, calculating a pointer that will point before the start of the buffer buf. This later becomes an issue following the data flow through prepend(), as the value of buffer (our former buf corrupted pointer from dentry_path()) is substracted the value of 10, to then later conduct a memcpy to it.
This example highlights that integer type conversions should be closely examined across function boundaries, as if these are not done properly can cause issues as the one showed in this example.
#
Integer Manipulation Issues
Two’s Complement: A Brief Overview #
Two’s complement is a binary representation used for signed integers in modern computer architectures. It simplifies arithmetic operations by making addition and subtraction work the same way for both positive and negative numbers.
How Two’s Complement Works #
- Positive Numbers: Represented as usual in binary.
- Negative Numbers: To get the two’s complement of a number:
- Invert all bits (one’s complement).
- Add 1 to the result.
Examples (8-bit Representation) #
| Decimal | Binary (Two’s Complement) |
|---|---|
| 0 | 00000000 |
| +1 | 00000001 |
| +127 | 01111111 |
| -1 | 11111111 (Invert 00000001 → 11111110, add 1) |
| -128 | 10000000 |
Integer Ranges in Two’s Complement #
Different integer types have different bit-widths, defining their value ranges.
| Type | Size (bits) | Minimum Value (Decimal / Hex) | Maximum Value (Decimal / Hex) |
|---|---|---|---|
int8_t |
8 | -128 (0x80) |
127 (0x7F) |
uint8_t |
8 | 0 (0x00) |
255 (0xFF) |
int16_t |
16 | -32,768 (0x8000) |
32,767 (0x7FFF) |
uint16_t |
16 | 0 (0x0000) |
65,535 (0xFFFF) |
int32_t |
32 | -2,147,483,648 (0x80000000) |
2,147,483,647 (0x7FFFFFFF) |
uint32_t |
32 | 0 (0x00000000) |
4,294,967,295 (0xFFFFFFFF) |
int64_t |
64 | -9,223,372,036,854,775,808 (0x8000000000000000) |
9,223,372,036,854,775,807 (0x7FFFFFFFFFFFFFFF) |
uint64_t |
64 | 0 (0x0000000000000000) |
18,446,744,073,709,551,615 (0xFFFFFFFFFFFFFFFF) |
Key Properties of Two’s Complement #
- The Most Significant Bit (MSB) acts as the sign bit (0 = positive, 1 = negative).
- Overflow occurs when an operation results in a number outside the representable range.
- Negative numbers have their highest bit set to 1.
This system is used because it simplifies hardware design for arithmetic operations while avoiding issues like separate subtraction logic or multiple representations of zero.
Integer Type Conversions #
Practical rules of thumb for integer type conversions:
- When converting from a narrower signed type to a wider signed type, sign extension will take place but the value will be preserved
- When converting from a narrower unsigned type to a wider unsigned type, zero extension will take place and the value will be preserved
- When converting from a narrower signed type to a wider unsigned type, sign extension will take place and the value may change
- When converting from a wider type to a narrower type, truncation will take place and the value may change
- When converting between signed and unsigned types of the same width, the bit pattern stays the same and the value may change
Conversions commonly take place in:
- Casts
- Assignments
- Function call parameters
- Function call returns
Integer Promotions #
Integer Promotions specify how a narrow integer type like a char or a short, gets converted to an int. This promotion is used for two different purposes:
- Certain operators in C require an integer operand of type int or unsigned int. For these operators narrower types get promoted to the right type – int or unsigned int
- Integer promotions are a critical component of C rules for handling arithmetic expressions aka usual arithmetic conversions. In these cases, integer promotions are commonly applied to both operands.
If an integer type is narrower than an int, integer promotions almost always convert it to an int.
| Source Type | Result Type | Rationale |
|---|---|---|
unsigned char |
int |
Promote; source rank less than int rank |
char |
int |
Promote; source rank less than int rank |
short |
int |
Promote; source rank less than int rank |
unsigned short |
int |
Promote; source rank less than int rank |
int |
int |
Don’t promote; source rank equal to int rank |
unsigned int |
unsigned int |
Don’t promote; source rank equal to int rank |
long int |
long int |
Don’t promote; source rank greater than int rank |
float |
float |
Don’t promote; source not of integer type |
char * |
char* |
Don’t promote; source not of integer type |
Integer Promotion Applications #
- Unary + Operator: Performs integer promotions on its operand. For example if bob variable is of type char, the resulting type of the expression (+bob) is int, ini contrast with the resulting type of the expression (bob) being char
- Unary - Operator: Performs an integer promotion on its operand and then does a negation. Regardless of whether the operand is signed after the promotion, a twos complement negation is performed.
- Unary ~ Operator: Performs a one complement after doing an integer promotion on its operand.
- Bitwise Shift Operators: The integer promotions are applied to both arguments of the operator, and the type of the result is the same as the promoted type of the left operand:
char a = 1;
char c = 16;
int bob = a << c;
mov w8, #1
strb w8, [sp, #11]
mov w8, #16
strb w8, [sp, #10]
ldrb w8, [sp, #11]
ldrb w9, [sp, #10]
lsl w8, w8, w9
str w8, [sp, #4]
a is converted to an integer, and c is converted to an integer. The promoted type of the left operand is an int, so the type of the result is an int. The integer representation of a is left-shifted 16 times.
- Switch statements: Integer promotions are used in a switch statements. First they are applied to the controlling expression (
switch (controlling expression) {) so that the expression has a promoted type. Then, all the integer constants are converted to the type of the promoted controlled expression.
Usual Arithmetic Conversions #
In many situations, C is expected to take two operands of potentially divergent types and perform some arithmetic operations that involved both of them. The C standard specifies an algorithm for reconciling two types into a compatible type for this purpose. The goal of these conversions iis to transform both operands into a common real type, which is used for the actual operation and then as the type of the result. These conversions only apply to arithmetic types – integer and floating point types.
Rule 1. Floating Points Take Precedence #
Floating point types take precedence over integer types, so if one of the arguments in an arithmetic expression is a floating point type, the other argument is converted to a floating point type. If one floating point type is less precise than the other, the less precise argument iis promoted to the type of the more precise argument
Rule 2. Apply Integer Promotions #
Integer promotions are performed on both operands if neither of them is a floating point type. This means that any integer type smaller than an int is converted to an int, and anything thats the same width as an int, larger than an int or not an integer type is left alone. Following is an example:
unsigned char a = 255;
unsigned char b = 255;
if ((a + b) > 300)
return 10
mov w8, #255
strb w8, [sp, #11]
strb w8, [sp, #10]
ldrb w8, [sp, #11]
ldrb w9, [sp, #10]
add w8, w8, w9
subs w8, w8, #300
b.le .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #10
str w8, [sp, #12]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #12]
b .LBB0_3
In the expression within the if statement, the + operator causes the usual arithmetic conversions to be applied to its operands. Therefore a and b are both converted to ints, the addition takes place, and the resulting type of the expressions is an int that holds the result of the addition (510). Therefore work() will be invoked, even though it looks like the addition could cause a numeric overflow. Here is another example:
unsigned short a = 1;
if ((a - 5) <= 0)
return 10;
mov w8, #1
strh w8, [sp, #10]
ldrh w8, [sp, #10]
subs w8, w8, #5
subs w8, w8, #0
b.gt .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #10
str w8, [sp, #12]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #12]
b .LBB0_3
One would imagine that subtracting 5 to an unsigned short with the value of 1 will cause an underflow. However due to usual arithmetic conversions, both operands of the expression are converted to ints (a gets converted from unsigned short -> int and then an int with the value of 5 gets subtracted to it, resulting in a value of -4)
Rule 3. Same Type After Integer Promotions #
If the two operands have different types after the integer promotions are applied, but they share the same signed-ness, the narrower type is converted to the type of the wider type. In other words, if both operands are signed or both operands are unsigned, the type with the lesser integer conversion rank is converted to the type of the operand with the higher conversion rank. This rule has nothing to do with short integers or characters because they have already been converted to integers by integer promotions. This rule is more applicable to arithmetic involving types of larger sizes such as long long int or long int:
int a = 5;
long int b = 6;
long long int c = (a + b);
mov w8, #5
str w8, [sp, #24]
mov x8, #6
str x8, [sp, #16]
ldrsw x8, [sp, #24]
ldr x9, [sp, #16]
add x8, x8, x9
str x8, [sp, #8]
In the previous example, integer promotions do not change any of the types of the expression because they are equal or higher width than an int type. So this rule mandates that the int a be converted into a long int before addition occurs. The resulting long int type is converted into a long long int on the assignment to c.
Rule 5. Unsigned Type Wider Than or Same Width as Signed Type #
If an unsigned operand is of greater integer conversion rank than the signed operand, or their ranks are equal, you convert the signed operand to the type of the unsigned operand. This behavior can be surprising as it leads to situations as follows:
int a = -5;
if (a <= sizeof(int))
return 10;
mov w8, #-5
str w8, [sp, #8]
ldrsw x8, [sp, #8]
subs x8, x8, #4
b.hi .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #10
str w8, [sp, #12]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #12]
b .LBB0_3
The comparison operator < causes the usual arithmetic conversions to be applied to both operands. Integer promotions are applied to a and to sizeof(int), but these conversions do not affect them. Then the type of a is evaluated to be a signed integer, and sizeof(int) returns a size_t which is an unsigned integer. Since size_t has a greater integer conversion rank, the unsigned type takes precedence by this rule, and a gets converted to an unsigned integer type, having the following:
if (4294967291 <= 4)
return 10;
Rule 6. Signed Type Wider Than Unsigned Type, Value Preservation Possible. #
If the signed operand is of greater integer conversion rank than the unsigned operand, and value-preserving conversion can be made from the unsigned integer type to the signed type, everything gets converted to the signed integer type:
long long int a = 10;
unsigned int b = 5;
if (a + b <= 0)
return 1;
mov x8, #10
str x8, [sp, #16]
mov w8, #5
str w8, [sp, #12]
ldr x8, [sp, #16]
ldr w9, [sp, #12]
add x8, x8, x9
subs x8, x8, #0
b.gt .LBB0_2
b .LBB0_1
.LBB0_1:
mov w8, #1
str w8, [sp, #28]
b .LBB0_3
.LBB0_2:
str wzr, [sp, #28]
b .LBB0_3
The signed argument, a long long int can represent all the values of the unsigned argument, an unsigned int. So the compiler would convert both operands to the signed operand’s type – long long int
Rule 7. Signed Type Wider Than Unsigned Type, Value Preservation Impossible #
If the signed integer type has a greater integer conversion rank than the unsigned integer type, the signed integer type gets converted to its corresponding unsigned integer representation, and then both operands get converted to that type:
unsigned int a = 10;
long int b = 20;
if (a + b <= 10)
return 1;
add r7, sp, #0
movs r3, #10
str r3, [r7, #4]
movs r3, #20
str r3, [r7]
ldr r2, [r7]
ldr r3, [r7, #4]
add r3, r3, r2
cmp r3, #10
bhi .L2
movs r3, #1
b .L3
For the purpose of this example, lets assume we are on a 32bit machine, such as the width of long int and unsigned int is the same of 4 bytes. The signed type (long int) is of higher rank than the unsigned type (unsigned int). The signed type cannot hold all the values of the unsigned type. Therefore, the signed operand type will be converted to unsigned (unsigned long int) and then convert both operands to this type. The addition expression will have a unsigned long int resulting value of 30.
Summary: #
- If either operand is a floating point type, convert all operands to the operand’s floating point type with highest precision. Done
- Perform integer promotions to both operands. If the two operands are now of the same type, we are done.
- If the two operands share the same signed-ness, convert the operand with the lower integer conversion rank to the type of the operand with of the higher integer conversion rank. Done
- If the unsigned operand is of higher or equal higher conversion rank than the signed operand, convert the signed operand to the type of the unsigned operand. Done
- If the signed operand is of higher integer conversion rank than the unsigned operand, and you can perform a value-preserving conversion, convert the unsigned operand type to the signed operand type. Done
- If the signed operand is of higher integer conversion rank than the unsigned operand, but you can’t perform a value-preserving conversion, convert both operands to the unsigned type corresponding to the type of the signed operand.
Sign Extension #
Sign extension occurs when a smaller signed integer type is converted to a larger type, and the machine propagates the sign bit of the smaller type through the unused bits of the larger type. The intent of sign extension is that the conversion is value-preserving when going from a smaller signed type to a larger signed type.
Sign extension can occur in a number of ways:
- If a simple conversion is made from a small signed type to a larger type, with a typecast, assignment, or function call.
- if a signed type smaller than an integer is promoted via integer promotions
- if the usual arithmetic conversions is applied to a type after integer promotions, because a signed integer type could be promoted to a larger type, such as long long.
There are two main reasons why sign extension could be assess as a security issue:
- In certain cases, sign extension is a value-changing conversion that has an unexpected result.
- Developers often forget that the char and short types they use are signed
Its specially important to remember that sign conversion takes place when converting from a smaller signed type to a larger unsigned type.
The following example showcases an vulnerability due to sign conversion:
1unsigned short read_length(int sockfd) {
2 unsigned short len;
3
4 if (full_read(sockfd, (void*)&len, 2) != 2)
5 die("could not read length!\n");
6
7 return ntohs(len);
8}
9
10int read_packet(int sockfd) {
11 struct header hdr;
12 short length;
13 char *buffer;
14 size_t n;
15
16 length = read_length(sockfd);
17
18 if (length > 1024) {
19 error("read_packet: length too large: %d\n", length);
20 return -1;
21 }
22
23 buffer = (char*)malloc(length + 1);
24
25 if ((n = read(sockfd, buffer, length)) < 0) {
26 perror("read: %m");
27 free(buffer);
28 return -1;
29 }
30
31 buffer[n] = '\0';
32 return 0;
33}
Lets break the previous example down:
- At line 16, the result of
read_lengthreturns an unsigned short, which is converted into a signed short and store in the variablelength. - In the following length check at line 18, both sides of the comparison are promoted to integers. If the value of
lengthis an negative number, it would bypass the if statement check that tests wteher it’s greater than 1024. - At line 23, the value of length its added one and its passed as the first argument to
malloc. The length parameter is again sign-extended because its promoted to an integer for the addition. Therefore, if the specified length is 0xffff, it’s sign-extended to 0xffffffff. - The addition of this value plus 1, wraps around to 0, and malloc(0) will potentially return a very small chunk.
- Finally, at line 25 the call to read causes the third argument, the
lengthparameter to be converted directly from a signed short to asize_t. Sign extension occurs here aswell because a smaller signed type its been converted to a larger unsigned type. Therefore the call to read allows to read a large number of bytes into the buffer, resulting into a buffer overflow
Sign extensions seems as though it should be ubiquiotous and mostly harmless in C code. However, programmers rarely intend for their smaller data types to be sign-extended when they are converted, and the presence of sign extension often indicates a bug.
Sign extensions are often difficult to locate in C/C++, but in some cases it shows up well in assembly code. Here are a few examples:
Sign-Extension Example: #
int8_t c = -5;
unsigned int a = c;
ARM64 clang
mov w8, #251
strb w8, [sp, #15]
ldrsb w8, [sp, #15]
str w8, [sp, #8]
x86_64 clang
mov byte ptr [rbp - 1], -5
movsx eax, byte ptr [rbp - 1]
mov dword ptr [rbp - 8], eax
Zero-Extension Example: #
uint8_t c = 5;
unsigned int a = c;
ARM64 clang
mov w8, #5
strb w8, [sp, #15]
ldrb w8, [sp, #15]
str w8, [sp, #8]
x86_64 clang
mov byte ptr [rbp - 1], 5
movzx eax, byte ptr [rbp - 1]
mov dword ptr [rbp - 8], eax
As you can observe, different architectures are more verbose than others when instructions are performing sign-extension operations. Therefore, we should be able to remmeber and to take into account the fundamental rules for sign-extension when auditing C/C++ code bases.
Truncation #
Truncation occurs when a larger type is converted into a smaller type. Note that the usual airthmetic conversions and integer promotions are never really call for a large type to be converted to a smaller type. Therefore, truncation can only occur as the result of an assignment, a typecase, or a function call involving a prototype.
The following is an example of truncation:
int a = 0x12345678;
short b = a;
When a is assigned to b the top 16 bits of the value are truncated, and h has a value of 0x5678.
This lost in precision could potentially lead into security failures. The following is an example:
void assume_privs(unsigned short uid) {
seteuid(uid);
setuid(uid);
}
int become_user(int uid) {
if (uid == 0)
die("root isn't allowed\n");
assume_privs(uid);
}
if attackers could pass arbitrary uid parameter to the become_user function, they could pass the uid of 0x10000 (65536), which after truncation to an unsigned short, the uid would have the value of 0, and attackers could gain root privileges.
The following is another example:
unsigned short len;
char mybuf[1024];
char *userstr = getuserstr();
len = strlen(userstr);
if (len > sizeof(mybuf) - 5)
die("string too long!");
strcpy(mybuf, userstr);
In the previous example, if the result of the previous strlen call would return 0x10000, the variable len after integer truncation will hold the value of 0, bypassing the len check, but cause a buffer overflow on the strcpy call.
here is a last example:
1char custom_strcmp(const char *str1, const char *str2) {
2 unsigned int *ptr1 = (unsigned int*)str1;
3 unsigned int *ptr2 = (unsigned int*)str2;
4 unsigned int i = 0;
5
6 size_t len1 = strlen(str1);
7 size_t len2 = strlen(str2);
8
9 if (len1 != len2 || strlen(len1) != 10)
10 return -1;
11
12 for (i = 0; i < len1 / 4; i++) {
13 if (ptr1[i] != ptr2[i])
14 return ptr1[i] - ptr2[i];
15 }
16
17 i *= 4;
18
19 for (i; i < len1; i++) {
20 if (str1[i] != str2[i])
21 return str1[i] - str2[i]
22 }
23
24 return 0;
25
26}
27
28void main(int argc, char **argv) {
29 if (argc != 2)
30 return;
31
32 if (!custom_strcmp(SECRET, argv[1])) {
33 puts("Success");
34 } else {
35 puts("Failure");
36 }
37
38 return;
39}
In the previous snippet, we can observe the implementation of a custom strcmp function. This function is used against the first supplied console argument to the program, and its compared against a custom secret string. Both the user supplied input and the secret string are 10 characters long.
The custom strcmp function is splitted into two different for loops. An initial one that is meant to compare pairs of integers from the secret string and the user supplied input. The second for loop goes over the last index that was divisible by four in the user supplied input (8), and it will iterate for 2 more iterations until it reaches the size of 10.
If one takes a close look at the function prototype of custom_strcmp, we can observe that its meant to return a char type. However we can observe that at line 11, its returning an unsigned int, that then later is truncated to a byte. This means that the original intent of that initial top for-loop was to compare 4 bytes of the input string against the secret string at a time. However due to integer truncation, only the last significant byte will be evaluated. Therefore this condition makes this function bruteforcable, as due to this integer truncation we can brute-force the first byte of the password until the "Success" string gets printed.
More Integer Vulnerability Examples #
CVE-2019-14196 #
1// Globals
2static char filefh[NFS3_FHSIZE]; /* NFSv2 / NFSv3 file handle */
3static int filefh3_length; /* (variable) length of filefh when NFSv3 */
4
5////ACID: pkt
6static int nfs_lookup_reply(uchar *pkt, unsigned len)
7{
8 struct rpc_t rpc_pkt;
9
10 debug("%s\n", __func__);
11
12 memcpy(&rpc_pkt.u.data[0], pkt, len);
13
14// ...
15
16 if (supported_nfs_versions & NFSV2_FLAG) {
17 memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
18 } else { /* NFSV3_FLAG */
19 filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
20 if (filefh3_length > NFS3_FHSIZE)
21 filefh3_length = NFS3_FHSIZE;
22 memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length);
23 }
24
25 return 0;
26}
This is a classic wrong integer size check or also known as “signed size insanity check” due to confussion of signess.
The global variable filefh3_length is of type int, therefore it can hold negative values. At line 19, filefh3_length is initialized by the result of ntohl against rpc_pkt.u.reply.data[1] which is ACID.
If the value returned turns out to be negative, the check at line 20 won’t hold, and on line 22 filefh3_length will be implicitly converted from an int to a size_t for the third parameter of memcpy, making the memcpy size field a very large unsigned integer therefore leading to a buffer overflow on filefh, as it of size NFS3_FHSIZE.
CVE-2021-33909 #
////NOTE: Start reading the code at seq_read_iter()
/**
* seq_has_overflowed - check if the buffer has overflowed
* @m: the seq_file handle
*
* seq_files have a buffer which may overflow. When this happens a larger
* buffer is reallocated and all the data will be printed again.
* The overflow state is true when m->count == m->size.
*
* Returns true if the buffer received more than it can hold.
*/
static inline bool seq_has_overflowed(struct seq_file *m)
{
return m->count == m->size;
}
//------------------------------------------------------------------------
135 static int show_mountinfo(struct seq_file *m, struct vfsmount *mnt) //KC: called by "m->op->show(m, p)"
136 {
...
150 seq_dentry(m, mnt->mnt_root, " \t\n\\");
//------------------------------------------------------------------------
523 int seq_dentry(struct seq_file *m, struct dentry *dentry, const char *esc)
524 {
525 char *buf;
526 size_t size = seq_get_buf(m, &buf);
...
529 if (size) {
530 char *p = dentry_path(dentry, buf, size);
//------------------------------------------------------------------------
380 char *dentry_path(struct dentry *dentry, char *buf, int buflen)
381 {
382 char *p = NULL;
...
385 if (d_unlinked(dentry)) { //KC: assume true
386 p = buf + buflen;
387 if (prepend(&p, &buflen, "//deleted", 10) != 0)
//------------------------------------------------------------------------
11 static int prepend(char **buffer, int *buflen, const char *str, int namelen)
12 {
13 *buflen -= namelen;
14 if (*buflen < 0)
15 return -ENAMETOOLONG;
16 *buffer -= namelen;
17 memcpy(*buffer, str, namelen);
//------------------------------------------------------------------------
////ACID: Assume the attacker can control the underlying seq_file to cause the while(1) loop to occur as many times as they want
168 ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
169 {
170 struct seq_file *m = iocb->ki_filp->private_data;
...
205 /* grab buffer if we didn't have one */
206 if (!m->buf) { //KC: assume this is NULL on the first iteration
207 m->buf = seq_buf_alloc(m->size = PAGE_SIZE); //KC: m->size is a size_t
...
210 }
...
220 // get a non-empty record in the buffer
...
223 while (1) {
...
227 err = m->op->show(m, p); //KC: This calls to show_mountinfo()
...
236 if (!seq_has_overflowed(m)) // got it
237 goto Fill;
238 // need a bigger buffer
...
240 kvfree(m->buf);
...
242 m->buf = seq_buf_alloc(m->size <<= 1);
...
246 }
An attacker can gain control over the variable seq_file at line 170 in seq_read_iter, it then allocates a page size for m->buf, and then it iterates indefinitely on the while loop at line 223.
At this point we see that m->op->show(m, p) gets invoked, which results in show_mountinfo() being invoked. We can see that show_mountinfo() invokes seq_dentry() with our controlled seq_file, m.
In seq_dentry() at line 256, we can se that is fetching the m->buf via seq_get_buf(), and the return value will be the buffer’s size size stored as a size_t. If size is not 0, dentry_path() will be invoked passing our m->buf and its size as the second and third parameters buf and size respectively.
We can immediately note by dentry_path() prototype, that the third parameter buflen is of type int. This means that with respect to the original type of size passed to dentry_path() as a size_t, by the time execution-flow reaches dentry_path, size will be truncated to a 32-bit integer from a 64bit size_t, but also interpreted as a signed integer.
On line 386 we can see how the variable p is initlized as the buf base being a (char *) plus buflen, which if its a negative integer value (say 0x80000000 (-2147483648)), this would result in faulty pointer arithmetic, calculating a pointer that will point before the start of the buffer buf. This later becomes an issue following the data flow through prepend(), as the value of buffer (our former buf corrupted pointer from dentry_path()) is substracted the value of 10, to then later conduct a memcpy to it.
This example highlights that integer type conversions should be closely examined across function boundaries, as if these are not done properly can cause issues as the one showed in this example.
Stack Linear Buffer Overflows
Stack linear buffer overflows occur when an application writes data into a fixed-size buffer on the stack without proper boundary checks, potentially corrupting adjacent memory. These overflows can lead to crashes, information disclosure, or even remote code execution (RCE) in critical scenarios.
These bugs often manifest in cases where sequential writes occur without validating the buffer’s boundaries. The problem is further exacerbated in functions that process user-controlled input or dynamically constructed data.
Root Causes
#
Some of the most common root causes of stack-based buffer overflows include:
- Unbounded String Operations: Using functions such as strcpy(), sprintf(), or strcat() or equivalent wrapper functions from the latter
without bounds checking.
- ACID Loop-Counters or Loop-Exit Conditions: When loop iteration or loop exit conditions depend on ACID parameters, such as an attacker-controlled buffer length.
- Missing Buffer Size Validation: Functions that use memcpy() or sscanf() or equivalent wrapper functions from the latter without verifying the destination buffer size.
- Fixed-Size Stack Buffers: When a local stack buffer is assumed to be large enough but is overrun due to larger-than-expected input.
Examples
#
The idea behind these examples is that without much context one can develop an intuition on how these bugs look like by looking at real-life examples
CVE-2018-9312
#
1int __cdecl Calc_CompressFileInf_8110171() {
2 char *v0; // ebx@1
3 char *v1; // eax@1
4 char *v2; // ST1C_4@2
5 int v3; // edx@2
6 int v4; // ecx@2
7 char **v5; // eax@8
8 char *v6; // ecx@17
9 int result; // eax@1
10
11 Metadata *metadata; // [esp+18h] [ebp-66Ch]@1
12 char fileName[1024]; // [esp+24h] [ebp-660h]@2
13 char log[512]; // [esp+42h] [ebp-260h]@2
14 char fileStat[96]; // [esp+62h] [ebp-60h]@2
15
16 v0 = (char *)1;
17 slog("[UPD] Calc_CompressFileInf: Start\n");
18 dword_AE70798 = g_file_num_idx;
19 v1 = dword_AE7121C;
20 g_file_num_idx = -1;
21 dword_AE7121C = (char *)-1;
22 dword_AE712F4 = v1;
23 memset(&dword_AE712C8, 0, 0x1u);
24 *(_QWORD *)&qword_AE712E0 = 0LL;
25 qword_AE71320 = 0LL;
26 metadata = gMetadataList; // ACID
27
28 while ((signed int)v0 <= g_manage_file_num_of_files) {
29 memset(fileName, 0, 1024);
30 sprintf(fileName, "%s/%s", gBasePath, metadata->decompressedFileName);
31 sprintf(log, "[UPD] Calc_CompressFileInf: Filename = %s\n", fileName);
32 slog(log);
33 }
34}
If metadata->decompressedFileName is larger than fileName (1024 bytes) the call to sprintf at line 30 will cause an stack buffer overflow. And by extension the consecutive sprintf call at line 31 too, as fileName will be larger than log (512 bytes)
CVE-2021-20294
#
1////ACID: filedata, symtab, section, strtab, strtab_size
2static void
3print_dynamic_symbol (Filedata *filedata, unsigned long si,
4 Elf_Internal_Sym *symtab,
5 Elf_Internal_Shdr *section,
6 char *strtab, size_t strtab_size)
7{
8 const char *version_string;
9 enum versioned_symbol_info sym_info;
10 unsigned short vna_other;
11 Elf_Internal_Sym *psym = symtab + si;
12
13 printf ("%6ld: ", si);
14 print_vma (psym->st_value, LONG_HEX);
15 putchar (' ');
16 print_vma (psym->st_size, DEC_5);
17 printf (" %-7s", get_symbol_type (filedata, ELF_ST_TYPE (psym->st_info)));
18 printf (" %-6s", get_symbol_binding (filedata, ELF_ST_BIND (psym->st_info)));
19 if (filedata->file_header.e_ident[EI_OSABI] == ELFOSABI_SOLARIS)
20 printf (" %-7s", get_solaris_symbol_visibility (psym->st_other));
21 else
22 {
23 unsigned int vis = ELF_ST_VISIBILITY (psym->st_other);
24
25 printf (" %-7s", get_symbol_visibility (vis));
26 /* Check to see if any other bits in the st_other field are set.
27 Note - displaying this information disrupts the layout of the
28 table being generated, but for the moment this case is very rare. */
29 if (psym->st_other ^ vis)
30 printf (" [%s] ", get_symbol_other (filedata, psym->st_other ^ vis));
31 }
32 printf (" %4s ", get_symbol_index_type (filedata, psym->st_shndx));
33
34 bfd_boolean is_valid = VALID_SYMBOL_NAME (strtab, strtab_size,
35 psym->st_name);
36 const char * sstr = is_valid ? strtab + psym->st_name : _("");
37
38 version_string
39 = get_symbol_version_string (filedata,
40 (section == NULL
41 || section->sh_type == SHT_DYNSYM),
42 strtab, strtab_size, si,
43 psym, &sym_info, &vna_other); //XENO: Lots of ACID in will yield ACID out
44
45 int len_avail = 21;
46 if (! do_wide && version_string != NULL) //XENO: do_wide is true iff -W option passed
47 {
48 char buffer[256];
49
50 len_avail -= sprintf (buffer, "@%s", version_string);
51
52 if (sym_info == symbol_undefined)
53 len_avail -= sprintf (buffer," (%d)", vna_other);
54 else if (sym_info != symbol_hidden)
55 len_avail -= 1;
56 }
57
58 print_symbol (len_avail, sstr);
59// ...
60}
If version_string is larger than buffer (256 bytes) the call to sprintf at line 50 will cause an stack buffer overflow.
CVE-2021-43579
#
1////ACID: everything read from fp
2static int /* O - 0 = success, -1 = fail */
3image_load_bmp(image_t *img, /* I - Image to load into */
4 FILE *fp, /* I - File to read from */
5 int gray, /* I - Grayscale image? */
6 int load_data)/* I - 1 = load image data, 0 = just info */
7{
8 int info_size, /* Size of info header */
9 depth, /* Depth of image (bits) */
10 compression, /* Type of compression */
11 colors_used, /* Number of colors used */
12 x, y, /* Looping vars */
13 color, /* Color of RLE pixel */
14 count, /* Number of times to repeat */
15 temp, /* Temporary color */
16 align; /* Alignment bytes */
17 uchar bit, /* Bit in image */
18 byte; /* Byte in image */
19 uchar *ptr; /* Pointer into pixels */
20 uchar colormap[256][4];/* Colormap */
21
22
23 // Get the header...
24 getc(fp); /* Skip "BM" sync chars */
25 getc(fp);
26 read_dword(fp); /* Skip size */
27 read_word(fp); /* Skip reserved stuff */
28 read_word(fp);
29 read_dword(fp);
30
31 // Then the bitmap information...
32 info_size = (int)read_dword(fp);
33 img->width = read_long(fp);
34 img->height = read_long(fp);
35 read_word(fp);
36 depth = read_word(fp);
37 compression = (int)read_dword(fp);
38 read_dword(fp);
39 read_long(fp);
40 read_long(fp);
41 colors_used = (int)read_dword(fp);
42 read_dword(fp);
43
44 if (img->width <= 0 || img->width > 8192 || img->height <= 0 || img->height > 8192)
45 return (-1);
46
47 if (info_size > 40)
48 for (info_size -= 40; info_size > 0; info_size --)
49 getc(fp);
50
51 // Get colormap...
52 if (colors_used == 0 && depth <= 8)
53 colors_used = 1 << depth;
54
55 fread(colormap, (size_t)colors_used, 4, fp);
56
57 /* Skipped remaining code until the end of the function*/
The variable colormap is a statically-sized mutli-dimension array of [256][4] taking 256 * 4 bytes of space in the stack. colors_used is read from the ACID file, and is later used in the fread() call at line 55, which will write ACID file contents to colormap as the destination. If colors_used is bigger than 256 * 4, a stack-buffer-overflow will occur.
CVE-2021-?????
#
1
2char ** find_tag_end(char **result) {
3 char *i;
4 unsigned int v2;
5 unsigned int cur_char;
6 for (i = *result ; ; ++i) {
7 cur_char = (unsigned __int8)*i;
8 if (cur_char <= 0xD && ((1 << cur_char) & 0x2601) != 0) // \0 \t \n \r
9 break;
10 v2 = cur_char - 32;
11 if (v2 <= 0x1F && ((1 << v2) & (unsigned int)&unk_C0008001) != 0) // space / > ?
12 break;
13 }
14 *result = i;
15 return result;
16}
17
18int IMSPL_XmlGetNextTagName(char *src, char *dst){
19 char * ptr = src;
20 // The cut code will:
21 // 1. Skip space characters
22 // 2. Find the beginning mark '<'
23 // 3. Skip comments
24 // ...
25 char * v8 = ptr + 1;
26 char ** v13;
27 v13[0] = v8;
28 find_tag_end((char **)v13);
29 v9 = v13[0];
30 if (v8 != v13[0]) {
31 memcpy(dst, (int *) ((char *)ptr + 1), v13[0] - v8);
32 dst[v9 - v8] = 0;
33 V12 = 10601;
34 // IMSPL_XmiGetNextTagName: Tag name
35 v11 = &log_struct_437f227c;
36 Logs((int *)&v11, (int)dst, -1, -20071784);
37 * (unsigned __int8 **)src = v13[0];
38 LOBYTE(result) = 1;
39 return (unsigned __int8) result;
40 }
41 // ...
42}
43
44// a1: ACID
45int IMSPL_XmlParser_ContactLstDecode(int *a1, int *a2) {
46 unsigned __int8 *v4;
47 int v5;
48 log_info_s *v7;
49 int v8;
50 unsigned __int8 *v9;
51 int v10;
52 char v11[136];
53
54 bzero(v11, 100);
55 v10 = 0;
56 v4 = (unsigned __int8 *)*a1;
57 v8 = 10597;
58 v9 = v4;
59 // ----------%s----------
60 v7 = &log_struct_4380937c;
61 log_0x418ffa6c(&v7, "IMSPL_XmlParser_ContactLstDecode", -20071784) ;
62 if (IMSPL_XmlGetNextTagName((char *)&v9, v11) ! = 1) {
63 LABEL_8:
64 *a1 = (int)v9;
65 v8 = 10597;
66 // Function END
67 v7 = &log_struct_43809448;
68 log_0x418ffa6c(&v7, -20071784) ;
69 return 1;
70 }
71// ...
72}
We can observe that on line 52, v11 is statically-sized, occupying 136 bytes in the stack. This variable is then passed to IMSPL_XmlGetNextTagName() as the second parameter, along with the address of v9 which is ACID. We can observe that in IMSPL_XmlGetNextTagName() the function find_tag_end() will be invoked to obtain the tag name end stored in v13 taking as first parameter an ACID pointer, entailing we would be able to control the value written into v13.
If the resulting value saved in v13 is not equal to v8 that being the pointer pointing to the beginning of the tag, then the a memcpy will take place, with the following expression as the size argument: v13[0] - v8. If the result of that expression is larger than 135 bytes, the original length of the buffer dedicated to store the tag contents, then a stack-buffer-overflow will occur.
CVE-2022-0435
#
1/* struct tipc_peer: state of a peer node and its domain
2 * @addr: tipc node identity of peer
3 * @head_map: shows which other nodes currently consider peer 'up'
4 * @domain: most recent domain record from peer
5 * @hash: position in hashed lookup list
6 * @list: position in linked list, in circular ascending order by 'addr'
7 * @applied: number of reported domain members applied on this monitor list
8 * @is_up: peer is up as seen from this node
9 * @is_head: peer is assigned domain head as seen from this node
10 * @is_local: peer is in local domain and should be continuously monitored
11 * @down_cnt: - numbers of other peers which have reported this on lost
12 */
13struct tipc_peer {
14 u32 addr;
15 struct tipc_mon_domain *domain;
16 struct hlist_node hash;
17 struct list_head list;
18 u8 applied;
19 u8 down_cnt;
20 bool is_up;
21 bool is_head;
22 bool is_local;
23};
24
25/* struct tipc_mon_domain: domain record to be transferred between peers
26 * @len: actual size of domain record
27 * @gen: current generation of sender's domain
28 * @ack_gen: most recent generation of self's domain acked by peer
29 * @member_cnt: number of domain member nodes described in this record
30 * @up_map: bit map indicating which of the members the sender considers up
31 * @members: identity of the domain members
32 */
33struct tipc_mon_domain {
34 u16 len;
35 u16 gen;
36 u16 ack_gen;
37 u16 member_cnt;
38 u64 up_map;
39 u32 members[MAX_MON_DOMAIN];
40};
41
42#define MAX_MON_DOMAIN 64
43
44static int dom_rec_len(struct tipc_mon_domain *dom, u16 mcnt)
45{
46 return ((void *)&dom->members - (void *)dom) + (mcnt * sizeof(u32));
47}
48
49/* tipc_mon_rcv - process monitor domain event message
50 */
51// ACID: *data, dlen
52void tipc_mon_rcv(struct net *net, void *data, u16 dlen, u32 addr,
53 struct tipc_mon_state *state, int bearer_id)
54{
55 struct tipc_monitor *mon = tipc_monitor(net, bearer_id);
56 struct tipc_mon_domain *arrv_dom = data;
57 struct tipc_mon_domain dom_bef;
58 struct tipc_mon_domain *dom;
59 struct tipc_peer *peer;
60 u16 new_member_cnt = ntohs(arrv_dom->member_cnt);
61 int new_dlen = dom_rec_len(arrv_dom, new_member_cnt);
62 u16 new_gen = ntohs(arrv_dom->gen);
63 u16 acked_gen = ntohs(arrv_dom->ack_gen);
64 bool probing = state->probing;
65 int i, applied_bef;
66
67 state->probing = false;
68
69 /* Sanity check received domain record */
70 if (dlen < dom_rec_len(arrv_dom, 0))
71 return;
72 if (dlen != dom_rec_len(arrv_dom, new_member_cnt))
73 return;
74 if ((dlen < new_dlen) || ntohs(arrv_dom->len) != new_dlen)
75 return;
76
77 /* Synch generation numbers with peer if link just came up */
78 if (!state->synched) {
79 state->peer_gen = new_gen - 1;
80 state->acked_gen = acked_gen;
81 state->synched = true;
82 }
83
84 if (more(acked_gen, state->acked_gen))
85 state->acked_gen = acked_gen;
86
87 /* Drop duplicate unless we are waiting for a probe response */
88 if (!more(new_gen, state->peer_gen) && !probing)
89 return;
90
91 write_lock_bh(&mon->lock);
92 peer = get_peer(mon, addr);
93 if (!peer || !peer->is_up)
94 goto exit;
95
96 /* Peer is confirmed, stop any ongoing probing */
97 peer->down_cnt = 0;
98
99 /* Task is done for duplicate record */
100 if (!more(new_gen, state->peer_gen))
101 goto exit;
102
103 state->peer_gen = new_gen;
104
105 /* Cache current domain record for later use */
106 dom_bef.member_cnt = 0;
107 dom = peer->domain;
108 if (dom)
109 memcpy(&dom_bef, dom, dom->len);
110
111 /* Transform and store received domain record */
112 if (!dom || (dom->len < new_dlen)) {
113 kfree(dom);
114 dom = kmalloc(new_dlen, GFP_ATOMIC);
115 peer->domain = dom;
116 if (!dom)
117 goto exit;
118 }
119 dom->len = new_dlen;
120 dom->gen = new_gen;
121 dom->member_cnt = new_member_cnt;
122 dom->up_map = be64_to_cpu(arrv_dom->up_map);
123 for (i = 0; i < new_member_cnt; i++)
124 dom->members[i] = ntohl(arrv_dom->members[i]);
125
126 /* Update peers affected by this domain record */
127 applied_bef = peer->applied;
128 mon_apply_domain(mon, peer);
129 mon_identify_lost_members(peer, &dom_bef, applied_bef);
130 mon_assign_roles(mon, peer_head(peer));
131exit:
132 write_unlock_bh(&mon->lock);
133}
We can observe that tipc_mon_domain structure contains a members field of an array of unsigned integers of MAX_MON_DOMAIN elements (64). In addition there’s another type tipc_peer with a pointer to a tipc_mon_domain called domain.
Ultimately if we trace the ACID data flow, we can immediately understand that new_member_cnt, an unsigned short type is ACID as its fetched from ntohs(arrv_dom->member_cnt) and arrv_dom is ACID as it points to data. All the sanity checks from line 70-75 can ultimately be bypassed as dlen, arrv_dom and new_dlen are all ACID. We can see following down the function that a tipc_peer object is fetched at line 92, to then later fetch a tipc_mon_domain field from the previous peer object at line 107.
Finally we can observe that at line 123 there’s a for loop with ACID ecit condition, as it iterates over new_member_cnt which is ACID. For each iteration, it will initialize dom->members[i] with ntohl(arrv_dom->members[i]) which is ACID. If new_member_cnt is lrger than MAX_MON_DOMAIN, then on this for loop, a stack-buffer-overflow will occur.
#
Stack Linear Buffer Overflows
Stack linear buffer overflows occur when an application writes data into a fixed-size buffer on the stack without proper boundary checks, potentially corrupting adjacent memory. These overflows can lead to crashes, information disclosure, or even remote code execution (RCE) in critical scenarios.
These bugs often manifest in cases where sequential writes occur without validating the buffer’s boundaries. The problem is further exacerbated in functions that process user-controlled input or dynamically constructed data.
Root Causes #
Some of the most common root causes of stack-based buffer overflows include:
- Unbounded String Operations: Using functions such as strcpy(), sprintf(), or strcat() or equivalent wrapper functions from the latter without bounds checking.
- ACID Loop-Counters or Loop-Exit Conditions: When loop iteration or loop exit conditions depend on ACID parameters, such as an attacker-controlled buffer length.
- Missing Buffer Size Validation: Functions that use memcpy() or sscanf() or equivalent wrapper functions from the latter without verifying the destination buffer size.
- Fixed-Size Stack Buffers: When a local stack buffer is assumed to be large enough but is overrun due to larger-than-expected input.
Examples #
The idea behind these examples is that without much context one can develop an intuition on how these bugs look like by looking at real-life examples
CVE-2018-9312 #
1int __cdecl Calc_CompressFileInf_8110171() {
2 char *v0; // ebx@1
3 char *v1; // eax@1
4 char *v2; // ST1C_4@2
5 int v3; // edx@2
6 int v4; // ecx@2
7 char **v5; // eax@8
8 char *v6; // ecx@17
9 int result; // eax@1
10
11 Metadata *metadata; // [esp+18h] [ebp-66Ch]@1
12 char fileName[1024]; // [esp+24h] [ebp-660h]@2
13 char log[512]; // [esp+42h] [ebp-260h]@2
14 char fileStat[96]; // [esp+62h] [ebp-60h]@2
15
16 v0 = (char *)1;
17 slog("[UPD] Calc_CompressFileInf: Start\n");
18 dword_AE70798 = g_file_num_idx;
19 v1 = dword_AE7121C;
20 g_file_num_idx = -1;
21 dword_AE7121C = (char *)-1;
22 dword_AE712F4 = v1;
23 memset(&dword_AE712C8, 0, 0x1u);
24 *(_QWORD *)&qword_AE712E0 = 0LL;
25 qword_AE71320 = 0LL;
26 metadata = gMetadataList; // ACID
27
28 while ((signed int)v0 <= g_manage_file_num_of_files) {
29 memset(fileName, 0, 1024);
30 sprintf(fileName, "%s/%s", gBasePath, metadata->decompressedFileName);
31 sprintf(log, "[UPD] Calc_CompressFileInf: Filename = %s\n", fileName);
32 slog(log);
33 }
34}
If metadata->decompressedFileName is larger than fileName (1024 bytes) the call to sprintf at line 30 will cause an stack buffer overflow. And by extension the consecutive sprintf call at line 31 too, as fileName will be larger than log (512 bytes)
CVE-2021-20294 #
1////ACID: filedata, symtab, section, strtab, strtab_size
2static void
3print_dynamic_symbol (Filedata *filedata, unsigned long si,
4 Elf_Internal_Sym *symtab,
5 Elf_Internal_Shdr *section,
6 char *strtab, size_t strtab_size)
7{
8 const char *version_string;
9 enum versioned_symbol_info sym_info;
10 unsigned short vna_other;
11 Elf_Internal_Sym *psym = symtab + si;
12
13 printf ("%6ld: ", si);
14 print_vma (psym->st_value, LONG_HEX);
15 putchar (' ');
16 print_vma (psym->st_size, DEC_5);
17 printf (" %-7s", get_symbol_type (filedata, ELF_ST_TYPE (psym->st_info)));
18 printf (" %-6s", get_symbol_binding (filedata, ELF_ST_BIND (psym->st_info)));
19 if (filedata->file_header.e_ident[EI_OSABI] == ELFOSABI_SOLARIS)
20 printf (" %-7s", get_solaris_symbol_visibility (psym->st_other));
21 else
22 {
23 unsigned int vis = ELF_ST_VISIBILITY (psym->st_other);
24
25 printf (" %-7s", get_symbol_visibility (vis));
26 /* Check to see if any other bits in the st_other field are set.
27 Note - displaying this information disrupts the layout of the
28 table being generated, but for the moment this case is very rare. */
29 if (psym->st_other ^ vis)
30 printf (" [%s] ", get_symbol_other (filedata, psym->st_other ^ vis));
31 }
32 printf (" %4s ", get_symbol_index_type (filedata, psym->st_shndx));
33
34 bfd_boolean is_valid = VALID_SYMBOL_NAME (strtab, strtab_size,
35 psym->st_name);
36 const char * sstr = is_valid ? strtab + psym->st_name : _("");
37
38 version_string
39 = get_symbol_version_string (filedata,
40 (section == NULL
41 || section->sh_type == SHT_DYNSYM),
42 strtab, strtab_size, si,
43 psym, &sym_info, &vna_other); //XENO: Lots of ACID in will yield ACID out
44
45 int len_avail = 21;
46 if (! do_wide && version_string != NULL) //XENO: do_wide is true iff -W option passed
47 {
48 char buffer[256];
49
50 len_avail -= sprintf (buffer, "@%s", version_string);
51
52 if (sym_info == symbol_undefined)
53 len_avail -= sprintf (buffer," (%d)", vna_other);
54 else if (sym_info != symbol_hidden)
55 len_avail -= 1;
56 }
57
58 print_symbol (len_avail, sstr);
59// ...
60}
If version_string is larger than buffer (256 bytes) the call to sprintf at line 50 will cause an stack buffer overflow.
CVE-2021-43579 #
1////ACID: everything read from fp
2static int /* O - 0 = success, -1 = fail */
3image_load_bmp(image_t *img, /* I - Image to load into */
4 FILE *fp, /* I - File to read from */
5 int gray, /* I - Grayscale image? */
6 int load_data)/* I - 1 = load image data, 0 = just info */
7{
8 int info_size, /* Size of info header */
9 depth, /* Depth of image (bits) */
10 compression, /* Type of compression */
11 colors_used, /* Number of colors used */
12 x, y, /* Looping vars */
13 color, /* Color of RLE pixel */
14 count, /* Number of times to repeat */
15 temp, /* Temporary color */
16 align; /* Alignment bytes */
17 uchar bit, /* Bit in image */
18 byte; /* Byte in image */
19 uchar *ptr; /* Pointer into pixels */
20 uchar colormap[256][4];/* Colormap */
21
22
23 // Get the header...
24 getc(fp); /* Skip "BM" sync chars */
25 getc(fp);
26 read_dword(fp); /* Skip size */
27 read_word(fp); /* Skip reserved stuff */
28 read_word(fp);
29 read_dword(fp);
30
31 // Then the bitmap information...
32 info_size = (int)read_dword(fp);
33 img->width = read_long(fp);
34 img->height = read_long(fp);
35 read_word(fp);
36 depth = read_word(fp);
37 compression = (int)read_dword(fp);
38 read_dword(fp);
39 read_long(fp);
40 read_long(fp);
41 colors_used = (int)read_dword(fp);
42 read_dword(fp);
43
44 if (img->width <= 0 || img->width > 8192 || img->height <= 0 || img->height > 8192)
45 return (-1);
46
47 if (info_size > 40)
48 for (info_size -= 40; info_size > 0; info_size --)
49 getc(fp);
50
51 // Get colormap...
52 if (colors_used == 0 && depth <= 8)
53 colors_used = 1 << depth;
54
55 fread(colormap, (size_t)colors_used, 4, fp);
56
57 /* Skipped remaining code until the end of the function*/
The variable colormap is a statically-sized mutli-dimension array of [256][4] taking 256 * 4 bytes of space in the stack. colors_used is read from the ACID file, and is later used in the fread() call at line 55, which will write ACID file contents to colormap as the destination. If colors_used is bigger than 256 * 4, a stack-buffer-overflow will occur.
CVE-2021-????? #
1
2char ** find_tag_end(char **result) {
3 char *i;
4 unsigned int v2;
5 unsigned int cur_char;
6 for (i = *result ; ; ++i) {
7 cur_char = (unsigned __int8)*i;
8 if (cur_char <= 0xD && ((1 << cur_char) & 0x2601) != 0) // \0 \t \n \r
9 break;
10 v2 = cur_char - 32;
11 if (v2 <= 0x1F && ((1 << v2) & (unsigned int)&unk_C0008001) != 0) // space / > ?
12 break;
13 }
14 *result = i;
15 return result;
16}
17
18int IMSPL_XmlGetNextTagName(char *src, char *dst){
19 char * ptr = src;
20 // The cut code will:
21 // 1. Skip space characters
22 // 2. Find the beginning mark '<'
23 // 3. Skip comments
24 // ...
25 char * v8 = ptr + 1;
26 char ** v13;
27 v13[0] = v8;
28 find_tag_end((char **)v13);
29 v9 = v13[0];
30 if (v8 != v13[0]) {
31 memcpy(dst, (int *) ((char *)ptr + 1), v13[0] - v8);
32 dst[v9 - v8] = 0;
33 V12 = 10601;
34 // IMSPL_XmiGetNextTagName: Tag name
35 v11 = &log_struct_437f227c;
36 Logs((int *)&v11, (int)dst, -1, -20071784);
37 * (unsigned __int8 **)src = v13[0];
38 LOBYTE(result) = 1;
39 return (unsigned __int8) result;
40 }
41 // ...
42}
43
44// a1: ACID
45int IMSPL_XmlParser_ContactLstDecode(int *a1, int *a2) {
46 unsigned __int8 *v4;
47 int v5;
48 log_info_s *v7;
49 int v8;
50 unsigned __int8 *v9;
51 int v10;
52 char v11[136];
53
54 bzero(v11, 100);
55 v10 = 0;
56 v4 = (unsigned __int8 *)*a1;
57 v8 = 10597;
58 v9 = v4;
59 // ----------%s----------
60 v7 = &log_struct_4380937c;
61 log_0x418ffa6c(&v7, "IMSPL_XmlParser_ContactLstDecode", -20071784) ;
62 if (IMSPL_XmlGetNextTagName((char *)&v9, v11) ! = 1) {
63 LABEL_8:
64 *a1 = (int)v9;
65 v8 = 10597;
66 // Function END
67 v7 = &log_struct_43809448;
68 log_0x418ffa6c(&v7, -20071784) ;
69 return 1;
70 }
71// ...
72}
We can observe that on line 52, v11 is statically-sized, occupying 136 bytes in the stack. This variable is then passed to IMSPL_XmlGetNextTagName() as the second parameter, along with the address of v9 which is ACID. We can observe that in IMSPL_XmlGetNextTagName() the function find_tag_end() will be invoked to obtain the tag name end stored in v13 taking as first parameter an ACID pointer, entailing we would be able to control the value written into v13.
If the resulting value saved in v13 is not equal to v8 that being the pointer pointing to the beginning of the tag, then the a memcpy will take place, with the following expression as the size argument: v13[0] - v8. If the result of that expression is larger than 135 bytes, the original length of the buffer dedicated to store the tag contents, then a stack-buffer-overflow will occur.
CVE-2022-0435 #
1/* struct tipc_peer: state of a peer node and its domain
2 * @addr: tipc node identity of peer
3 * @head_map: shows which other nodes currently consider peer 'up'
4 * @domain: most recent domain record from peer
5 * @hash: position in hashed lookup list
6 * @list: position in linked list, in circular ascending order by 'addr'
7 * @applied: number of reported domain members applied on this monitor list
8 * @is_up: peer is up as seen from this node
9 * @is_head: peer is assigned domain head as seen from this node
10 * @is_local: peer is in local domain and should be continuously monitored
11 * @down_cnt: - numbers of other peers which have reported this on lost
12 */
13struct tipc_peer {
14 u32 addr;
15 struct tipc_mon_domain *domain;
16 struct hlist_node hash;
17 struct list_head list;
18 u8 applied;
19 u8 down_cnt;
20 bool is_up;
21 bool is_head;
22 bool is_local;
23};
24
25/* struct tipc_mon_domain: domain record to be transferred between peers
26 * @len: actual size of domain record
27 * @gen: current generation of sender's domain
28 * @ack_gen: most recent generation of self's domain acked by peer
29 * @member_cnt: number of domain member nodes described in this record
30 * @up_map: bit map indicating which of the members the sender considers up
31 * @members: identity of the domain members
32 */
33struct tipc_mon_domain {
34 u16 len;
35 u16 gen;
36 u16 ack_gen;
37 u16 member_cnt;
38 u64 up_map;
39 u32 members[MAX_MON_DOMAIN];
40};
41
42#define MAX_MON_DOMAIN 64
43
44static int dom_rec_len(struct tipc_mon_domain *dom, u16 mcnt)
45{
46 return ((void *)&dom->members - (void *)dom) + (mcnt * sizeof(u32));
47}
48
49/* tipc_mon_rcv - process monitor domain event message
50 */
51// ACID: *data, dlen
52void tipc_mon_rcv(struct net *net, void *data, u16 dlen, u32 addr,
53 struct tipc_mon_state *state, int bearer_id)
54{
55 struct tipc_monitor *mon = tipc_monitor(net, bearer_id);
56 struct tipc_mon_domain *arrv_dom = data;
57 struct tipc_mon_domain dom_bef;
58 struct tipc_mon_domain *dom;
59 struct tipc_peer *peer;
60 u16 new_member_cnt = ntohs(arrv_dom->member_cnt);
61 int new_dlen = dom_rec_len(arrv_dom, new_member_cnt);
62 u16 new_gen = ntohs(arrv_dom->gen);
63 u16 acked_gen = ntohs(arrv_dom->ack_gen);
64 bool probing = state->probing;
65 int i, applied_bef;
66
67 state->probing = false;
68
69 /* Sanity check received domain record */
70 if (dlen < dom_rec_len(arrv_dom, 0))
71 return;
72 if (dlen != dom_rec_len(arrv_dom, new_member_cnt))
73 return;
74 if ((dlen < new_dlen) || ntohs(arrv_dom->len) != new_dlen)
75 return;
76
77 /* Synch generation numbers with peer if link just came up */
78 if (!state->synched) {
79 state->peer_gen = new_gen - 1;
80 state->acked_gen = acked_gen;
81 state->synched = true;
82 }
83
84 if (more(acked_gen, state->acked_gen))
85 state->acked_gen = acked_gen;
86
87 /* Drop duplicate unless we are waiting for a probe response */
88 if (!more(new_gen, state->peer_gen) && !probing)
89 return;
90
91 write_lock_bh(&mon->lock);
92 peer = get_peer(mon, addr);
93 if (!peer || !peer->is_up)
94 goto exit;
95
96 /* Peer is confirmed, stop any ongoing probing */
97 peer->down_cnt = 0;
98
99 /* Task is done for duplicate record */
100 if (!more(new_gen, state->peer_gen))
101 goto exit;
102
103 state->peer_gen = new_gen;
104
105 /* Cache current domain record for later use */
106 dom_bef.member_cnt = 0;
107 dom = peer->domain;
108 if (dom)
109 memcpy(&dom_bef, dom, dom->len);
110
111 /* Transform and store received domain record */
112 if (!dom || (dom->len < new_dlen)) {
113 kfree(dom);
114 dom = kmalloc(new_dlen, GFP_ATOMIC);
115 peer->domain = dom;
116 if (!dom)
117 goto exit;
118 }
119 dom->len = new_dlen;
120 dom->gen = new_gen;
121 dom->member_cnt = new_member_cnt;
122 dom->up_map = be64_to_cpu(arrv_dom->up_map);
123 for (i = 0; i < new_member_cnt; i++)
124 dom->members[i] = ntohl(arrv_dom->members[i]);
125
126 /* Update peers affected by this domain record */
127 applied_bef = peer->applied;
128 mon_apply_domain(mon, peer);
129 mon_identify_lost_members(peer, &dom_bef, applied_bef);
130 mon_assign_roles(mon, peer_head(peer));
131exit:
132 write_unlock_bh(&mon->lock);
133}
We can observe that tipc_mon_domain structure contains a members field of an array of unsigned integers of MAX_MON_DOMAIN elements (64). In addition there’s another type tipc_peer with a pointer to a tipc_mon_domain called domain.
Ultimately if we trace the ACID data flow, we can immediately understand that new_member_cnt, an unsigned short type is ACID as its fetched from ntohs(arrv_dom->member_cnt) and arrv_dom is ACID as it points to data. All the sanity checks from line 70-75 can ultimately be bypassed as dlen, arrv_dom and new_dlen are all ACID. We can see following down the function that a tipc_peer object is fetched at line 92, to then later fetch a tipc_mon_domain field from the previous peer object at line 107.
Finally we can observe that at line 123 there’s a for loop with ACID ecit condition, as it iterates over new_member_cnt which is ACID. For each iteration, it will initialize dom->members[i] with ntohl(arrv_dom->members[i]) which is ACID. If new_member_cnt is lrger than MAX_MON_DOMAIN, then on this for loop, a stack-buffer-overflow will occur.
Heap Linear Buffer Overflows
Heap linear buffer overflows occur when an application writes data into a fixed-size buffer on the heap without proper boundary checks, potentially corrupting adjacent memory.
Similarly to Stack linear buffer overflows, these bugs often manifest in cases where sequential writes occur without validating the buffer’s boundaries. The problem is further exacerbated in functions that process user-controlled input or dynamically constructed data.
Root Causes
#
Some of the most common root causes of stack-based buffer overflows include:
- Unbounded String Operations: Using functions such as strcpy(), sprintf(), or strcat() or equivalent wrapper functions from the latter without bounds checking.
- ACID Loop-Counters or Loop-Exit Conditions: When loop iteration or loop exit conditions depend on ACID parameters, such as an attacker-controlled buffer length.
- Missing Buffer Size Validation: Functions that use memcpy() or sscanf() or equivalent wrapper functions from the latter without verifying the destination buffer size.
- Fixed-Size Heap Buffers: When a local stack buffer is assumed to be large enough but is overrun due to larger-than-expected input.
- Wrongly assumed sized when copying memory across Heap Buffers: In cases in which memory gets copied from one buffer to another in the heap, bound checks are not properly implemented and often times sizes of source and destination buffer differ.
Examples
#
CVE-2020-0917
#
1
2// XENO: This struct is not officially documented
3// XENO: But this is what people have reverse engineered
4struct _MDL {
5 struct _MDL *Next;
6 CSHORT Size;
7 CSHORT MdlFlags;
8 struct _EPROCESS *Process;
9 PVOID MappedSystemVa;
10 PVOID StartVa;
11 ULONG ByteCount;
12 ULONG ByteOffset;
13} MDL, *PMDL;
14// XENO: Struct is followed by a variable-length array
15// XENO: Of physical-address (frame) pointers
16
17#define MmInitializeMdl (_MemoryDescriptorList,
18 _BaseVa,
19 _Length
20)
21{ \
22 (_MemoryDescriptorList)->Next = (PMDL) NULL; \
23 (_MemoryDescriptorList)->Size = (CSHORT) (sizeof(MDL) + \
24 (sizeof(PFN_NUMBER) * ADDRESS_AND_SIZE_TO_SPAN_PAGES(_BaseVa, _Length))); \
25 (_MemoryDescriptorList)->MdlFlags = 0; \
26 (_MemoryDescriptorList)->StartVa = (PVOID) PAGE_ALIGN(_BaseVa); \
27 (_MemoryDescriptorList)->ByteOffset = BYTE_OFFSET(_BaseVa); \
28 (_MemoryDescriptorList)->ByteCount = (ULONG) _Length; \
29}
30
31PMDL TransferMdl;
32NTSTATUS Status;
33PMDL UndoMdl;
34
35// Obtain a mapping to the undo MDL.
36
37Status = SkmmMapDataTransfer(DataMdl, //XENO: DataMdl ACID in
38 TransferPfn,
39 SkmmMapRead,
40 &TransferMdl, //XENO: TransferMdl ACID out
41 NULL);
42
43if(!NT_SUCCESS(Status)) {
44 return Status;
45}
46
47UndoMdl = SkAllocatePool(NonPagedPoolNx, TransferMdl->ByteCount, 'ldmM');
48
49if(UndoMdl == NULL){
50 goto CleanupAndExit;
51}
52
53OriginalUndoMdl = TransferMdl->MappedSystemVa; //XENO: Attacker controls data at address, not address itself
54MmInitializeMdl(UndoMdl, (PVOID)OriginalUndoMdl->ByteOffset, OriginalUndoMdl->ByteCount);
Variable destination length, aswell as source length, and data used in memory copy operation its fetched from ACID memory
CVE-2020-11901
#
1
2
3tt16Bit tfDnsExpLabelLength(tt8BitPtr labelPtr, tt8BitPtr pktDataPtr, tt8BitPtr labelEndPtr){
4 tt8Bit currLabelLength;
5 tt16Bit i = 0, totalLength = 0;
6 tt8BitPtr newLabelPtr;
7
8 while (&labelPtr[i] < labelEndPtr && labelPtr[i] != 0) {
9 currLabelLength = labelPtr[i];
10 if ((currLabelLength & 0xc0) == 0) {
11 totalLength += currLabelLength + 1;
12 i += currLabelLength + 1;
13 } else {
14 if (&labelPtr[i+1] < labelEndPtr) {
15 newLabelPtr = pktDataPtr + (((currLabelLength & 0x3f) << 8) | labelPtr[i+1]);
16 if (newLabelPtr < labelPtr) {
17 labelPtr = newLabelPtr;
18 i = 0;
19 continue;
20 }
21 }
22 return 0;
23 }
24 }
25 return totalLength;
26}
27
28//ACID: RDLENGTH, resourceRecordAfterNamePtr, dnsHeaderPtr
29if (RDLENGTH <= remaining_size) {
30 /* compute the next resource record pointer based on the RDLENGTH */
31 labelEndPtr = resourceRecordAfterNamePtr + 10 + RDLENGTH;
32 /* type: MX */
33 if (cacheEntryQueryType == DNS_TYPE_MX && rrtype == DNS_TYPE_MX) {
34 addr_info = tfDnsAllocAddrInfo();
35 if (addr_info != NULL && RDLENGTH >= 2) {
36 /* copy preference value of MX record */
37 memcpy(&addr_info->ai_mxpref,resourceRecordAfterNamePtr + 10, 2);
38 /* compute the length of the MX hostname */
39 labelLength = tfDnsExpLabelLength(resourceRecordAfterNamePtr + 0xc, dnsHeaderPtr, labelEndPtr);
40 addr_info->ai_mxhostname = NULL;
41 if (labelLength != 0) {
42 /* allocate buffer for the expanded name */
43 asciiPtr = tfGetRawBuffer((uint)labelLength);
44 addr_info->ai_mxhostname = asciiPtr;
45 if (asciiPtr != NULL) {
46 /* copy MX hostname to `asciiPtr` as ASCII */
47 tfDnsLabelToAscii(resourceRecordAfterNamePtr + 0xc, asciiPtr, dnsHeaderPtr, 1, 0);
48 /* ... */
49 }
50 /* ... */
51 }
52 /* ... */
53 }
54 /* ... */
55 }
56}
resourceRecordAfterNamePtr is ACID, and its length is not checked against asciiPtr length before memory copy. In addition, asciiPtr length is derived from labelLength, which is ACID.
CVE-2020-25111
#
1////ACID: cp
2static uint16_t ScanName(uint8_t * cp, uint8_t ** npp){
3 uint8_t len;
4 uint16_t rc;
5 uint8_t *np;
6
7 if(*npp){
8 free(*npp);
9 *npp = 0;
10 }
11
12 if((*cp & 0xC0) == 0xC0)
13 return 2;
14
15 rc = strlen((char *) cp) + 1;
16 np = *npp = malloc(rc);
17 len = *cp++;
18 while(len){
19 while (len--)
20 *np++ = *cp++;
21 if((len = *cp++) != 0)
22 *np++ = '.';
23 }
24 *np = 0;
25
26 return rc;
27}
buffer length is calculated differently when buffer is allocated than when data is being copied to the buffer. Lengths are assumed to be the same
CVE-2020-27009
#
1//// No src was given for GET16() but we will assume it behaves as below:
2#define GET16(base, offset) *(unsigned short *)((void *)(base) + offset)
3
4////ACID: pkt
5STATUS DNS_Extract_Data (DNS_PKT_HEADER *pkt, CHAR *data, UNSIGNED *ttl, INT type){
6 DNS_RR *pr_ptr;
7 INT name_size, n_answers, rcode;
8 UINT16 length;
9 CHAR *p_ptr, *name;
10
11 n_answers = GET16(pkt, DNS_ANCOUNT_OFFSET);
12 // [...]
13 /* If there is at least one reasonable answer and this is a response, process it */
14 if ((n_answers > 0) && (GET16(pkt, DNS_FLAGS_OFFSET) & DNS_QR)) {
15 /* Point to where the question starts.*/
16 p_ptr = (CHAR *)(pkt + 1);
17 /* Allocate a block of memory to put the name in */
18 if (NU_Allocate_Memory (&System_Memory, (VOID **)&name,
19 DNS_MAX_NAME_SIZE,
20 NU_NO_SUSPEND) != NU_SUCCESS) {
21 return (NU_NO_MEMORY);
22 }
23
24 /* Extract the name. */
25 name_size = DNS_Unpack_Domain_Name (name, p_ptr, (CHAR *)pkt);
26
27 /* Move the pointer past the name QTYPE and QCLASS to point at the
28 answer section of the response. */
29 p_ptr += name_size + 4;
30
31 /* At this point, there may be several answers. We will take the first
32 answer section of the response. */
33 while ((n_answers--) > 0){
34 /* Extract the name from the answer. */
35 name_size = DNS_Unpack_Domain_Name (name, p_ptr, (CHAR *)pkt);
36 /* Move the pointer past the name. */
37 p_ptr += name_size;
38 /* Point to the resource record. */
39 rr_ptr = (DNS_RR *)p_ptr;
40 // [...]
41 /* Copy the length of this answer. */
42 length = GET16(rr_ptr, DNS_RDLENGTH_OFFSET);
43 // [...]
44 }
45 // [...]
46 }
47 // [...]
48}
49
50////ACID: src, buf_begin
51INT DNS_Unpack_Domain_Name(CHAR * dst, CHAR *src, CHAR *buf_begin) {
52 INT16 size;
53 INT i, retval = 0;
54 CHAR *savesrc;
55
56 savesrc = src;
57
58 while (*src){
59 size = *src;
60
61 while ((size & 0xC0) == 0xC0){
62 if (!retval)
63 {
64 retval = src - savesrc + 2;
65 }
66 src++;
67 src = &buf_begin[(size & 0x3f) * 256 + *src];
68 size = *src;
69 }
70 src++;
71
72 for (i=0; i < (size & 0x3f); i++){
73 *dst++ = *src++;
74 }
75 *dst++ = '.';
76 }
77
78 *(--dst) = 0;
79 src++;
80
81 if (!retval) {
82 retval = src - savesrc;
83 }
84
85 return (retval);
86}
Manual memory copy loop-exit condition and outer-loop-exit condition are all ACID
#
Heap Linear Buffer Overflows
Heap linear buffer overflows occur when an application writes data into a fixed-size buffer on the heap without proper boundary checks, potentially corrupting adjacent memory.
Similarly to Stack linear buffer overflows, these bugs often manifest in cases where sequential writes occur without validating the buffer’s boundaries. The problem is further exacerbated in functions that process user-controlled input or dynamically constructed data.
Root Causes #
Some of the most common root causes of stack-based buffer overflows include:
- Unbounded String Operations: Using functions such as strcpy(), sprintf(), or strcat() or equivalent wrapper functions from the latter without bounds checking.
- ACID Loop-Counters or Loop-Exit Conditions: When loop iteration or loop exit conditions depend on ACID parameters, such as an attacker-controlled buffer length.
- Missing Buffer Size Validation: Functions that use memcpy() or sscanf() or equivalent wrapper functions from the latter without verifying the destination buffer size.
- Fixed-Size Heap Buffers: When a local stack buffer is assumed to be large enough but is overrun due to larger-than-expected input.
- Wrongly assumed sized when copying memory across Heap Buffers: In cases in which memory gets copied from one buffer to another in the heap, bound checks are not properly implemented and often times sizes of source and destination buffer differ.
Examples #
CVE-2020-0917 #
1
2// XENO: This struct is not officially documented
3// XENO: But this is what people have reverse engineered
4struct _MDL {
5 struct _MDL *Next;
6 CSHORT Size;
7 CSHORT MdlFlags;
8 struct _EPROCESS *Process;
9 PVOID MappedSystemVa;
10 PVOID StartVa;
11 ULONG ByteCount;
12 ULONG ByteOffset;
13} MDL, *PMDL;
14// XENO: Struct is followed by a variable-length array
15// XENO: Of physical-address (frame) pointers
16
17#define MmInitializeMdl (_MemoryDescriptorList,
18 _BaseVa,
19 _Length
20)
21{ \
22 (_MemoryDescriptorList)->Next = (PMDL) NULL; \
23 (_MemoryDescriptorList)->Size = (CSHORT) (sizeof(MDL) + \
24 (sizeof(PFN_NUMBER) * ADDRESS_AND_SIZE_TO_SPAN_PAGES(_BaseVa, _Length))); \
25 (_MemoryDescriptorList)->MdlFlags = 0; \
26 (_MemoryDescriptorList)->StartVa = (PVOID) PAGE_ALIGN(_BaseVa); \
27 (_MemoryDescriptorList)->ByteOffset = BYTE_OFFSET(_BaseVa); \
28 (_MemoryDescriptorList)->ByteCount = (ULONG) _Length; \
29}
30
31PMDL TransferMdl;
32NTSTATUS Status;
33PMDL UndoMdl;
34
35// Obtain a mapping to the undo MDL.
36
37Status = SkmmMapDataTransfer(DataMdl, //XENO: DataMdl ACID in
38 TransferPfn,
39 SkmmMapRead,
40 &TransferMdl, //XENO: TransferMdl ACID out
41 NULL);
42
43if(!NT_SUCCESS(Status)) {
44 return Status;
45}
46
47UndoMdl = SkAllocatePool(NonPagedPoolNx, TransferMdl->ByteCount, 'ldmM');
48
49if(UndoMdl == NULL){
50 goto CleanupAndExit;
51}
52
53OriginalUndoMdl = TransferMdl->MappedSystemVa; //XENO: Attacker controls data at address, not address itself
54MmInitializeMdl(UndoMdl, (PVOID)OriginalUndoMdl->ByteOffset, OriginalUndoMdl->ByteCount);
Variable destination length, aswell as source length, and data used in memory copy operation its fetched from ACID memory
CVE-2020-11901 #
1
2
3tt16Bit tfDnsExpLabelLength(tt8BitPtr labelPtr, tt8BitPtr pktDataPtr, tt8BitPtr labelEndPtr){
4 tt8Bit currLabelLength;
5 tt16Bit i = 0, totalLength = 0;
6 tt8BitPtr newLabelPtr;
7
8 while (&labelPtr[i] < labelEndPtr && labelPtr[i] != 0) {
9 currLabelLength = labelPtr[i];
10 if ((currLabelLength & 0xc0) == 0) {
11 totalLength += currLabelLength + 1;
12 i += currLabelLength + 1;
13 } else {
14 if (&labelPtr[i+1] < labelEndPtr) {
15 newLabelPtr = pktDataPtr + (((currLabelLength & 0x3f) << 8) | labelPtr[i+1]);
16 if (newLabelPtr < labelPtr) {
17 labelPtr = newLabelPtr;
18 i = 0;
19 continue;
20 }
21 }
22 return 0;
23 }
24 }
25 return totalLength;
26}
27
28//ACID: RDLENGTH, resourceRecordAfterNamePtr, dnsHeaderPtr
29if (RDLENGTH <= remaining_size) {
30 /* compute the next resource record pointer based on the RDLENGTH */
31 labelEndPtr = resourceRecordAfterNamePtr + 10 + RDLENGTH;
32 /* type: MX */
33 if (cacheEntryQueryType == DNS_TYPE_MX && rrtype == DNS_TYPE_MX) {
34 addr_info = tfDnsAllocAddrInfo();
35 if (addr_info != NULL && RDLENGTH >= 2) {
36 /* copy preference value of MX record */
37 memcpy(&addr_info->ai_mxpref,resourceRecordAfterNamePtr + 10, 2);
38 /* compute the length of the MX hostname */
39 labelLength = tfDnsExpLabelLength(resourceRecordAfterNamePtr + 0xc, dnsHeaderPtr, labelEndPtr);
40 addr_info->ai_mxhostname = NULL;
41 if (labelLength != 0) {
42 /* allocate buffer for the expanded name */
43 asciiPtr = tfGetRawBuffer((uint)labelLength);
44 addr_info->ai_mxhostname = asciiPtr;
45 if (asciiPtr != NULL) {
46 /* copy MX hostname to `asciiPtr` as ASCII */
47 tfDnsLabelToAscii(resourceRecordAfterNamePtr + 0xc, asciiPtr, dnsHeaderPtr, 1, 0);
48 /* ... */
49 }
50 /* ... */
51 }
52 /* ... */
53 }
54 /* ... */
55 }
56}
resourceRecordAfterNamePtr is ACID, and its length is not checked against asciiPtr length before memory copy. In addition, asciiPtr length is derived from labelLength, which is ACID.
CVE-2020-25111 #
1////ACID: cp
2static uint16_t ScanName(uint8_t * cp, uint8_t ** npp){
3 uint8_t len;
4 uint16_t rc;
5 uint8_t *np;
6
7 if(*npp){
8 free(*npp);
9 *npp = 0;
10 }
11
12 if((*cp & 0xC0) == 0xC0)
13 return 2;
14
15 rc = strlen((char *) cp) + 1;
16 np = *npp = malloc(rc);
17 len = *cp++;
18 while(len){
19 while (len--)
20 *np++ = *cp++;
21 if((len = *cp++) != 0)
22 *np++ = '.';
23 }
24 *np = 0;
25
26 return rc;
27}
buffer length is calculated differently when buffer is allocated than when data is being copied to the buffer. Lengths are assumed to be the same
CVE-2020-27009 #
1//// No src was given for GET16() but we will assume it behaves as below:
2#define GET16(base, offset) *(unsigned short *)((void *)(base) + offset)
3
4////ACID: pkt
5STATUS DNS_Extract_Data (DNS_PKT_HEADER *pkt, CHAR *data, UNSIGNED *ttl, INT type){
6 DNS_RR *pr_ptr;
7 INT name_size, n_answers, rcode;
8 UINT16 length;
9 CHAR *p_ptr, *name;
10
11 n_answers = GET16(pkt, DNS_ANCOUNT_OFFSET);
12 // [...]
13 /* If there is at least one reasonable answer and this is a response, process it */
14 if ((n_answers > 0) && (GET16(pkt, DNS_FLAGS_OFFSET) & DNS_QR)) {
15 /* Point to where the question starts.*/
16 p_ptr = (CHAR *)(pkt + 1);
17 /* Allocate a block of memory to put the name in */
18 if (NU_Allocate_Memory (&System_Memory, (VOID **)&name,
19 DNS_MAX_NAME_SIZE,
20 NU_NO_SUSPEND) != NU_SUCCESS) {
21 return (NU_NO_MEMORY);
22 }
23
24 /* Extract the name. */
25 name_size = DNS_Unpack_Domain_Name (name, p_ptr, (CHAR *)pkt);
26
27 /* Move the pointer past the name QTYPE and QCLASS to point at the
28 answer section of the response. */
29 p_ptr += name_size + 4;
30
31 /* At this point, there may be several answers. We will take the first
32 answer section of the response. */
33 while ((n_answers--) > 0){
34 /* Extract the name from the answer. */
35 name_size = DNS_Unpack_Domain_Name (name, p_ptr, (CHAR *)pkt);
36 /* Move the pointer past the name. */
37 p_ptr += name_size;
38 /* Point to the resource record. */
39 rr_ptr = (DNS_RR *)p_ptr;
40 // [...]
41 /* Copy the length of this answer. */
42 length = GET16(rr_ptr, DNS_RDLENGTH_OFFSET);
43 // [...]
44 }
45 // [...]
46 }
47 // [...]
48}
49
50////ACID: src, buf_begin
51INT DNS_Unpack_Domain_Name(CHAR * dst, CHAR *src, CHAR *buf_begin) {
52 INT16 size;
53 INT i, retval = 0;
54 CHAR *savesrc;
55
56 savesrc = src;
57
58 while (*src){
59 size = *src;
60
61 while ((size & 0xC0) == 0xC0){
62 if (!retval)
63 {
64 retval = src - savesrc + 2;
65 }
66 src++;
67 src = &buf_begin[(size & 0x3f) * 256 + *src];
68 size = *src;
69 }
70 src++;
71
72 for (i=0; i < (size & 0x3f); i++){
73 *dst++ = *src++;
74 }
75 *dst++ = '.';
76 }
77
78 *(--dst) = 0;
79 src++;
80
81 if (!retval) {
82 retval = src - savesrc;
83 }
84
85 return (retval);
86}
Manual memory copy loop-exit condition and outer-loop-exit condition are all ACID
Non Linear Overflows (OOB)
The definition of OOB access primitives can be summerized as when Attacker Controlled Input Data (ACID) is used to calculate a memory location (that is out-of-bounds from the intended memory), and then ACID is written to that location, or data is read from that location.
This concept is equally applicable to memory originating from different regions in the process address space – Stack, Heap, … etc
Note: All linear buffer overflows are oob writes, but not all oob writes are linear buffer overflows.
Root Causes
#
- Everything that applies for linear buffer overflows
- Faulty Pointer Arithmetic:
- Using ACID for [array index] calculation
- base + offset and other pointer arithmetic calculations that allow for a skip forward/backwards that can land outside of the buffer bounds
Examples
#
CVE-2019-10540
#
1////ACID: g_font->numMasters
2int ParseBlendVToHOrigin(void *arg) {
3 Fixed16_16 *ptrs[2];
4 Fixed16_16 values[2];
5
6 for (int i = 0; i < g_font->numMasters; i++) { //KC: 0 <= g_font->numMasters <= 16
7 ptrs[i] = &g_font->SomeArray[arg->SomeField + i];
8 }
9
10 for (int i = 0; i < 2; i++) { //KC: values becomes ACID here
11 int values_read = GetOpenFixedArray(values, g_font->numMasters);
12 if (values_read != g_font->numMasters) {
13 return -8;
14 }
15
16 for (int num = 0; num < g_font->numMasters; num++) {
17 ptrs[num][i] = values[num];
18 }
19 }
20
21 return 0;
22}
Nested for loop assumes g_font->numMasters will always be within bounds, therefore is an ACID loop-exit condition
CVE-2020-13995
#
1//XENO: Globals
2char Gstr[255];
3char sBuffer[1000];
4//...
5/* V2_0, V2_1 */
6int number_of_DESs;
7segment_info_type *DES_info;
8//...
9long read_verify(int fh, char *destination, long length, char *sErrorMessage)
10{
11 long rc;
12 long start;
13 long file_len;
14 static char sTemp[150];
15
16 rc = read(fh, destination, length);
17 if (rc == -1) {
18 start = lseek(fh, 0, SEEK_CUR);
19 file_len = lseek(fh, 0, SEEK_END);
20 sprintf(sTemp, "Error reading, read returned %ld. (start = %ld, \
21read length = %ld, file_length = %ld\n%s\n",
22 rc, start, length, file_len, sErrorMessage);
23 errmessage(sTemp);
24 iQuit(1);
25 }
26 else if (rc != length) {
27 start = lseek(fh, 0, SEEK_CUR) - rc;
28 file_len = lseek(fh, 0, SEEK_END);
29 sprintf(sTemp, "Error reading, read returned %ld. (start = %ld, \
30read length = %ld, file_length = %ld\n%s\n",
31 rc, start, length, file_len, sErrorMessage);
32 errmessage(sTemp);
33 printf("errno=%d\n", errno);
34 iQuit(1);
35 }
36 return rc;
37}
38
39////ACID: hNITF
40int main(int argc, char *argv[]){
41 //...
42 rc = open(sNITFfilename, O_RDONLY| O_BINARY);
43 //...
44 hNITF = rc;
45 //...
46 read_verify(hNITF, (char *) sBuffer, 3,
47 "error reading header (# extension segs");
48 sBuffer[3] = '\0';
49 number_of_DESs = atoi(sBuffer);
50
51 if (number_of_DESs > 0) {
52 /* Allocate Space for extension segs information arrays */
53 DES_info = (segment_info_type *)
54 malloc(sizeof(segment_info_type) * number_of_DESs);
55 if (DES_info == NULL) {
56 errmessage("Error allocating memory for DES_info");
57 iQuit(1);
58 }
59
60 /* Read Image subheader / data lengths */
61
62 read_verify(hNITF, sBuffer, 13 * number_of_DESs,
63 "Error reading header / image subheader data lengths");
64
65 temp = sBuffer;
66
67 for (x = 0; x < number_of_DESs; x++) {
68 strncpy(Gstr, temp, 4);
69 Gstr[4] = '\0';
70 DES_info[x].length_of_subheader = atol(Gstr);
71 temp += 4;
72
73 strncpy(Gstr, temp, 9);
74 Gstr[9] = '\0';
75 DES_info[x].length_of_data = atol(Gstr);
76 temp += 9;
77
78 DES_info[x].pData = NULL;
79 DES_info[x].bFile_written = FALSE;
80 }
81 }
82}
The variable number_of_DESs is a signed integer, which gets implicitly converted into an unsigned integer by read. Therefore the check on line 51 can be bypassed, causing an underallocated DES_info if ACID number_of_DESs is negative, and causing a linear global overflow of sBuffer that would also overwrite *DES_info, which later is dereferenced to cause OOB data writes.
CVE-2021-26675
#
1 static char *uncompress(int16_t field_count, /*KC: ACID from packet header */
2 char *start, /*KC: Starting header of ACID input packet */
3 char *end, /*KC: End of ACID input packet */
4 char *ptr, /*KC: Current offset in ACID input packet */
5 char *uncompressed, /*KC: Base of [1025] output buffer */
6 int uncomp_len, /*KC: Hardcoded 1025 */
7 char **uncompressed_ptr)/*KC: Offset to end of uncompressed data */
8{
9 char *uptr = *uncompressed_ptr; /* position in result buffer */
10
11 debug("count %d ptr %p end %p uptr %p", field_count, ptr, end, uptr);
12
13 while (field_count-- > 0 && ptr < end) {
14 int dlen; /* data field length */
15 int ulen; /* uncompress length */
16 int pos; /* position in compressed string */
17 char name[NS_MAXLABEL]; /* tmp label */ /*KC: fixed-size 63 byte buffer*/
18 uint16_t dns_type, dns_class;
19 int comp_pos;
20
21 if (!convert_label(start, end, ptr, name, NS_MAXLABEL,
22 &pos, &comp_pos))
23 goto out;
24
25 /*
26 * Copy the uncompressed resource record, type, class and \0 to
27 * tmp buffer.
28 */
29 // SACI: ulen <= 62
30 ulen = strlen(name);
31 strncpy(uptr, name, uncomp_len - (uptr - uncompressed)); /*KC: 1025 - (current offset-base) */
32
33 debug("pos %d ulen %d left %d name %s", pos, ulen,
34 (int)(uncomp_len - (uptr - uncompressed)), uptr);
35
36 uptr += ulen;
37 *uptr++ = '\0';
38
39 ptr += pos;
40
41 /*
42 * We copy also the fixed portion of the result (type, class,
43 * ttl, address length and the address)
44 */
45 memcpy(uptr, ptr, NS_RRFIXEDSZ); /*KC: NS_RRFIXEDSZ = 10*/
46
47 dns_type = uptr[0] << 8 | uptr[1];
48 dns_class = uptr[2] << 8 | uptr[3];
49
50 if (dns_class != ns_c_in)
51 goto out;
52
53 ptr += NS_RRFIXEDSZ;
54 uptr += NS_RRFIXEDSZ;
The variable field_count is ACID. However even though field_count is attacker controlled, there is a loop exit-condition at line 21 which is SACI (attacker can control length of the packet, but can’t iterate through the loop infinitely).
On line 30 theres is an strlen call to fetch the length of the label record. This label can be at most 62 bytes as defined by the spec.
However an OOB write condition can manifest if we reach the very end of uptr such as uncomp_len - (uptr - uncompressed) evaluates to anything for X than 62.
This would mean that theres at most X bytes of extra space in uptr, however on like 36, uptr is added the length of the string for the name label (eg: 62), to then dereference it to write a null byte, and subsequently invoke a memcpy with fixed size, leading to an OOB write.
CVE-2021-28216
#
1////ACID: NV Var data returned in PerformanceVariable
2////NOT ACID: Variables named *Guid
3//
4// Update S3 boot records into the basic boot performance table.
5//
6VarSize = sizeof (PerformanceVariable);
7Status = VariableServices->GetVariable(VariableServices,
8 EFI_FIRMWARE_PERFORMANCE_VARIABLE_NAME,
9 &gEfiFirmwarePerformanceGuid,
10 NULL,
11 &VarSize,
12 &PerformanceVariable);
13if (EFI_ERROR (Status)) {
14 return Status;
15}
16BootPerformanceTable = (UINT8*) (UINTN)PerformanceVariable.BootPerformanceTablePointer;
17//
18// Dump PEI boot records
19//
20FirmwarePerformanceTablePtr = (BootPerformanceTable + sizeof(BOOT_PERFORMANCE_TABLE));
21
22GuidHob = GetFirstGuidHob(&gEdkiiFpdtExtendedFirmwarePerformanceGuid);
23
24while (GuidHob != NULL) {
25 FirmwarePerformanceData = GET_GUID_HOB_DATA(GuidHob);
26 PeiPerformanceLogHeader = (FPDT_PEI_EXT_PERF_HEADER *)FirmwarePerformanceData;
27 CopyMem(FirmwarePerformanceTablePtr,
28 FirmwarePerformanceData + sizeof (FPDT_PEI_EXT_PERF_HEADER),
29 (UINTN)(PeiPerformanceLogHeader->SizeOfAllEntries));
30
31 GuidHob = GetNextGuidHob(&gEdkiiFpdtExtendedFirmwarePerformanceGuid, GET_NEXT_HOB(GuidHob));
32 FirmwarePerformanceTablePtr += (UINTN)(PeiPerformanceLogHeader->SizeOfAllEntries);
33}
34//
35// Update Table length.
36//
37((BOOT_PERFORMANCE_TABLE *) BootPerformanceTable)->Header.Length =
38 (UINT32)((UINTN)FirmwarePerformanceTablePtr - (UINTN)BootPerformanceTable);
Anything coming from PerformanceVariable is ACID. On line 27, we can see a function invokation that resembles a mecmpy. Despite only controlling the destination and not the source or the length of the memory copy operation, an attacker could potentially predict what bytes are being copied.
CVE-2022-25636
#
1struct flow_action {
2 unsigned int num_entries;
3 struct flow_action_entry entries[];
4};
5
6struct flow_rule {
7 struct flow_match match;
8 struct flow_action action;
9};
10
11struct nft_flow_rule {
12 __be16 proto;
13 struct nft_flow_match match;
14 struct flow_rule *rule;
15};
16
17struct nft_offload_ctx {
18 struct {
19 enum nft_offload_dep_type type;
20 __be16 l3num;
21 u8 protonum;
22 } dep;
23 unsigned int num_actions;
24 struct net *net;
25 struct nft_offload_reg regs[NFT_REG32_15 + 1];
26};
27
28/**
29 * struct_size() - Calculate size of structure with trailing array.
30 * @p: Pointer to the structure.
31 * @member: Name of the array member.
32 * @count: Number of elements in the array.
33 *
34 * Calculates size of memory needed for structure @p followed by an
35 * array of @count number of @member elements.
36 *
37 * Return: number of bytes needed or SIZE_MAX on overflow.
38 */
39#define struct_size(p, member, count) \
40 __ab_c_size(count, \
41 sizeof(*(p)->member) + __must_be_array((p)->member),\
42 sizeof(*(p)))
43
44#define NFT_OFFLOAD_F_ACTION (1 << 0)
45
46struct flow_rule *flow_rule_alloc(unsigned int num_actions)
47{
48 struct flow_rule *rule;
49 int i;
50 // XENO: allocates space for the rule->action.entries[num_actions] array
51 rule = kzalloc(struct_size(rule, action.entries, num_actions),
52 GFP_KERNEL);
53 if (!rule)
54 return NULL;
55
56 rule->action.num_entries = num_actions;
57 /* Pre-fill each action hw_stats with DONT_CARE.
58 * Caller can override this if it wants stats for a given action.
59 */
60 for (i = 0; i < num_actions; i++)
61 rule->action.entries[i].hw_stats = FLOW_ACTION_HW_STATS_DONT_CARE;
62
63 return rule;
64}
65
66static struct nft_flow_rule *nft_flow_rule_alloc(int num_actions)
67{
68 struct nft_flow_rule *flow;
69
70 flow = kzalloc(sizeof(struct nft_flow_rule), GFP_KERNEL);
71 if (!flow)
72 return NULL;
73
74 flow->rule = flow_rule_alloc(num_actions);
75 if (!flow->rule) {
76 kfree(flow);
77 return NULL;
78 }
79
80 flow->rule->match.dissector = &flow->match.dissector;
81 flow->rule->match.mask = &flow->match.mask;
82 flow->rule->match.key = &flow->match.key;
83
84 return flow;
85}
86
87static inline struct nft_expr *nft_expr_first(const struct nft_rule *rule)
88{
89 return (struct nft_expr *)&rule->data[0];
90}
91
92static inline struct nft_expr *nft_expr_last(const struct nft_rule *rule)
93{
94 return (struct nft_expr *)&rule->data[rule->dlen];
95}
96
97static inline bool nft_expr_more(const struct nft_rule *rule,
98 const struct nft_expr *expr)
99{
100 return expr != nft_expr_last(rule) && expr->ops;
101}
102
103
104int nft_fwd_dup_netdev_offload(struct nft_offload_ctx *ctx,
105 struct nft_flow_rule *flow,
106 enum flow_action_id id, int oif)
107{
108 struct flow_action_entry *entry;
109 struct net_device *dev;
110
111 /* nft_flow_rule_destroy() releases the reference on this device. */
112 dev = dev_get_by_index(ctx->net, oif);
113 if (!dev)
114 return -EOPNOTSUPP;
115
116 entry = &flow->rule->action.entries[ctx->num_actions++];
117 entry->id = id;
118 entry->dev = dev;
119
120 return 0;
121}
122
123static inline void *nft_expr_priv(const struct nft_expr *expr)
124{
125 return (void *)expr->data;
126}
127
128static int nft_dup_netdev_offload(struct nft_offload_ctx *ctx,
129 struct nft_flow_rule *flow,
130 const struct nft_expr *expr)
131{
132 const struct nft_dup_netdev *priv = nft_expr_priv(expr); // XENO: assume priv != ACID
133 int oif = ctx->regs[priv->sreg_dev].data.data[0];
134
135 return nft_fwd_dup_netdev_offload(ctx, flow, FLOW_ACTION_MIRRED /*5*/, oif);
136}
137
138////ACID: rule
139struct nft_flow_rule *nft_flow_rule_create(struct net *net,
140 const struct nft_rule *rule)
141{
142 struct nft_offload_ctx *ctx;
143 struct nft_flow_rule *flow;
144 int num_actions = 0, err;
145 struct nft_expr *expr;
146
147 expr = nft_expr_first(rule);
148 while (nft_expr_more(rule, expr)) {
149 if (expr->ops->offload_flags & NFT_OFFLOAD_F_ACTION)
150 num_actions++;
151
152 expr = nft_expr_next(expr);
153 }
154
155 if (num_actions == 0)
156 return ERR_PTR(-EOPNOTSUPP);
157
158 flow = nft_flow_rule_alloc(num_actions);
159 if (!flow)
160 return ERR_PTR(-ENOMEM);
161
162 expr = nft_expr_first(rule);
163
164 ctx = kzalloc(sizeof(struct nft_offload_ctx), GFP_KERNEL);
165 if (!ctx) {
166 err = -ENOMEM;
167 goto err_out;
168 }
169 ctx->net = net;
170 ctx->dep.type = NFT_OFFLOAD_DEP_UNSPEC;
171
172 while (nft_expr_more(rule, expr)) {
173 if (!expr->ops->offload) {
174 err = -EOPNOTSUPP;
175 goto err_out;
176 }
177 err = expr->ops->offload(ctx, flow, expr); //XENO: Calls nft_dup_netdev_offload()
178 if (err < 0)
179 goto err_out;
180
181 expr = nft_expr_next(expr);
182 }
183 nft_flow_rule_transfer_vlan(ctx, flow);
184
185 flow->proto = ctx->dep.l3num;
186 kfree(ctx);
187
188 return flow;
189err_out:
190 kfree(ctx);
191 nft_flow_rule_destroy(flow);
192
193 return ERR_PTR(err);
194}
The variable num_actions is ACID and is determined if each expression in rule matches the following condition at nft_flow_rule_create at line 149: expr->ops->offload_flags & NFT_OFFLOAD_F_ACTION. This will ultimately determine how many flow_rule instances will be allocated by flow_rule_alloc at line 51.
However, at like 172 we can observe the expression within the ACID nft_rule are iterated again, and for all expressions which meet the expr->ops->offload condition, the nft_dup_netdev_offload function pointer will be invoked. This function will endup invoking nft_fwd_dup_netdev_offload, which will initialize a flow_action_entry at ctx-num_actions, and this counter will be increased everytime this function is invoked.
There is an incongruence between the number of flow_rule allocated instances, and the way these instances are later initialized by nft_fwd_dup_netdev_offload, leading to an OOB write when an OOB flow_action_entry is initialized at line 117, ann 118, since the code at nft_fwd_dup_netdev_offload assumes that a given flow_action_entries to be initialized are allocated.
#
Non Linear Overflows (OOB)
The definition of OOB access primitives can be summerized as when Attacker Controlled Input Data (ACID) is used to calculate a memory location (that is out-of-bounds from the intended memory), and then ACID is written to that location, or data is read from that location.
This concept is equally applicable to memory originating from different regions in the process address space – Stack, Heap, … etc
Note: All linear buffer overflows are oob writes, but not all oob writes are linear buffer overflows.
Root Causes #
- Everything that applies for linear buffer overflows
- Faulty Pointer Arithmetic:
- Using ACID for [array index] calculation
- base + offset and other pointer arithmetic calculations that allow for a skip forward/backwards that can land outside of the buffer bounds
Examples #
CVE-2019-10540 #
1////ACID: g_font->numMasters
2int ParseBlendVToHOrigin(void *arg) {
3 Fixed16_16 *ptrs[2];
4 Fixed16_16 values[2];
5
6 for (int i = 0; i < g_font->numMasters; i++) { //KC: 0 <= g_font->numMasters <= 16
7 ptrs[i] = &g_font->SomeArray[arg->SomeField + i];
8 }
9
10 for (int i = 0; i < 2; i++) { //KC: values becomes ACID here
11 int values_read = GetOpenFixedArray(values, g_font->numMasters);
12 if (values_read != g_font->numMasters) {
13 return -8;
14 }
15
16 for (int num = 0; num < g_font->numMasters; num++) {
17 ptrs[num][i] = values[num];
18 }
19 }
20
21 return 0;
22}
Nested for loop assumes g_font->numMasters will always be within bounds, therefore is an ACID loop-exit condition
CVE-2020-13995 #
1//XENO: Globals
2char Gstr[255];
3char sBuffer[1000];
4//...
5/* V2_0, V2_1 */
6int number_of_DESs;
7segment_info_type *DES_info;
8//...
9long read_verify(int fh, char *destination, long length, char *sErrorMessage)
10{
11 long rc;
12 long start;
13 long file_len;
14 static char sTemp[150];
15
16 rc = read(fh, destination, length);
17 if (rc == -1) {
18 start = lseek(fh, 0, SEEK_CUR);
19 file_len = lseek(fh, 0, SEEK_END);
20 sprintf(sTemp, "Error reading, read returned %ld. (start = %ld, \
21read length = %ld, file_length = %ld\n%s\n",
22 rc, start, length, file_len, sErrorMessage);
23 errmessage(sTemp);
24 iQuit(1);
25 }
26 else if (rc != length) {
27 start = lseek(fh, 0, SEEK_CUR) - rc;
28 file_len = lseek(fh, 0, SEEK_END);
29 sprintf(sTemp, "Error reading, read returned %ld. (start = %ld, \
30read length = %ld, file_length = %ld\n%s\n",
31 rc, start, length, file_len, sErrorMessage);
32 errmessage(sTemp);
33 printf("errno=%d\n", errno);
34 iQuit(1);
35 }
36 return rc;
37}
38
39////ACID: hNITF
40int main(int argc, char *argv[]){
41 //...
42 rc = open(sNITFfilename, O_RDONLY| O_BINARY);
43 //...
44 hNITF = rc;
45 //...
46 read_verify(hNITF, (char *) sBuffer, 3,
47 "error reading header (# extension segs");
48 sBuffer[3] = '\0';
49 number_of_DESs = atoi(sBuffer);
50
51 if (number_of_DESs > 0) {
52 /* Allocate Space for extension segs information arrays */
53 DES_info = (segment_info_type *)
54 malloc(sizeof(segment_info_type) * number_of_DESs);
55 if (DES_info == NULL) {
56 errmessage("Error allocating memory for DES_info");
57 iQuit(1);
58 }
59
60 /* Read Image subheader / data lengths */
61
62 read_verify(hNITF, sBuffer, 13 * number_of_DESs,
63 "Error reading header / image subheader data lengths");
64
65 temp = sBuffer;
66
67 for (x = 0; x < number_of_DESs; x++) {
68 strncpy(Gstr, temp, 4);
69 Gstr[4] = '\0';
70 DES_info[x].length_of_subheader = atol(Gstr);
71 temp += 4;
72
73 strncpy(Gstr, temp, 9);
74 Gstr[9] = '\0';
75 DES_info[x].length_of_data = atol(Gstr);
76 temp += 9;
77
78 DES_info[x].pData = NULL;
79 DES_info[x].bFile_written = FALSE;
80 }
81 }
82}
The variable number_of_DESs is a signed integer, which gets implicitly converted into an unsigned integer by read. Therefore the check on line 51 can be bypassed, causing an underallocated DES_info if ACID number_of_DESs is negative, and causing a linear global overflow of sBuffer that would also overwrite *DES_info, which later is dereferenced to cause OOB data writes.
CVE-2021-26675 #
1 static char *uncompress(int16_t field_count, /*KC: ACID from packet header */
2 char *start, /*KC: Starting header of ACID input packet */
3 char *end, /*KC: End of ACID input packet */
4 char *ptr, /*KC: Current offset in ACID input packet */
5 char *uncompressed, /*KC: Base of [1025] output buffer */
6 int uncomp_len, /*KC: Hardcoded 1025 */
7 char **uncompressed_ptr)/*KC: Offset to end of uncompressed data */
8{
9 char *uptr = *uncompressed_ptr; /* position in result buffer */
10
11 debug("count %d ptr %p end %p uptr %p", field_count, ptr, end, uptr);
12
13 while (field_count-- > 0 && ptr < end) {
14 int dlen; /* data field length */
15 int ulen; /* uncompress length */
16 int pos; /* position in compressed string */
17 char name[NS_MAXLABEL]; /* tmp label */ /*KC: fixed-size 63 byte buffer*/
18 uint16_t dns_type, dns_class;
19 int comp_pos;
20
21 if (!convert_label(start, end, ptr, name, NS_MAXLABEL,
22 &pos, &comp_pos))
23 goto out;
24
25 /*
26 * Copy the uncompressed resource record, type, class and \0 to
27 * tmp buffer.
28 */
29 // SACI: ulen <= 62
30 ulen = strlen(name);
31 strncpy(uptr, name, uncomp_len - (uptr - uncompressed)); /*KC: 1025 - (current offset-base) */
32
33 debug("pos %d ulen %d left %d name %s", pos, ulen,
34 (int)(uncomp_len - (uptr - uncompressed)), uptr);
35
36 uptr += ulen;
37 *uptr++ = '\0';
38
39 ptr += pos;
40
41 /*
42 * We copy also the fixed portion of the result (type, class,
43 * ttl, address length and the address)
44 */
45 memcpy(uptr, ptr, NS_RRFIXEDSZ); /*KC: NS_RRFIXEDSZ = 10*/
46
47 dns_type = uptr[0] << 8 | uptr[1];
48 dns_class = uptr[2] << 8 | uptr[3];
49
50 if (dns_class != ns_c_in)
51 goto out;
52
53 ptr += NS_RRFIXEDSZ;
54 uptr += NS_RRFIXEDSZ;
The variable field_count is ACID. However even though field_count is attacker controlled, there is a loop exit-condition at line 21 which is SACI (attacker can control length of the packet, but can’t iterate through the loop infinitely).
On line 30 theres is an strlen call to fetch the length of the label record. This label can be at most 62 bytes as defined by the spec.
However an OOB write condition can manifest if we reach the very end of uptr such as uncomp_len - (uptr - uncompressed) evaluates to anything for X than 62.
This would mean that theres at most X bytes of extra space in uptr, however on like 36, uptr is added the length of the string for the name label (eg: 62), to then dereference it to write a null byte, and subsequently invoke a memcpy with fixed size, leading to an OOB write.
CVE-2021-28216 #
1////ACID: NV Var data returned in PerformanceVariable
2////NOT ACID: Variables named *Guid
3//
4// Update S3 boot records into the basic boot performance table.
5//
6VarSize = sizeof (PerformanceVariable);
7Status = VariableServices->GetVariable(VariableServices,
8 EFI_FIRMWARE_PERFORMANCE_VARIABLE_NAME,
9 &gEfiFirmwarePerformanceGuid,
10 NULL,
11 &VarSize,
12 &PerformanceVariable);
13if (EFI_ERROR (Status)) {
14 return Status;
15}
16BootPerformanceTable = (UINT8*) (UINTN)PerformanceVariable.BootPerformanceTablePointer;
17//
18// Dump PEI boot records
19//
20FirmwarePerformanceTablePtr = (BootPerformanceTable + sizeof(BOOT_PERFORMANCE_TABLE));
21
22GuidHob = GetFirstGuidHob(&gEdkiiFpdtExtendedFirmwarePerformanceGuid);
23
24while (GuidHob != NULL) {
25 FirmwarePerformanceData = GET_GUID_HOB_DATA(GuidHob);
26 PeiPerformanceLogHeader = (FPDT_PEI_EXT_PERF_HEADER *)FirmwarePerformanceData;
27 CopyMem(FirmwarePerformanceTablePtr,
28 FirmwarePerformanceData + sizeof (FPDT_PEI_EXT_PERF_HEADER),
29 (UINTN)(PeiPerformanceLogHeader->SizeOfAllEntries));
30
31 GuidHob = GetNextGuidHob(&gEdkiiFpdtExtendedFirmwarePerformanceGuid, GET_NEXT_HOB(GuidHob));
32 FirmwarePerformanceTablePtr += (UINTN)(PeiPerformanceLogHeader->SizeOfAllEntries);
33}
34//
35// Update Table length.
36//
37((BOOT_PERFORMANCE_TABLE *) BootPerformanceTable)->Header.Length =
38 (UINT32)((UINTN)FirmwarePerformanceTablePtr - (UINTN)BootPerformanceTable);
Anything coming from PerformanceVariable is ACID. On line 27, we can see a function invokation that resembles a mecmpy. Despite only controlling the destination and not the source or the length of the memory copy operation, an attacker could potentially predict what bytes are being copied.
CVE-2022-25636 #
1struct flow_action {
2 unsigned int num_entries;
3 struct flow_action_entry entries[];
4};
5
6struct flow_rule {
7 struct flow_match match;
8 struct flow_action action;
9};
10
11struct nft_flow_rule {
12 __be16 proto;
13 struct nft_flow_match match;
14 struct flow_rule *rule;
15};
16
17struct nft_offload_ctx {
18 struct {
19 enum nft_offload_dep_type type;
20 __be16 l3num;
21 u8 protonum;
22 } dep;
23 unsigned int num_actions;
24 struct net *net;
25 struct nft_offload_reg regs[NFT_REG32_15 + 1];
26};
27
28/**
29 * struct_size() - Calculate size of structure with trailing array.
30 * @p: Pointer to the structure.
31 * @member: Name of the array member.
32 * @count: Number of elements in the array.
33 *
34 * Calculates size of memory needed for structure @p followed by an
35 * array of @count number of @member elements.
36 *
37 * Return: number of bytes needed or SIZE_MAX on overflow.
38 */
39#define struct_size(p, member, count) \
40 __ab_c_size(count, \
41 sizeof(*(p)->member) + __must_be_array((p)->member),\
42 sizeof(*(p)))
43
44#define NFT_OFFLOAD_F_ACTION (1 << 0)
45
46struct flow_rule *flow_rule_alloc(unsigned int num_actions)
47{
48 struct flow_rule *rule;
49 int i;
50 // XENO: allocates space for the rule->action.entries[num_actions] array
51 rule = kzalloc(struct_size(rule, action.entries, num_actions),
52 GFP_KERNEL);
53 if (!rule)
54 return NULL;
55
56 rule->action.num_entries = num_actions;
57 /* Pre-fill each action hw_stats with DONT_CARE.
58 * Caller can override this if it wants stats for a given action.
59 */
60 for (i = 0; i < num_actions; i++)
61 rule->action.entries[i].hw_stats = FLOW_ACTION_HW_STATS_DONT_CARE;
62
63 return rule;
64}
65
66static struct nft_flow_rule *nft_flow_rule_alloc(int num_actions)
67{
68 struct nft_flow_rule *flow;
69
70 flow = kzalloc(sizeof(struct nft_flow_rule), GFP_KERNEL);
71 if (!flow)
72 return NULL;
73
74 flow->rule = flow_rule_alloc(num_actions);
75 if (!flow->rule) {
76 kfree(flow);
77 return NULL;
78 }
79
80 flow->rule->match.dissector = &flow->match.dissector;
81 flow->rule->match.mask = &flow->match.mask;
82 flow->rule->match.key = &flow->match.key;
83
84 return flow;
85}
86
87static inline struct nft_expr *nft_expr_first(const struct nft_rule *rule)
88{
89 return (struct nft_expr *)&rule->data[0];
90}
91
92static inline struct nft_expr *nft_expr_last(const struct nft_rule *rule)
93{
94 return (struct nft_expr *)&rule->data[rule->dlen];
95}
96
97static inline bool nft_expr_more(const struct nft_rule *rule,
98 const struct nft_expr *expr)
99{
100 return expr != nft_expr_last(rule) && expr->ops;
101}
102
103
104int nft_fwd_dup_netdev_offload(struct nft_offload_ctx *ctx,
105 struct nft_flow_rule *flow,
106 enum flow_action_id id, int oif)
107{
108 struct flow_action_entry *entry;
109 struct net_device *dev;
110
111 /* nft_flow_rule_destroy() releases the reference on this device. */
112 dev = dev_get_by_index(ctx->net, oif);
113 if (!dev)
114 return -EOPNOTSUPP;
115
116 entry = &flow->rule->action.entries[ctx->num_actions++];
117 entry->id = id;
118 entry->dev = dev;
119
120 return 0;
121}
122
123static inline void *nft_expr_priv(const struct nft_expr *expr)
124{
125 return (void *)expr->data;
126}
127
128static int nft_dup_netdev_offload(struct nft_offload_ctx *ctx,
129 struct nft_flow_rule *flow,
130 const struct nft_expr *expr)
131{
132 const struct nft_dup_netdev *priv = nft_expr_priv(expr); // XENO: assume priv != ACID
133 int oif = ctx->regs[priv->sreg_dev].data.data[0];
134
135 return nft_fwd_dup_netdev_offload(ctx, flow, FLOW_ACTION_MIRRED /*5*/, oif);
136}
137
138////ACID: rule
139struct nft_flow_rule *nft_flow_rule_create(struct net *net,
140 const struct nft_rule *rule)
141{
142 struct nft_offload_ctx *ctx;
143 struct nft_flow_rule *flow;
144 int num_actions = 0, err;
145 struct nft_expr *expr;
146
147 expr = nft_expr_first(rule);
148 while (nft_expr_more(rule, expr)) {
149 if (expr->ops->offload_flags & NFT_OFFLOAD_F_ACTION)
150 num_actions++;
151
152 expr = nft_expr_next(expr);
153 }
154
155 if (num_actions == 0)
156 return ERR_PTR(-EOPNOTSUPP);
157
158 flow = nft_flow_rule_alloc(num_actions);
159 if (!flow)
160 return ERR_PTR(-ENOMEM);
161
162 expr = nft_expr_first(rule);
163
164 ctx = kzalloc(sizeof(struct nft_offload_ctx), GFP_KERNEL);
165 if (!ctx) {
166 err = -ENOMEM;
167 goto err_out;
168 }
169 ctx->net = net;
170 ctx->dep.type = NFT_OFFLOAD_DEP_UNSPEC;
171
172 while (nft_expr_more(rule, expr)) {
173 if (!expr->ops->offload) {
174 err = -EOPNOTSUPP;
175 goto err_out;
176 }
177 err = expr->ops->offload(ctx, flow, expr); //XENO: Calls nft_dup_netdev_offload()
178 if (err < 0)
179 goto err_out;
180
181 expr = nft_expr_next(expr);
182 }
183 nft_flow_rule_transfer_vlan(ctx, flow);
184
185 flow->proto = ctx->dep.l3num;
186 kfree(ctx);
187
188 return flow;
189err_out:
190 kfree(ctx);
191 nft_flow_rule_destroy(flow);
192
193 return ERR_PTR(err);
194}
The variable num_actions is ACID and is determined if each expression in rule matches the following condition at nft_flow_rule_create at line 149: expr->ops->offload_flags & NFT_OFFLOAD_F_ACTION. This will ultimately determine how many flow_rule instances will be allocated by flow_rule_alloc at line 51.
However, at like 172 we can observe the expression within the ACID nft_rule are iterated again, and for all expressions which meet the expr->ops->offload condition, the nft_dup_netdev_offload function pointer will be invoked. This function will endup invoking nft_fwd_dup_netdev_offload, which will initialize a flow_action_entry at ctx-num_actions, and this counter will be increased everytime this function is invoked.
There is an incongruence between the number of flow_rule allocated instances, and the way these instances are later initialized by nft_fwd_dup_netdev_offload, leading to an OOB write when an OOB flow_action_entry is initialized at line 117, ann 118, since the code at nft_fwd_dup_netdev_offload assumes that a given flow_action_entries to be initialized are allocated.
Integer Overflows/Underflows
Integer Overflows/Underflows are the product of signed and unsigned integers exceeding their positive and negative value ranges due to Attacker Control Input Data.
Integer Overflow Root Causes
#
- ACID Arithmetic expressions involving lack or faulty checks ensuring result of arithmetic operation does not overflow/underflow
- Confusion between signed and unsigned integers
- Implicit integer conversions – eg: Signed sizes later converted to unsigned
- ACID loop-counter or loop-exit conditions that lead to progressive increments/decrements to an integer type that will endup overflowing/underflowing.
Integer Overflow As Vulnerabilties
#
Most commonly (although not always), integer overflows/underflows tend to be leveraged as vulnerabilities following a common under-allocation, over-copy pattern.
Conceptually this pattern may look as follows:
First an integer overflow can succesfully be abused to cause some sort of under-allocation condition. Something such as
dest = alloc(ACID1 + const)dest = alloc(ACID1 + ACID2)dest = alloc(ACID1 * const)- … etc
Then a memory copy si done to that allocation. Assuming the length of the copy is not affected by the same integer overflow condition, it would result in an over-copy condition relative to the previous under-allocated buffer:
copy(dest, src, ACID1)
Examples
#
CVE-2020-0796
#
1////ACID: The data pointed to by request->pNetRawBuffer
2signed __int64 __fastcall Srv2DecompressData(SRV2_WORKITEM *workitem)
3{
4 // declarations omitted
5 ...
6 request = workitem->psbhRequest;
7 if ( request->dwMsgSize < 0x10 )
8 return 0xC000090B;
9 compressHeader = *(CompressionTransformHeader *)request->pNetRawBuffer;
10 ...
11
12 newHeader = SrvNetAllocateBuffer((unsigned int)(compressHeader.originalCompressedSegSize + compressHeader.offsetOrLength), 0);
13 if ( !newHeader )
14 return 0xC000009A;
15
16 if ( SmbCompressionDecompress(
17 compressHeader.compressionType,
18 &workitem->psbhRequest->pNetRawBuffer[compressHeader.offsetOrLength + 16],
19 workitem->psbhRequest->dwMsgSize - compressHeader.offsetOrLength - 16,
20 &newHeader->pNetRawBuffer[compressHeader.offsetOrLength],
21 compressHeader.OriginalCompressedSegSize,
22 &finalDecompressedSize) < 0
23 || finalDecompressedSize != compressHeader.originalCompressedSegSize) )
24 {
25 SrvNetFreeBuffer(newHeader);
26 return 0xC000090B;
27 }
28 if ( compressHeader.offsetOrLength )
29 {
30 memmove(newHeader->pNetRawBuffer, workitem->psbhRequest->pNetRawBuffer + 16, compressHeader.offsetOrLength);
31 }
32 newHeader->dwMsgSize = compressHeader.OffsetOrLength + fianlDecompressedSize;
33 Srv2ReplaceReceiveBuffer(workitem, newHeader);
34 return 0;
35}
The function SrvNetAllocateBuffer allocates the result of this expression: compressHeader.originalCompressedSegSize + compressHeader.offsetOrLength. Both operands of this arithmetic expression are ACID.
If we later look at line 30, we can see a memmove to this newly allocated memory with a controlled size of compressHeader.offsetOrLength. This means that if the expression compressHeader.originalCompressedSegSize + compressHeader.offsetOrLength succesfully overflows the range of an unsigned integer, resulting in a smaller computed value relative than compressHeader.offsetOrLength, a buffer overflow will occur due to an integer overflow.
CVE-2019-5105
#
1////ACID: param_1
2void FUN_00677d70(void **param_1, int param_2, int param_3, int param_4, int param_5 ,uint *param_6)
3{
4 int header_length;
5 size_t _Size;
6 int iVar1;
7 int iVar2;
8 int receiver_length;
9 uint sender_length;
10 /* Omitted code */
11 void *blkDrvPDUdata;
12 /* Omitted code */
13 iVar2 = *(int *)(param_2 + 0x128) + DAT_007a3534;
14 if (iVar2 < 0xf) {
15 /* Omitted code */
16 blkDrvPDUdata = *param_1;
17 header_length = (*(byte *)((int)blkDrvPDUdata + 1) & 7) * 2;
18 sender_length = *(byte *)((int)blkDrvPDUdata + 5) & 0xf;
19 receiver_length = (int)(uint)*(byte *)((int)blkDrvPDUdata + 5) >> 4;
20 pvVar3 = (void *)(sender_length + receiver_length + header_length);
21 local_20c = header_length;
22 if (pvVar3 < param_1[1] || pvVar3 == param_1[1]) {
23 pvVar3 = *param_1;
24 if ((*(byte *)((int)blkDrvPDUdata + 2) & 0x10) == 0) {
25 *param_6 = header_length + (sender_length + receiver_length) * 2;
26 if ((*param_6 & 3) != 0) {
27 *param_6 = *param_6 + 2;
28 }
29 _Size = (int)param_1[1] - *param_6;
30
31 /* Omitted code*/
32 if ((local_220 < 0x10) && (local_244 < 0x10)) {
33 /* Omitted Code*/
34 if (local_20c + _Size_00 + iVar1 + local_214 + _Size < 0x201) {
35 memcpy(local_208 + local_214 + iVar1 + _Size_00 + local_20c,
36 (void *)((int)*param_1 + *param_6), _Size );
37 param_1[1] = (void *)(local_20c + _Size_00 + iVar1 + local_214 + _Size);
38 memcpy(*param_1,local_208,(size_t)param_1[1]);
39 *(int *)(param_5 + 0xc) = (int)*param_1 + local_20c;
40 *(int *)(param_4 + 0xc) = *(int *)(param_5 + 0xc) + *(int *)(param_5 + 8) * 2;
41 *param_6 = local_20c + _Size_00 + iVar1;
42 if ((*param_6 & 3) != 0) {
43 *param_6 = *param_6 + 2;
44 }
45 }
46 }
47 }
48 }
49 }
50 FUN_006ce8f9();
51 return;
52}
We can observe that header_length, sender_length, receiver_length are all ACID. Therefore, nothing would prevent an attacker to craft a packet to reach line 29. At this point, a size field _Size is computed, which will later be used at line 35 on a memcpy function call. This value can be caused to be a very large integer value if the value of *param_6 is greater than the value of param_1[1].
After integer conversions, the expression will promote both integers to be unsigned integers since param_6 is an uint *. We can also observe that there is some sort of size check at line 34 that should be bypassed in order to reach the memcpy code path. With a very large value on _Size is likely that the expression local_20c + _Size_00 + iVar1 + local_214 + _Size < 0x201 can be satisfied by causing yet again another integer overflow on the expression result value to be less than 0x201, since _Size is ACID.
CVE-2019-14192
#
1////ACID: in_packet
2void net_process_received_packet(uchar *in_packet, int len)
3{
4 struct ethernet_hdr *et;
5 struct ip_udp_hdr *ip;
6 struct in_addr dst_ip;
7 struct in_addr src_ip;
8 int eth_proto;
9 // ...
10 ip = (struct ip_udp_hdr *)(in_packet + E802_HDR_SIZE);
11 // ...
12 switch (eth_proto) {
13 // ...
14 case PROT_IP:
15 debug_cond(DEBUG_NET_PKT, "Got IP\n");
16 /* Before we start poking the header, make sure it is there */
17 if (len < IP_UDP_HDR_SIZE) {
18 debug("len bad %d < %lu\n", len,
19 (ulong)IP_UDP_HDR_SIZE);
20 return;
21 }
22 /* Check the packet length */
23 if (len < ntohs(ip->ip_len)) {
24 debug("len bad %d < %d\n", len, ntohs(ip->ip_len));
25 return;
26 }
27 len = ntohs(ip->ip_len);
28 // ...
29 ip = net_defragment(ip, &len);
30 if (!ip)
31 return;
32 // ...
33 if (ip->ip_p == IPPROTO_ICMP) {
34 receive_icmp(ip, len, src_ip, et);
35 return;
36 } else if (ip->ip_p != IPPROTO_UDP) { /* Only UDP packets */
37 return;
38 }
39
40 // ...
41#if defined(CONFIG_NETCONSOLE) && !defined(CONFIG_SPL_BUILD)
42 nc_input_packet((uchar *)ip + IP_UDP_HDR_SIZE,
43 src_ip,
44 ntohs(ip->udp_dst),
45 ntohs(ip->udp_src),
46 ntohs(ip->udp_len) - UDP_HDR_SIZE);
47#endif
48 /*
49 * IP header OK. Pass the packet to the current handler.
50 */
51 (*udp_packet_handler)((uchar *)ip + IP_UDP_HDR_SIZE,
52 ntohs(ip->udp_dst),
53 src_ip,
54 ntohs(ip->udp_src),
55 ntohs(ip->udp_len) - UDP_HDR_SIZE);
56 break;
57 // ...
58 }
59}
In this example we can obervse that an UDP packet is parsed and ACID parameters are passed to either nc_input_packet or upd_packet_handler. We can obeserve that the 5th argument is some attacker controlled value ip->udp_len minus some constant UDP_HDR_SIZE.
The result of this expression can lead to an integer underflow, resulting in a very large integer, and it is not checked before its computed and passed as the packet length to the two aforementioned functions. Therefore, either one of these functions will be processing the subject udp packet with an incorrect packet size, which can later lead to memory corruption.
CVE-2020-11901
#
1//ACID: RDLENGTH, resourceRecordAfterNamePtr, dnsHeaderPtr
2if (RDLENGTH <= remaining_size) {
3 /* compute the next resource record pointer based on the RDLENGTH */
4 labelEndPtr = resourceRecordAfterNamePtr + 10 + RDLENGTH;
5 /* type: MX */
6 if (cacheEntryQueryType == DNS_TYPE_MX && rrtype == DNS_TYPE_MX) {
7 addr_info = tfDnsAllocAddrInfo();
8 if (addr_info != NULL && RDLENGTH >= 2) {
9 /* copy preference value of MX record */
10 memcpy(&addr_info->ai_mxpref,resourceRecordAfterNamePtr + 10, 2);
11 /* compute the length of the MX hostname */
12 labelLength = tfDnsExpLabelLength(resourceRecordAfterNamePtr + 0xc, dnsHeaderPtr, labelEndPtr);
13 addr_info->ai_mxhostname = NULL;
14 if (labelLength != 0) {
15 /* allocate buffer for the expanded name */
16 asciiPtr = tfGetRawBuffer((uint)labelLength);
17 addr_info->ai_mxhostname = asciiPtr;
18 if (asciiPtr != NULL) {
19 /* copy MX hostname to `asciiPtr` as ASCII */
20 tfDnsLabelToAscii(resourceRecordAfterNamePtr + 0xc, asciiPtr, dnsHeaderPtr, 1, 0);
21 /* ... */
22 }
23 /* ... */
24 }
25 /* ... */
26 }
27 /* ... */
28 }
29}
30
31tt16Bit tfDnsExpLabelLength(tt8BitPtr labelPtr, tt8BitPtr pktDataPtr, tt8BitPtr labelEndPtr){
32 tt8Bit currLabelLength;
33 tt16Bit i = 0, totalLength = 0;
34 tt8BitPtr newLabelPtr;
35
36 while (&labelPtr[i] < labelEndPtr && labelPtr[i] != 0) {
37 currLabelLength = labelPtr[i];
38 if ((currLabelLength & 0xc0) == 0) {
39 totalLength += currLabelLength + 1;
40 i += currLabelLength + 1;
41 } else {
42 if (&labelPtr[i+1] < labelEndPtr) {
43 newLabelPtr = pktDataPtr + (((currLabelLength & 0x3f) << 8) | labelPtr[i+1]);
44 if (newLabelPtr < labelPtr) {
45 labelPtr = newLabelPtr;
46 i = 0;
47 continue;
48 }
49 }
50 return 0;
51 }
52 }
53 return totalLength;
54}
We can observe that at line 12 the function tfDnsExpLabelLength is invoked and all their parameters are ACID. We can also see that at line 16, the return value of this function labelLength is used to allocate a buffer by tfGetRawBuffer, that later at line 20 the MX hostname is copied to this buffer by tfDNSLabelToAscii.
Therefore although we don’t have enough context to understand the MX hostname length, our goal is to make labelLength as small as possible to provoke an under-allocation, to then cause a potential OOB write to it. For that we need to take a close look at tfDnsExpLabelLength.
As we mentioned before, all of the supplied parameters to this function are ACID. This funtion’s purpose is to traverse the DNS MX records to compute the label total length. We can see a while loop at line 36 that will traverse the label records as long as &labelPtr[i] < labelEndPtr && labelPtr[i] != 0. In addition labelPtr can be set to a different value for compressed DNS records at line 45. Abusing these two concepts, its viable to overflow the value of totalLength at line 39, so that it becomes a small integer.
CVE-2020-16225
#
1////ACID: The data read from staFileHandler
2FILE *staFileHandler; //File handler is valid and already points to 0x200 location
3 //in .sta file being loaded.
4size_t x;
5size_t y;
6size_t allocSize;
7void *memoryAllocation;
8
9fread(&x, 4, 1, staFileHandler);
10fread(&y, 4, 1, staFileHandler);
11allocSize = y - x;
12memoryAllocation = VirtualAlloc(0, allocSize, 0x3000, 4);
13fread(memoryAllocation+x, 1, allocSize, staFileHandler);
This is a farily short example, but the way to abuse this is not as intuitive that one may think. If allocSize gets computed to be a verly large size_t value, as an example: 0xffffffffffffffff, VirtualAlloc will return 0.
Since the result of VirtualAlloc is not checked, at line 13, on fread call, memoryAllocation would be 0 and it will be added to x which its ACID and we can leverage as an arbitrary pointer.
Therefore, we can ultimately read an arbitrary amount of bytes from the ACID file, to an arbitrary memory location, as long as the size to be read is smaller or equal than the bytes remaining to be read from the file, as fread will read until the end of the file.
CVE-2020-17443
#
1////ACID: echo
2static int pico_icmp6_send_echoreply(struct pico_frame *echo)
3{
4 struct pico_frame *reply = NULL;
5 struct pico_icmp6_hdr *ehdr = NULL, *rhdr = NULL;
6 struct pico_ip6 src;
7 struct pico_ip6 dst;
8
9 reply = pico_proto_ipv6.alloc(&pico_proto_ipv6, echo->dev, (uint16_t)(echo->transport_len));
10 if (!reply) {
11 pico_err = PICO_ERR_ENOMEM;
12 return -1;
13 }
14
15 echo->payload = echo->transport_hdr + PICO_ICMP6HDR_ECHO_REQUEST_SIZE;
16 reply->payload = reply->transport_hdr + PICO_ICMP6HDR_ECHO_REQUEST_SIZE;
17 reply->payload_len = echo->transport_len;
18
19 ehdr = (struct pico_icmp6_hdr *)echo->transport_hdr;
20 rhdr = (struct pico_icmp6_hdr *)reply->transport_hdr;
21 rhdr->type = PICO_ICMP6_ECHO_REPLY;
22 rhdr->code = 0;
23 rhdr->msg.info.echo_reply.id = ehdr->msg.info.echo_reply.id;
24 rhdr->msg.info.echo_reply.seq = ehdr->msg.info.echo_request.seq;
25 memcpy(reply->payload, echo->payload, (uint32_t)(echo->transport_len - PICO_ICMP6HDR_ECHO_REQUEST_SIZE));
26 rhdr->crc = 0;
27 rhdr->crc = short_be(pico_icmp6_checksum(reply));
28 /* Get destination and source swapped */
29 memcpy(dst.addr, ((struct pico_ipv6_hdr *)echo->net_hdr)->src.addr, PICO_SIZE_IP6);
30 memcpy(src.addr, ((struct pico_ipv6_hdr *)echo->net_hdr)->dst.addr, PICO_SIZE_IP6);
31 pico_ipv6_frame_push(reply, &src, &dst, PICO_PROTO_ICMP6, 0);
32 return 0;
33}
34
35/* allocates an IPv6 packet without extension headers. If extension headers are needed,
36 * include the len of the extension headers in the size parameter. Once a frame acquired
37 * increment net_len and transport_hdr with the len of the extension headers, decrement
38 * transport_len with this value.
39 */
40static struct pico_frame *pico_ipv6_alloc(struct pico_protocol *self, struct pico_device *dev, uint16_t size)
41{
42 struct pico_frame *f = NULL;
43
44 IGNORE_PARAMETER(self);
45
46 if (0) {}
47#ifdef PICO_SUPPORT_6LOWPAN
48 else if (PICO_DEV_IS_6LOWPAN(dev)) {
49 f = pico_proto_6lowpan_ll.alloc(&pico_proto_6lowpan_ll, dev, (uint16_t)(size + PICO_SIZE_IP6HDR));
50 }
51#endif
52 else {
53#ifdef PICO_SUPPORT_ETH
54 f = pico_proto_ethernet.alloc(&pico_proto_ethernet, dev, (uint16_t)(size + PICO_SIZE_IP6HDR));
55#else
56 f = pico_frame_alloc(size + PICO_SIZE_IP6HDR + PICO_SIZE_ETHHDR);
57#endif
58 }
59
60 if (!f)
61 return NULL;
62
63 f->net_len = PICO_SIZE_IP6HDR;
64 f->transport_hdr = f->net_hdr + PICO_SIZE_IP6HDR;
65 f->transport_len = (uint16_t)size;
66
67 /* Datalink size is accounted for in pico_datalink_send (link layer) */
68 f->len = (uint32_t)(size + PICO_SIZE_IP6HDR);
69
70 return f;
71}
Several integer issues exist is the code snippet above:
The first one is the memcpy function at line 25, in which echo->transport_len is ACID and that gets substracted with PICO_ICMP6HDR_ECHO_REQUEST_SIZE, which can lead to a signed integer underflow and end up copying a verly large block of memory to reply->payload.
In addition, we can see other two potential integer overflows in pico_ipv6_alloc as there are no checks for the parameter size, and since size its a uint16_t and for both line 49, and line 54 the size field of the correspondent allocation function is also casted to an uint16, (uint16_t)(size + PICO_SIZE_IP6HDR) could overflow the range of an uint16_t causing memory under-allocation in both cases, which can potentially lead to out-of-bound writes.
CVE-2021-30860
#
1enum JBIG2SegmentType
2{
3 jbig2SegBitmap,
4 jbig2SegSymbolDict,
5 jbig2SegPatternDict,
6 jbig2SegCodeTable
7};
8
9////ACID: refSegs, nRefSegs
10void JBIG2Stream::readTextRegionSeg(unsigned int segNum, bool imm, bool lossless, unsigned int length, unsigned int *refSegs, unsigned int nRefSegs)
11{
12 JBIG2Segment *seg;
13 std::vector codeTables;
14 JBIG2SymbolDict *symbolDict;
15 JBIG2Bitmap **syms;
16 unsigned int huff;
17 unsigned int numSyms, symCodeLen;
18 unsigned int i, k, kk;
19
20 // ...
21
22 // get symbol dictionaries and tables
23 numSyms = 0;
24 for (i = 0; i < nRefSegs; ++i) {
25 if ((seg = findSegment(refSegs[i]))) {
26 if (seg->getType() == jbig2SegSymbolDict) {
27 numSyms += ((JBIG2SymbolDict *)seg)->getSize();
28 } else if (seg->getType() == jbig2SegCodeTable) {
29 codeTables.push_back(seg);
30 }
31 } else {
32 error(errSyntaxError, curStr->getPos(), "Invalid segment reference in JBIG2 text region");
33 return;
34 }
35 }
36
37 // ...
38
39 // get the symbol bitmaps
40 syms = (JBIG2Bitmap **)gmallocn(numSyms, sizeof(JBIG2Bitmap *));
41 if (numSyms > 0 && !syms) {
42 return;
43 }
44 kk = 0;
45 for (i = 0; i < nRefSegs; ++i) {
46 if ((seg = findSegment(refSegs[i]))) {
47 if (seg->getType() == jbig2SegSymbolDict) {
48 symbolDict = (JBIG2SymbolDict *)seg;
49 for (k = 0; k < symbolDict->getSize(); ++k) {
50 syms[kk++] = symbolDict->getBitmap(k);
51 }
52 }
53 }
54 }
The accumulator variable numSyms used in order to calculate the estimated size to allocate all jbig2SegSymbolDict segments, can overflow the unsigned integer range at line 27, as the for loop counter at line 24 is attacker-controlled.
This will lead to an under-allocation at line 40 on the call to gmallocn. Later at line 45, on another ACID loop-counter for loop, the jbig2SegSymbolDict segments are fetched again, but they are copied to the newly allocated buffer, since this buffer will be under-allocated, this will lead to an OOB write.
CVE-2021-22636
#
1int16_t _BundleCmdSignatureFile_Parse(
2 OtaArchive_BundleCmdTable_t *pBundleCmdTable,
3 uint8_t *pRecvBuf, //XENO: ACID: TAR file received over network
4 int16_t RecvBufLen, //XENO: SACI: Size of TAR file received over network
5 int16_t *ProcessedSize,
6 uint32_t SigFileSize, //XENO: ACID: Size from TAR file headers
7 uint8_t *pDigest)
8{
9 int16_t retVal = 0;
10 char * pSig = NULL;
11
12 /* Get the entire signature file */
13 retVal = GetEntireFile(pRecvBuf, RecvBufLen, ProcessedSize, SigFileSize,
14 &pSig);
15 if(retVal < 0)
16 {
17 return(retVal);
18 }
19 if(retVal == GET_ENTIRE_FILE_CONTINUE)
20 {
21 return(ARCHIVE_STATUS_BUNDLE_CMD_SIGNATURE_CONTINUE);
22 }
23
24 /* Verify the signature using ECDSA */
25 retVal = verifySignature(pSig, SigFileSize, pDigest);
26 if(retVal < 0)
27 {
28 _SlOtaLibTrace((
29 "[_BundleCmdSignatureFile_Parse] "
30 "signature verification failed!\r\n"));
31 return(retVal);
32 }
33
34 pBundleCmdTable->VerifiedSignature = 1;
35
36 return(ARCHIVE_STATUS_BUNDLE_CMD_SIGNATURE_DOWNLOAD_DONE);
37}
38int16_t GetEntireFile(uint8_t *pRecvBuf,
39 int16_t RecvBufLen,
40 int16_t *ProcessedSize,
41 uint32_t FileSize,
42 char **pFile)
43{
44 int16_t copyLen = 0;
45 static bool firstRun = TRUE;
46 static int16_t TotalRecvBufLen = 0;
47
48 if(firstRun)
49 {
50 TotalRecvBufLen = RecvBufLen;
51 firstRun = FALSE;
52 if(TotalRecvBufLen < FileSize)
53 {
54 /* Didn't receive the entire file in the first run. */
55 /* Allocate a buffer in the size of the entire file and fill
56 it in each round. */
57 pTempBuf = (char*)malloc(FileSize + 1);
58 if(pTempBuf == NULL)
59 {
60 /* Allocation failed, return error. */
61 return(-1);
62 }
63 memcpy(pTempBuf, (char *)pRecvBuf, RecvBufLen);
64 *ProcessedSize = RecvBufLen;
65
66 /* didn't receive the entire file, try in the next packet */
67 return(GET_ENTIRE_FILE_CONTINUE);
68 }
69 else
70 {
71 /* Received the entire file in the first run. */
72 /* No additional memory allocation is needed. */
73 *ProcessedSize = FileSize;
74 *pFile = (char *)pRecvBuf;
75 }
76 }
77 else
78 {
79 /* Avoid exceeding buffer size (FileSize + 1) */
80 if(RecvBufLen > ((FileSize + 1) - TotalRecvBufLen))
81 {
82 copyLen = ((FileSize + 1) - TotalRecvBufLen);
83 }
84 else
85 {
86 copyLen = RecvBufLen;
87 }
88
89 /* Copy the received buffer from where we stopped the previous copy */
90 memcpy(&(pTempBuf[TotalRecvBufLen]), (char *)pRecvBuf, copyLen);
91
92 *ProcessedSize = copyLen;
93 TotalRecvBufLen += copyLen;
94
95 if(TotalRecvBufLen < FileSize)
96 {
97 /* didn't receive the entire file, try in the next packet */
98 return(GET_ENTIRE_FILE_CONTINUE);
99 }
100
101 /* At this point we have the whole file */
102 *pFile = (char *)pTempBuf;
103 }
104
105 /* Set static variables to initial values to allow retry in
106 case of a warning during the OTA process */
107 firstRun = TRUE;
108 TotalRecvBufLen = 0;
109
110 return(GET_ENTIRE_FILE_DONE);
111}
112void ATTRIBUTE *malloc(size_t size)
113{
114 Header *packet;
115
116 if (size == 0) {
117 errno = EINVAL;
118 return (NULL);
119 }
120
121 packet = (Header *)pvPortMalloc(size + sizeof(Header));
122
123 if (packet == NULL) {
124 errno = ENOMEM;
125 return (NULL);
126 }
127
128 packet->header.actualBuf = (void *)packet;
129 packet->header.size = size + sizeof(Header);
130
131 return (packet + 1);
132}
We can observe in the function GetEntireFile (which takes ACID parameters at line 13 from _BundleCmdSignatureFile_Parse) calls malloc at line 57 with ACID FileSize + 1 as parameters. At line 121 we can observe that within the malloc implementation, pvPortMalloc allocates a buffer of size + sizeof(Header), which can lead to an integer overflow that will cause an under-allocated buffer.
Back at line 63 in the function GetEntireFile we can see that a memcpy call its used, copying memory to the potentially under-allocated buffer returned by malloc with ACID source buffer and size those being pRecvBuf and RecvBufLen respectively.
CVE-2019-15948
#
1
2////ACID: where ptr_ll_pkt points after assignment
3// Pseudocode from Ghidra decompilation
4void process_adv_ind_pdu(int ptr_some_struct)
5{
6 byte bVar1;
7 byte ll_len;
8 uint n;
9 uint uVar2;
10 byte *ptr_ll_pkt;
11 undefined local_40;
12 byte local_3f;
13 undefined auStack62 [0x6];
14 undefined local_38;
15 undefined stack_buffer [0x1f];
16 undefined local_18;
17
18 ptr_ll_pkt = (byte *)(DAT_0005b528 + (uint)*(ushort *)(ptr_some_struct + 0x8));
19 bVar1 = *ptr_ll_pkt;
20 ll_len = ptr_ll_pkt[0x1];
21 uVar2 = (uint)bVar1 & 0xf;
22 local_3f = (byte)(((uint)bVar1 << 0x19) >> 0x1f);
23 FUN_00067554(auStack62,ptr_ll_pkt + 0x2,0x6);
24 n = ((uint)ll_len & 0x3f) - 0x6 & 0xff;
25 local_38 = (undefined)n;
26 memcpy(stack_buffer,ptr_ll_pkt + 0x8,n);
27 local_18 = *(undefined *)(ptr_some_struct + 0xa);
28 if ((bVar1 & 0xf) == 0x0) {
29 local_40 = 0x0;
30 }
31 else {
32 if (uVar2 == 0x1) {
33 local_40 = 0x1;
34 local_38 = 0x0;
35 }
36 else {
37 if (uVar2 == 0x2) {
38 local_40 = 0x3;
39 }
40 else {
41 if (uVar2 != 0x6) {
42 return;
43 }
44 local_40 = 0x2;
45 }
46 }
47 }
48 FUN_000398e2(0x1,&local_40);
49 return;
50}
We can observe that ll_len is initialized at line 20 from ptr_ll_pkt which is ACID. ll_len is of type byte. Later at line 24, we can see that ll_len is explicitly casted to an unsigned integer value in order to initialize n which is an unsigned integer.
A binary mask is applied to the value of ll_len of 0x3f , then the value of 6 its substracted to it and the result is masked again against 0xff truncating the unsigned integer into an unsigned byte. The substraction of a constant value of six can lead to a buffer overflow, however the overflow will be at most of 0xff bytes due to unsigned int to byte integer truncation.
#
Integer Overflows/Underflows
Integer Overflows/Underflows are the product of signed and unsigned integers exceeding their positive and negative value ranges due to Attacker Control Input Data.
Integer Overflow Root Causes #
- ACID Arithmetic expressions involving lack or faulty checks ensuring result of arithmetic operation does not overflow/underflow
- Confusion between signed and unsigned integers
- Implicit integer conversions – eg: Signed sizes later converted to unsigned
- ACID loop-counter or loop-exit conditions that lead to progressive increments/decrements to an integer type that will endup overflowing/underflowing.
Integer Overflow As Vulnerabilties #
Most commonly (although not always), integer overflows/underflows tend to be leveraged as vulnerabilities following a common under-allocation, over-copy pattern.
Conceptually this pattern may look as follows: First an integer overflow can succesfully be abused to cause some sort of under-allocation condition. Something such as
dest = alloc(ACID1 + const)dest = alloc(ACID1 + ACID2)dest = alloc(ACID1 * const)- … etc
Then a memory copy si done to that allocation. Assuming the length of the copy is not affected by the same integer overflow condition, it would result in an over-copy condition relative to the previous under-allocated buffer:
copy(dest, src, ACID1)
Examples #
CVE-2020-0796 #
1////ACID: The data pointed to by request->pNetRawBuffer
2signed __int64 __fastcall Srv2DecompressData(SRV2_WORKITEM *workitem)
3{
4 // declarations omitted
5 ...
6 request = workitem->psbhRequest;
7 if ( request->dwMsgSize < 0x10 )
8 return 0xC000090B;
9 compressHeader = *(CompressionTransformHeader *)request->pNetRawBuffer;
10 ...
11
12 newHeader = SrvNetAllocateBuffer((unsigned int)(compressHeader.originalCompressedSegSize + compressHeader.offsetOrLength), 0);
13 if ( !newHeader )
14 return 0xC000009A;
15
16 if ( SmbCompressionDecompress(
17 compressHeader.compressionType,
18 &workitem->psbhRequest->pNetRawBuffer[compressHeader.offsetOrLength + 16],
19 workitem->psbhRequest->dwMsgSize - compressHeader.offsetOrLength - 16,
20 &newHeader->pNetRawBuffer[compressHeader.offsetOrLength],
21 compressHeader.OriginalCompressedSegSize,
22 &finalDecompressedSize) < 0
23 || finalDecompressedSize != compressHeader.originalCompressedSegSize) )
24 {
25 SrvNetFreeBuffer(newHeader);
26 return 0xC000090B;
27 }
28 if ( compressHeader.offsetOrLength )
29 {
30 memmove(newHeader->pNetRawBuffer, workitem->psbhRequest->pNetRawBuffer + 16, compressHeader.offsetOrLength);
31 }
32 newHeader->dwMsgSize = compressHeader.OffsetOrLength + fianlDecompressedSize;
33 Srv2ReplaceReceiveBuffer(workitem, newHeader);
34 return 0;
35}
The function SrvNetAllocateBuffer allocates the result of this expression: compressHeader.originalCompressedSegSize + compressHeader.offsetOrLength. Both operands of this arithmetic expression are ACID.
If we later look at line 30, we can see a memmove to this newly allocated memory with a controlled size of compressHeader.offsetOrLength. This means that if the expression compressHeader.originalCompressedSegSize + compressHeader.offsetOrLength succesfully overflows the range of an unsigned integer, resulting in a smaller computed value relative than compressHeader.offsetOrLength, a buffer overflow will occur due to an integer overflow.
CVE-2019-5105 #
1////ACID: param_1
2void FUN_00677d70(void **param_1, int param_2, int param_3, int param_4, int param_5 ,uint *param_6)
3{
4 int header_length;
5 size_t _Size;
6 int iVar1;
7 int iVar2;
8 int receiver_length;
9 uint sender_length;
10 /* Omitted code */
11 void *blkDrvPDUdata;
12 /* Omitted code */
13 iVar2 = *(int *)(param_2 + 0x128) + DAT_007a3534;
14 if (iVar2 < 0xf) {
15 /* Omitted code */
16 blkDrvPDUdata = *param_1;
17 header_length = (*(byte *)((int)blkDrvPDUdata + 1) & 7) * 2;
18 sender_length = *(byte *)((int)blkDrvPDUdata + 5) & 0xf;
19 receiver_length = (int)(uint)*(byte *)((int)blkDrvPDUdata + 5) >> 4;
20 pvVar3 = (void *)(sender_length + receiver_length + header_length);
21 local_20c = header_length;
22 if (pvVar3 < param_1[1] || pvVar3 == param_1[1]) {
23 pvVar3 = *param_1;
24 if ((*(byte *)((int)blkDrvPDUdata + 2) & 0x10) == 0) {
25 *param_6 = header_length + (sender_length + receiver_length) * 2;
26 if ((*param_6 & 3) != 0) {
27 *param_6 = *param_6 + 2;
28 }
29 _Size = (int)param_1[1] - *param_6;
30
31 /* Omitted code*/
32 if ((local_220 < 0x10) && (local_244 < 0x10)) {
33 /* Omitted Code*/
34 if (local_20c + _Size_00 + iVar1 + local_214 + _Size < 0x201) {
35 memcpy(local_208 + local_214 + iVar1 + _Size_00 + local_20c,
36 (void *)((int)*param_1 + *param_6), _Size );
37 param_1[1] = (void *)(local_20c + _Size_00 + iVar1 + local_214 + _Size);
38 memcpy(*param_1,local_208,(size_t)param_1[1]);
39 *(int *)(param_5 + 0xc) = (int)*param_1 + local_20c;
40 *(int *)(param_4 + 0xc) = *(int *)(param_5 + 0xc) + *(int *)(param_5 + 8) * 2;
41 *param_6 = local_20c + _Size_00 + iVar1;
42 if ((*param_6 & 3) != 0) {
43 *param_6 = *param_6 + 2;
44 }
45 }
46 }
47 }
48 }
49 }
50 FUN_006ce8f9();
51 return;
52}
We can observe that header_length, sender_length, receiver_length are all ACID. Therefore, nothing would prevent an attacker to craft a packet to reach line 29. At this point, a size field _Size is computed, which will later be used at line 35 on a memcpy function call. This value can be caused to be a very large integer value if the value of *param_6 is greater than the value of param_1[1].
After integer conversions, the expression will promote both integers to be unsigned integers since param_6 is an uint *. We can also observe that there is some sort of size check at line 34 that should be bypassed in order to reach the memcpy code path. With a very large value on _Size is likely that the expression local_20c + _Size_00 + iVar1 + local_214 + _Size < 0x201 can be satisfied by causing yet again another integer overflow on the expression result value to be less than 0x201, since _Size is ACID.
CVE-2019-14192 #
1////ACID: in_packet
2void net_process_received_packet(uchar *in_packet, int len)
3{
4 struct ethernet_hdr *et;
5 struct ip_udp_hdr *ip;
6 struct in_addr dst_ip;
7 struct in_addr src_ip;
8 int eth_proto;
9 // ...
10 ip = (struct ip_udp_hdr *)(in_packet + E802_HDR_SIZE);
11 // ...
12 switch (eth_proto) {
13 // ...
14 case PROT_IP:
15 debug_cond(DEBUG_NET_PKT, "Got IP\n");
16 /* Before we start poking the header, make sure it is there */
17 if (len < IP_UDP_HDR_SIZE) {
18 debug("len bad %d < %lu\n", len,
19 (ulong)IP_UDP_HDR_SIZE);
20 return;
21 }
22 /* Check the packet length */
23 if (len < ntohs(ip->ip_len)) {
24 debug("len bad %d < %d\n", len, ntohs(ip->ip_len));
25 return;
26 }
27 len = ntohs(ip->ip_len);
28 // ...
29 ip = net_defragment(ip, &len);
30 if (!ip)
31 return;
32 // ...
33 if (ip->ip_p == IPPROTO_ICMP) {
34 receive_icmp(ip, len, src_ip, et);
35 return;
36 } else if (ip->ip_p != IPPROTO_UDP) { /* Only UDP packets */
37 return;
38 }
39
40 // ...
41#if defined(CONFIG_NETCONSOLE) && !defined(CONFIG_SPL_BUILD)
42 nc_input_packet((uchar *)ip + IP_UDP_HDR_SIZE,
43 src_ip,
44 ntohs(ip->udp_dst),
45 ntohs(ip->udp_src),
46 ntohs(ip->udp_len) - UDP_HDR_SIZE);
47#endif
48 /*
49 * IP header OK. Pass the packet to the current handler.
50 */
51 (*udp_packet_handler)((uchar *)ip + IP_UDP_HDR_SIZE,
52 ntohs(ip->udp_dst),
53 src_ip,
54 ntohs(ip->udp_src),
55 ntohs(ip->udp_len) - UDP_HDR_SIZE);
56 break;
57 // ...
58 }
59}
In this example we can obervse that an UDP packet is parsed and ACID parameters are passed to either nc_input_packet or upd_packet_handler. We can obeserve that the 5th argument is some attacker controlled value ip->udp_len minus some constant UDP_HDR_SIZE.
The result of this expression can lead to an integer underflow, resulting in a very large integer, and it is not checked before its computed and passed as the packet length to the two aforementioned functions. Therefore, either one of these functions will be processing the subject udp packet with an incorrect packet size, which can later lead to memory corruption.
CVE-2020-11901 #
1//ACID: RDLENGTH, resourceRecordAfterNamePtr, dnsHeaderPtr
2if (RDLENGTH <= remaining_size) {
3 /* compute the next resource record pointer based on the RDLENGTH */
4 labelEndPtr = resourceRecordAfterNamePtr + 10 + RDLENGTH;
5 /* type: MX */
6 if (cacheEntryQueryType == DNS_TYPE_MX && rrtype == DNS_TYPE_MX) {
7 addr_info = tfDnsAllocAddrInfo();
8 if (addr_info != NULL && RDLENGTH >= 2) {
9 /* copy preference value of MX record */
10 memcpy(&addr_info->ai_mxpref,resourceRecordAfterNamePtr + 10, 2);
11 /* compute the length of the MX hostname */
12 labelLength = tfDnsExpLabelLength(resourceRecordAfterNamePtr + 0xc, dnsHeaderPtr, labelEndPtr);
13 addr_info->ai_mxhostname = NULL;
14 if (labelLength != 0) {
15 /* allocate buffer for the expanded name */
16 asciiPtr = tfGetRawBuffer((uint)labelLength);
17 addr_info->ai_mxhostname = asciiPtr;
18 if (asciiPtr != NULL) {
19 /* copy MX hostname to `asciiPtr` as ASCII */
20 tfDnsLabelToAscii(resourceRecordAfterNamePtr + 0xc, asciiPtr, dnsHeaderPtr, 1, 0);
21 /* ... */
22 }
23 /* ... */
24 }
25 /* ... */
26 }
27 /* ... */
28 }
29}
30
31tt16Bit tfDnsExpLabelLength(tt8BitPtr labelPtr, tt8BitPtr pktDataPtr, tt8BitPtr labelEndPtr){
32 tt8Bit currLabelLength;
33 tt16Bit i = 0, totalLength = 0;
34 tt8BitPtr newLabelPtr;
35
36 while (&labelPtr[i] < labelEndPtr && labelPtr[i] != 0) {
37 currLabelLength = labelPtr[i];
38 if ((currLabelLength & 0xc0) == 0) {
39 totalLength += currLabelLength + 1;
40 i += currLabelLength + 1;
41 } else {
42 if (&labelPtr[i+1] < labelEndPtr) {
43 newLabelPtr = pktDataPtr + (((currLabelLength & 0x3f) << 8) | labelPtr[i+1]);
44 if (newLabelPtr < labelPtr) {
45 labelPtr = newLabelPtr;
46 i = 0;
47 continue;
48 }
49 }
50 return 0;
51 }
52 }
53 return totalLength;
54}
We can observe that at line 12 the function tfDnsExpLabelLength is invoked and all their parameters are ACID. We can also see that at line 16, the return value of this function labelLength is used to allocate a buffer by tfGetRawBuffer, that later at line 20 the MX hostname is copied to this buffer by tfDNSLabelToAscii.
Therefore although we don’t have enough context to understand the MX hostname length, our goal is to make labelLength as small as possible to provoke an under-allocation, to then cause a potential OOB write to it. For that we need to take a close look at tfDnsExpLabelLength.
As we mentioned before, all of the supplied parameters to this function are ACID. This funtion’s purpose is to traverse the DNS MX records to compute the label total length. We can see a while loop at line 36 that will traverse the label records as long as &labelPtr[i] < labelEndPtr && labelPtr[i] != 0. In addition labelPtr can be set to a different value for compressed DNS records at line 45. Abusing these two concepts, its viable to overflow the value of totalLength at line 39, so that it becomes a small integer.
CVE-2020-16225 #
1////ACID: The data read from staFileHandler
2FILE *staFileHandler; //File handler is valid and already points to 0x200 location
3 //in .sta file being loaded.
4size_t x;
5size_t y;
6size_t allocSize;
7void *memoryAllocation;
8
9fread(&x, 4, 1, staFileHandler);
10fread(&y, 4, 1, staFileHandler);
11allocSize = y - x;
12memoryAllocation = VirtualAlloc(0, allocSize, 0x3000, 4);
13fread(memoryAllocation+x, 1, allocSize, staFileHandler);
This is a farily short example, but the way to abuse this is not as intuitive that one may think. If allocSize gets computed to be a verly large size_t value, as an example: 0xffffffffffffffff, VirtualAlloc will return 0.
Since the result of VirtualAlloc is not checked, at line 13, on fread call, memoryAllocation would be 0 and it will be added to x which its ACID and we can leverage as an arbitrary pointer.
Therefore, we can ultimately read an arbitrary amount of bytes from the ACID file, to an arbitrary memory location, as long as the size to be read is smaller or equal than the bytes remaining to be read from the file, as fread will read until the end of the file.
CVE-2020-17443 #
1////ACID: echo
2static int pico_icmp6_send_echoreply(struct pico_frame *echo)
3{
4 struct pico_frame *reply = NULL;
5 struct pico_icmp6_hdr *ehdr = NULL, *rhdr = NULL;
6 struct pico_ip6 src;
7 struct pico_ip6 dst;
8
9 reply = pico_proto_ipv6.alloc(&pico_proto_ipv6, echo->dev, (uint16_t)(echo->transport_len));
10 if (!reply) {
11 pico_err = PICO_ERR_ENOMEM;
12 return -1;
13 }
14
15 echo->payload = echo->transport_hdr + PICO_ICMP6HDR_ECHO_REQUEST_SIZE;
16 reply->payload = reply->transport_hdr + PICO_ICMP6HDR_ECHO_REQUEST_SIZE;
17 reply->payload_len = echo->transport_len;
18
19 ehdr = (struct pico_icmp6_hdr *)echo->transport_hdr;
20 rhdr = (struct pico_icmp6_hdr *)reply->transport_hdr;
21 rhdr->type = PICO_ICMP6_ECHO_REPLY;
22 rhdr->code = 0;
23 rhdr->msg.info.echo_reply.id = ehdr->msg.info.echo_reply.id;
24 rhdr->msg.info.echo_reply.seq = ehdr->msg.info.echo_request.seq;
25 memcpy(reply->payload, echo->payload, (uint32_t)(echo->transport_len - PICO_ICMP6HDR_ECHO_REQUEST_SIZE));
26 rhdr->crc = 0;
27 rhdr->crc = short_be(pico_icmp6_checksum(reply));
28 /* Get destination and source swapped */
29 memcpy(dst.addr, ((struct pico_ipv6_hdr *)echo->net_hdr)->src.addr, PICO_SIZE_IP6);
30 memcpy(src.addr, ((struct pico_ipv6_hdr *)echo->net_hdr)->dst.addr, PICO_SIZE_IP6);
31 pico_ipv6_frame_push(reply, &src, &dst, PICO_PROTO_ICMP6, 0);
32 return 0;
33}
34
35/* allocates an IPv6 packet without extension headers. If extension headers are needed,
36 * include the len of the extension headers in the size parameter. Once a frame acquired
37 * increment net_len and transport_hdr with the len of the extension headers, decrement
38 * transport_len with this value.
39 */
40static struct pico_frame *pico_ipv6_alloc(struct pico_protocol *self, struct pico_device *dev, uint16_t size)
41{
42 struct pico_frame *f = NULL;
43
44 IGNORE_PARAMETER(self);
45
46 if (0) {}
47#ifdef PICO_SUPPORT_6LOWPAN
48 else if (PICO_DEV_IS_6LOWPAN(dev)) {
49 f = pico_proto_6lowpan_ll.alloc(&pico_proto_6lowpan_ll, dev, (uint16_t)(size + PICO_SIZE_IP6HDR));
50 }
51#endif
52 else {
53#ifdef PICO_SUPPORT_ETH
54 f = pico_proto_ethernet.alloc(&pico_proto_ethernet, dev, (uint16_t)(size + PICO_SIZE_IP6HDR));
55#else
56 f = pico_frame_alloc(size + PICO_SIZE_IP6HDR + PICO_SIZE_ETHHDR);
57#endif
58 }
59
60 if (!f)
61 return NULL;
62
63 f->net_len = PICO_SIZE_IP6HDR;
64 f->transport_hdr = f->net_hdr + PICO_SIZE_IP6HDR;
65 f->transport_len = (uint16_t)size;
66
67 /* Datalink size is accounted for in pico_datalink_send (link layer) */
68 f->len = (uint32_t)(size + PICO_SIZE_IP6HDR);
69
70 return f;
71}
Several integer issues exist is the code snippet above:
The first one is the memcpy function at line 25, in which echo->transport_len is ACID and that gets substracted with PICO_ICMP6HDR_ECHO_REQUEST_SIZE, which can lead to a signed integer underflow and end up copying a verly large block of memory to reply->payload.
In addition, we can see other two potential integer overflows in pico_ipv6_alloc as there are no checks for the parameter size, and since size its a uint16_t and for both line 49, and line 54 the size field of the correspondent allocation function is also casted to an uint16, (uint16_t)(size + PICO_SIZE_IP6HDR) could overflow the range of an uint16_t causing memory under-allocation in both cases, which can potentially lead to out-of-bound writes.
CVE-2021-30860 #
1enum JBIG2SegmentType
2{
3 jbig2SegBitmap,
4 jbig2SegSymbolDict,
5 jbig2SegPatternDict,
6 jbig2SegCodeTable
7};
8
9////ACID: refSegs, nRefSegs
10void JBIG2Stream::readTextRegionSeg(unsigned int segNum, bool imm, bool lossless, unsigned int length, unsigned int *refSegs, unsigned int nRefSegs)
11{
12 JBIG2Segment *seg;
13 std::vector codeTables;
14 JBIG2SymbolDict *symbolDict;
15 JBIG2Bitmap **syms;
16 unsigned int huff;
17 unsigned int numSyms, symCodeLen;
18 unsigned int i, k, kk;
19
20 // ...
21
22 // get symbol dictionaries and tables
23 numSyms = 0;
24 for (i = 0; i < nRefSegs; ++i) {
25 if ((seg = findSegment(refSegs[i]))) {
26 if (seg->getType() == jbig2SegSymbolDict) {
27 numSyms += ((JBIG2SymbolDict *)seg)->getSize();
28 } else if (seg->getType() == jbig2SegCodeTable) {
29 codeTables.push_back(seg);
30 }
31 } else {
32 error(errSyntaxError, curStr->getPos(), "Invalid segment reference in JBIG2 text region");
33 return;
34 }
35 }
36
37 // ...
38
39 // get the symbol bitmaps
40 syms = (JBIG2Bitmap **)gmallocn(numSyms, sizeof(JBIG2Bitmap *));
41 if (numSyms > 0 && !syms) {
42 return;
43 }
44 kk = 0;
45 for (i = 0; i < nRefSegs; ++i) {
46 if ((seg = findSegment(refSegs[i]))) {
47 if (seg->getType() == jbig2SegSymbolDict) {
48 symbolDict = (JBIG2SymbolDict *)seg;
49 for (k = 0; k < symbolDict->getSize(); ++k) {
50 syms[kk++] = symbolDict->getBitmap(k);
51 }
52 }
53 }
54 }
The accumulator variable numSyms used in order to calculate the estimated size to allocate all jbig2SegSymbolDict segments, can overflow the unsigned integer range at line 27, as the for loop counter at line 24 is attacker-controlled.
This will lead to an under-allocation at line 40 on the call to gmallocn. Later at line 45, on another ACID loop-counter for loop, the jbig2SegSymbolDict segments are fetched again, but they are copied to the newly allocated buffer, since this buffer will be under-allocated, this will lead to an OOB write.
CVE-2021-22636 #
1int16_t _BundleCmdSignatureFile_Parse(
2 OtaArchive_BundleCmdTable_t *pBundleCmdTable,
3 uint8_t *pRecvBuf, //XENO: ACID: TAR file received over network
4 int16_t RecvBufLen, //XENO: SACI: Size of TAR file received over network
5 int16_t *ProcessedSize,
6 uint32_t SigFileSize, //XENO: ACID: Size from TAR file headers
7 uint8_t *pDigest)
8{
9 int16_t retVal = 0;
10 char * pSig = NULL;
11
12 /* Get the entire signature file */
13 retVal = GetEntireFile(pRecvBuf, RecvBufLen, ProcessedSize, SigFileSize,
14 &pSig);
15 if(retVal < 0)
16 {
17 return(retVal);
18 }
19 if(retVal == GET_ENTIRE_FILE_CONTINUE)
20 {
21 return(ARCHIVE_STATUS_BUNDLE_CMD_SIGNATURE_CONTINUE);
22 }
23
24 /* Verify the signature using ECDSA */
25 retVal = verifySignature(pSig, SigFileSize, pDigest);
26 if(retVal < 0)
27 {
28 _SlOtaLibTrace((
29 "[_BundleCmdSignatureFile_Parse] "
30 "signature verification failed!\r\n"));
31 return(retVal);
32 }
33
34 pBundleCmdTable->VerifiedSignature = 1;
35
36 return(ARCHIVE_STATUS_BUNDLE_CMD_SIGNATURE_DOWNLOAD_DONE);
37}
38int16_t GetEntireFile(uint8_t *pRecvBuf,
39 int16_t RecvBufLen,
40 int16_t *ProcessedSize,
41 uint32_t FileSize,
42 char **pFile)
43{
44 int16_t copyLen = 0;
45 static bool firstRun = TRUE;
46 static int16_t TotalRecvBufLen = 0;
47
48 if(firstRun)
49 {
50 TotalRecvBufLen = RecvBufLen;
51 firstRun = FALSE;
52 if(TotalRecvBufLen < FileSize)
53 {
54 /* Didn't receive the entire file in the first run. */
55 /* Allocate a buffer in the size of the entire file and fill
56 it in each round. */
57 pTempBuf = (char*)malloc(FileSize + 1);
58 if(pTempBuf == NULL)
59 {
60 /* Allocation failed, return error. */
61 return(-1);
62 }
63 memcpy(pTempBuf, (char *)pRecvBuf, RecvBufLen);
64 *ProcessedSize = RecvBufLen;
65
66 /* didn't receive the entire file, try in the next packet */
67 return(GET_ENTIRE_FILE_CONTINUE);
68 }
69 else
70 {
71 /* Received the entire file in the first run. */
72 /* No additional memory allocation is needed. */
73 *ProcessedSize = FileSize;
74 *pFile = (char *)pRecvBuf;
75 }
76 }
77 else
78 {
79 /* Avoid exceeding buffer size (FileSize + 1) */
80 if(RecvBufLen > ((FileSize + 1) - TotalRecvBufLen))
81 {
82 copyLen = ((FileSize + 1) - TotalRecvBufLen);
83 }
84 else
85 {
86 copyLen = RecvBufLen;
87 }
88
89 /* Copy the received buffer from where we stopped the previous copy */
90 memcpy(&(pTempBuf[TotalRecvBufLen]), (char *)pRecvBuf, copyLen);
91
92 *ProcessedSize = copyLen;
93 TotalRecvBufLen += copyLen;
94
95 if(TotalRecvBufLen < FileSize)
96 {
97 /* didn't receive the entire file, try in the next packet */
98 return(GET_ENTIRE_FILE_CONTINUE);
99 }
100
101 /* At this point we have the whole file */
102 *pFile = (char *)pTempBuf;
103 }
104
105 /* Set static variables to initial values to allow retry in
106 case of a warning during the OTA process */
107 firstRun = TRUE;
108 TotalRecvBufLen = 0;
109
110 return(GET_ENTIRE_FILE_DONE);
111}
112void ATTRIBUTE *malloc(size_t size)
113{
114 Header *packet;
115
116 if (size == 0) {
117 errno = EINVAL;
118 return (NULL);
119 }
120
121 packet = (Header *)pvPortMalloc(size + sizeof(Header));
122
123 if (packet == NULL) {
124 errno = ENOMEM;
125 return (NULL);
126 }
127
128 packet->header.actualBuf = (void *)packet;
129 packet->header.size = size + sizeof(Header);
130
131 return (packet + 1);
132}
We can observe in the function GetEntireFile (which takes ACID parameters at line 13 from _BundleCmdSignatureFile_Parse) calls malloc at line 57 with ACID FileSize + 1 as parameters. At line 121 we can observe that within the malloc implementation, pvPortMalloc allocates a buffer of size + sizeof(Header), which can lead to an integer overflow that will cause an under-allocated buffer.
Back at line 63 in the function GetEntireFile we can see that a memcpy call its used, copying memory to the potentially under-allocated buffer returned by malloc with ACID source buffer and size those being pRecvBuf and RecvBufLen respectively.
CVE-2019-15948 #
1
2////ACID: where ptr_ll_pkt points after assignment
3// Pseudocode from Ghidra decompilation
4void process_adv_ind_pdu(int ptr_some_struct)
5{
6 byte bVar1;
7 byte ll_len;
8 uint n;
9 uint uVar2;
10 byte *ptr_ll_pkt;
11 undefined local_40;
12 byte local_3f;
13 undefined auStack62 [0x6];
14 undefined local_38;
15 undefined stack_buffer [0x1f];
16 undefined local_18;
17
18 ptr_ll_pkt = (byte *)(DAT_0005b528 + (uint)*(ushort *)(ptr_some_struct + 0x8));
19 bVar1 = *ptr_ll_pkt;
20 ll_len = ptr_ll_pkt[0x1];
21 uVar2 = (uint)bVar1 & 0xf;
22 local_3f = (byte)(((uint)bVar1 << 0x19) >> 0x1f);
23 FUN_00067554(auStack62,ptr_ll_pkt + 0x2,0x6);
24 n = ((uint)ll_len & 0x3f) - 0x6 & 0xff;
25 local_38 = (undefined)n;
26 memcpy(stack_buffer,ptr_ll_pkt + 0x8,n);
27 local_18 = *(undefined *)(ptr_some_struct + 0xa);
28 if ((bVar1 & 0xf) == 0x0) {
29 local_40 = 0x0;
30 }
31 else {
32 if (uVar2 == 0x1) {
33 local_40 = 0x1;
34 local_38 = 0x0;
35 }
36 else {
37 if (uVar2 == 0x2) {
38 local_40 = 0x3;
39 }
40 else {
41 if (uVar2 != 0x6) {
42 return;
43 }
44 local_40 = 0x2;
45 }
46 }
47 }
48 FUN_000398e2(0x1,&local_40);
49 return;
50}
We can observe that ll_len is initialized at line 20 from ptr_ll_pkt which is ACID. ll_len is of type byte. Later at line 24, we can see that ll_len is explicitly casted to an unsigned integer value in order to initialize n which is an unsigned integer.
A binary mask is applied to the value of ll_len of 0x3f , then the value of 6 its substracted to it and the result is masked again against 0xff truncating the unsigned integer into an unsigned byte. The substraction of a constant value of six can lead to a buffer overflow, however the overflow will be at most of 0xff bytes due to unsigned int to byte integer truncation.
Uninitialized Data Access
Also known as UDA, Its when memory isn’t initialized, and it takes on whatever values happen to already be in that memory location. This becomes a vulnerability when leftover values/data in memory can be attacker-controlled.
Common Causes
#
- Not initializing local variables at declaration which later are accessed.
- Not initializing heap data at allocation time, which later are accessed.
- Only partially initializing structs and objects, which later non-initialized members are accessed.
- Accidental failure to initialize variables down an uncommon control-flow path
- Eg: passsing a pointer to an uninitialized struct to a function, and expecting it to perform initialization, but then it returns early before any initialization occurs.
Note: Fuzzers and specific compiler instrumentation can assist to find and mitigate this type of vulnerabilities. In particular MemorySanitizer is the adequate sanitizer in charge to detect uninitialized variable usage in fuzzers. In addition, compiler flags such as -ftrivial-auto-var-init=pattern or -ftrivial-auto-var-init=zero can force the initialization of variables and help mitigate these vulnerabiltities.
Examples
#
CVE-2022-1809
#
1//////////////////////////////////////////////////////////////////////
2//XENO: Structure that isn't completely initialized
3//////////////////////////////////////////////////////////////////////
4/* vtables */
5typedef struct {
6 RAnal *anal;
7 RAnalCPPABI abi;
8 ut8 word_size;
9 bool (*read_addr) (RAnal *anal, ut64 addr, ut64 *buf);
10} RVTableContext;
11
12//////////////////////////////////////////////////////////////////////
13//XENO: Part of the path where incomplete initialized occurs
14//////////////////////////////////////////////////////////////////////
15
16//XENO: assume the following fields are ACID based on a malicious ACID binary under analysis:
17//XENO: anal->config->bits, anal->cur->arch
18
19R_API bool r_anal_vtable_begin(RAnal *anal, RVTableContext *context) {
20 context->anal = anal;
21 context->abi = anal->cxxabi;
22 context->word_size = (ut8) (anal->config->bits / 8);
23 const bool is_arm = anal->cur->arch && r_str_startswith (anal->cur->arch, "arm");
24 if (is_arm && context->word_size < 4) {
25 context->word_size = 4;
26 }
27 const bool be = anal->config->big_endian;
28 switch (context->word_size) {
29 case 1:
30 context->read_addr = be? vtable_read_addr_be8 : vtable_read_addr_le8;
31 break;
32 case 2:
33 context->read_addr = be? vtable_read_addr_be16 : vtable_read_addr_le16;
34 break;
35 case 4:
36 context->read_addr = be? vtable_read_addr_be32 : vtable_read_addr_le32;
37 break;
38 case 8:
39 context->read_addr = be? vtable_read_addr_be64 : vtable_read_addr_le64;
40 break;
41 default:
42 return false;
43 }
44 return true;
45}
46
47//////////////////////////////////////////////////////////////////////
48//XENO: Part of the path where uninitialized access occurs eventually
49//////////////////////////////////////////////////////////////////////
50
51
52R_API void r_anal_list_vtables(RAnal *anal, int rad) {
53 RVTableContext context;
54 r_anal_vtable_begin (anal, &context);
55
56 const char *noMethodName = "No Name found";
57 RVTableMethodInfo *curMethod;
58 RListIter *vtableIter;
59 RVTableInfo *table;
60
61 RList *vtables = r_anal_vtable_search (&context);
62//XENO: snip
63}
64
65R_API RList *r_anal_vtable_search(RVTableContext *context) {
66 RAnal *anal = context->anal;
67 if (!anal) {
68 return NULL;
69 }
70
71 RList *vtables = r_list_newf ((RListFree)r_anal_vtable_info_free);
72 if (!vtables) {
73 return NULL;
74 }
75
76 RList *sections = anal->binb.get_sections (anal->binb.bin);
77 if (!sections) {
78 r_list_free (vtables);
79 return NULL;
80 }
81
82 r_cons_break_push (NULL, NULL);
83
84 RListIter *iter;
85 RBinSection *section;
86 r_list_foreach (sections, iter, section) {
87 if (r_cons_is_breaked ()) {
88 break;
89 }
90
91 if (!vtable_section_can_contain_vtables (section)) {
92 continue;
93 }
94
95 ut64 startAddress = section->vaddr;
96 ut64 endAddress = startAddress + (section->vsize) - context->word_size;
97 ut64 ss = endAddress - startAddress;
98 if (ss > ST32_MAX) {
99 break;
100 }
101 while (startAddress <= endAddress) {
102 if (r_cons_is_breaked ()) {
103 break;
104 }
105 if (!anal->iob.is_valid_offset (anal->iob.io, startAddress, 0)) {
106 break;
107 }
108
109 if (vtable_is_addr_vtable_start (context, section, startAddress)) {
110 RVTableInfo *vtable = r_anal_vtable_parse_at (context, startAddress);
111 if (vtable) {
112 r_list_append (vtables, vtable);
113 ut64 size = r_anal_vtable_info_get_size (context, vtable);
114 if (size > 0) {
115 startAddress += size;
116 continue;
117 }
118 }
119 }
120 startAddress += context->word_size;
121 }
122 }
123//XENO: snip
124}
125
126static bool vtable_is_addr_vtable_start(RVTableContext *context, RBinSection *section, ut64 curAddress) {
127 if (context->abi == R_ANAL_CPP_ABI_MSVC) {
128 return vtable_is_addr_vtable_start_msvc (context, curAddress);
129 }
130 if (context->abi == R_ANAL_CPP_ABI_ITANIUM) {
131 return vtable_is_addr_vtable_start_itanium (context, section, curAddress);
132 }
133 r_return_val_if_reached (false);
134 return false;
135}
136
137static bool vtable_is_addr_vtable_start_msvc(RVTableContext *context, ut64 curAddress) {
138 RAnalRef *xref;
139 RListIter *xrefIter;
140
141 if (!curAddress || curAddress == UT64_MAX) {
142 return false;
143 }
144 if (curAddress && !vtable_is_value_in_text_section (context, curAddress, NULL)) {
145 return false;
146 }
147//XENO: snip
148}
149
150static bool vtable_is_value_in_text_section(RVTableContext *context, ut64 curAddress, ut64 *value) {
151 //value at the current address
152 ut64 curAddressValue;
153 if (!context->read_addr (context->anal, curAddress, &curAddressValue)) {
154 return false;
155 }
156 //if the value is in text section
157 bool ret = vtable_addr_in_text_section (context, curAddressValue);
158 if (value) {
159 *value = curAddressValue;
160 }
161 return ret;
162}
Before proceeding further, we need to acknowledge the members of the RVTableContext struct, in particular the function pointer read_addr. After noting this, we can start our analysis at r_anal_list_vtables in which we can see how a RVTableContext object stored at context is declared but not initialized, although its immediately passed to the r_anal_vtable_begin function to initialize it.
At r_anal_vtable_begin we see that various fields are initialized for context. We should remmeber that anal->config->bits and anal->cur->arch are ACID, meaning that an attacker can potentially control the value of context->word_size and is_arm. Controlling these two variables, an attacker could craft its way into the default case in the subsequent switch case, in which we can observe that context->read_addr fails to be initialized, and the funciton simply returns false.
Its important to note that at r_anal_list_vtables this return value its failed to be validated. Moving down the data flow, eventually we can spot that at line 153 in vtable_is_value_in_text_section, context->read_addr its invoked without it previously being initialized, potentially leading to an arbitrary PC control primitive.
An attacker would have to carefully groom the stack by calling other functions prior to vtable_is_value_in_text_section, in which may gain to set some ACID value in the stack at the same offset where context->read_addr points to.
CVE-2021-3608
#
1//////////////////////////////////////////////////////////////////////
2//XENO: Structure that isn't completely initialized
3//////////////////////////////////////////////////////////////////////
4
5typedef struct PvrdmaRing {
6 char name[MAX_RING_NAME_SZ];
7 PCIDevice *dev;
8 uint32_t max_elems;
9 size_t elem_sz;
10 PvrdmaRingState *ring_state; /* used only for unmap */
11 int npages;
12 void **pages;
13} PvrdmaRing;
14
15//////////////////////////////////////////////////////////////////////
16//XENO: Part of the path where incomplete initialized occurs AND uninitialized usage occurs
17//////////////////////////////////////////////////////////////////////
18
19//XENO: Assume dir_addr and num_pages are ACID
20//XENO: And assume that if the 2nd argument to rdma_pci_dma_map() is ACID
21//XENO: then it's basically just mapping more ACID data/structs into memory
22static int init_dev_ring(PvrdmaRing *ring, PvrdmaRingState **ring_state,
23 const char *name, PCIDevice *pci_dev,
24 dma_addr_t dir_addr, uint32_t num_pages)
25{
26 uint64_t *dir, *tbl;
27 int rc = 0;
28
29 dir = rdma_pci_dma_map(pci_dev, dir_addr, TARGET_PAGE_SIZE);
30 if (!dir) {
31 rdma_error_report("Failed to map to page directory (ring %s)", name);
32 rc = -ENOMEM;
33 goto out;
34 }
35 tbl = rdma_pci_dma_map(pci_dev, dir[0], TARGET_PAGE_SIZE);
36 if (!tbl) {
37 rdma_error_report("Failed to map to page table (ring %s)", name);
38 rc = -ENOMEM;
39 goto out_free_dir;
40 }
41
42 *ring_state = rdma_pci_dma_map(pci_dev, tbl[0], TARGET_PAGE_SIZE);
43 if (!*ring_state) {
44 rdma_error_report("Failed to map to ring state (ring %s)", name);
45 rc = -ENOMEM;
46 goto out_free_tbl;
47 }
48 /* RX ring is the second */
49 (*ring_state)++;
50 rc = pvrdma_ring_init(ring, name, pci_dev,
51 (PvrdmaRingState *)*ring_state,
52 (num_pages - 1) * TARGET_PAGE_SIZE /
53 sizeof(struct pvrdma_cqne),
54 sizeof(struct pvrdma_cqne),
55 (dma_addr_t *)&tbl[1], (dma_addr_t)num_pages - 1);
56 if (rc) {
57 rc = -ENOMEM;
58 goto out_free_ring_state;
59 }
60
61 goto out_free_tbl;
62
63out_free_ring_state:
64 rdma_pci_dma_unmap(pci_dev, *ring_state, TARGET_PAGE_SIZE);
65
66out_free_tbl:
67 rdma_pci_dma_unmap(pci_dev, tbl, TARGET_PAGE_SIZE);
68
69out_free_dir:
70 rdma_pci_dma_unmap(pci_dev, dir, TARGET_PAGE_SIZE);
71
72out:
73 return rc;
74}
75
76int pvrdma_ring_init(PvrdmaRing *ring, const char *name, PCIDevice *dev,
77 PvrdmaRingState *ring_state, uint32_t max_elems,
78 size_t elem_sz, dma_addr_t *tbl, uint32_t npages)
79{
80 int i;
81 int rc = 0;
82
83 pstrcpy(ring->name, MAX_RING_NAME_SZ, name);
84 ring->dev = dev;
85 ring->ring_state = ring_state;
86 ring->max_elems = max_elems;
87 ring->elem_sz = elem_sz;
88 /* TODO: Give a moment to think if we want to redo driver settings
89 qatomic_set(&ring->ring_state->prod_tail, 0);
90 qatomic_set(&ring->ring_state->cons_head, 0);
91 */
92 ring->npages = npages;
93 ring->pages = g_malloc(npages * sizeof(void *)); //XENO: array of npages pointers
94
95 for (i = 0; i < npages; i++) {
96 if (!tbl[i]) {
97 rdma_error_report("npages=%d but tbl[%d] is NULL", npages, i);
98 continue;
99 }
100
101 ring->pages[i] = rdma_pci_dma_map(dev, tbl[i], TARGET_PAGE_SIZE);
102 if (!ring->pages[i]) {
103 rc = -ENOMEM;
104 rdma_error_report("Failed to map to page %d in ring %s", i, name);
105 goto out_free;
106 }
107 memset(ring->pages[i], 0, TARGET_PAGE_SIZE);
108 }
109
110 goto out;
111
112out_free:
113 while (i--) {
114 rdma_pci_dma_unmap(dev, ring->pages[i], TARGET_PAGE_SIZE);
115 }
116 g_free(ring->pages);
117
118out:
119 return rc;
120}
An attacker could potentially control dir_addr and num_pages. This entails that at line 29, dir would also be ACID, and at like 35 and 42, tbl and ring_state would also be ACID respectively. Then we can observe that at line 50 pvrdma_ring_init gets invoked passing ring_state as the 4th argument, (num_pages - 1) * TARGET_PAGE_SIZE / sizeof(struct pvrdma_cqne) as the 5th argument &tbl[1] as the 7th argument and (dma_addr_t)num_pages - 1 as the 8th argument – all ACID.
In pvrdma_ring_init() we can note that at line 92, ring->npages is initialized to the 8th argument npages which is ACID, to then proceed to initialize ring->pages using malloc. Then a for loop at line 95 iterates over npages. If we remember, tbl is the 7th argument of this function and is also ACID, therefore an attacker should control the values pointed to by it.
In particular, we can observe that on line 101, ring->pages[i] is attempted to be initialized witht the result of the function rdma_pci_dma_map, passing as its second parameter tbl[i] which is ACID as previously mentioned. If this function fails, due to an invalid value held at tbl[i], which could be conditioned based on an arbitrary i product of an invalid npages (ACID), then control flow will pivot to out_free at line 112.
Here a while loop starting from the current value of i will be processed, decrementing the value of i for each iteration and the function rdma_pci_dma_unmap will be attempted to be invoked, passing an uninitialized ring->pages[i] as its second argument.
If an attacker could groom the heap so that the statement ring->pages = g_malloc(npages * sizeof(void *)) would set the value of ring->pages with an already used memory region populated with attacker-controlled data, assuming that the attacker may have some sort of information disclosure capability to set ring->pages[i] to some arbitrary value, this would lead to an arbitrary-free primitive.
CVE-2022-26721
#
1 //XENO: CVE-2022-26721 pseudocode
2 xpc_object_t content = xpc_dictionary_get_value(req, "source");
3 size_t count = xpc_array_get_count(content); //XENO: count SACI, based on number of array elements sent
4 size_t *descriptors = malloc(sizeof(size_t) * 4 * count);
5 size_t *accessBeginPointer = &descriptors[count * 0],
6 *accessDataLength = &descriptors[count * 1],
7 *mappedBaseAddress = &descriptors[count * 2],
8 *mappedLength = &descriptors[count * 3];
9
10 for(size_t i = 0; i < count; i++) {
11 accessBeginPointer[i] = accessDataLength[i] =
12 mappedBaseAddress[i] = mappedLength[i] = 0;
13
14 xpc_object_t chunk = xpc_array_get_value(content, i);
15
16 if(xpc_get_type(chunk) == XPC_TYPE_DATA) { /*...*/ }
17 else if(xpc_get_type(chunk) == XPC_TYPE_SHMEM) {
18 xpc_object_t map = xpc_array_get_value(chunk, 0);
19 size_t offset = min(xpc_array_get_uint64(chunk, 1), 0xFFF), //XENO: offset SACI
20 size = xpc_array_get_uint64(chunk, 2); //XENO: size ACID
21
22 size_t mapped_address;
23 size_t mapped_size = xpc_shmem_map(map, &mapped_address); //XENO: mapped_size ACID
24
25 //XENO: Sanity check to avoid CVE-2021-30724 integer underflow
26 if(mapped_size < offset) break;
27
28 size = min(size, mapped_size - offset);
29 // ...
30 }
31 }
32 // ...
33 // cleanup
34 for(size_t index = 0; index < count; index++) {
35 if(mappedLength[index]) {
36 munmap(
37 mappedBaseAddress[index],
38 mappedLength[index]
39 );
40 }
41 }
42 free(descriptors);
We can observe that on line 3, count is the result of the number of arrays from the XPC dictionary. An attacker can control the XPC message, so therefore should be able to control the value of count.
Subsequently, we can observe that descriptors is set to a buffer allocated with malloc at line 4, and that accessBeginPointer, accessDataLength, mappedBaseAddress and mappedLength are all being initialized as pointers pointing to different offsets to the previously allocated buffer of descriptors. Then at line 10, we encounter a for-loop that iterates over count, this is an ACID loop-counter driven for-loop.
We can see that for the current i the values of accessBeginPointer, accessDataLength, mappedBaseAddress and mappedLength are set to 0. Then at line 14, a specific XPC object is fetched from the XPC message, and if its type is of type XPC_TYPE_SHMEM as checked at line 17, then it will fetch a few members from that object. At line 19, a size_t value is retrieved and set to offset, then at line 23 a shared memory object is retrieved and mapped to mapped_address, while its size its stored in mapped_size. Since an attacker would have to map this shared memory region, it ultimately also controls its size, making mapped_size ACID.
Then at line 26, there is an if statement checking if the mapped_size value is lower than offset. Since an attacker could ultimately control both of these values, it can satisfy the condition to reach the break statement, and quit the for-loop. After this, another for-loop will be executed, which aslo iterates over count. For every iteration munmap() will be called with mappedBaseAddress[index] and mappedLength[index] as its parameters.
Since this for loop iterates over count, if count would be 3, and we were able to trigger the break statement on the first iteration, with i as 0, this will lead to a situation in which some of the munmap invokations in the clean up for-loop, will be called on uninitialized memory for index values that do not overlap the addresses of already zero-initialized accessBeginPointer, accessDataLength, mappedBaseAddress and mappedLength instances in descriptors.
#
Uninitialized Data Access
Also known as UDA, Its when memory isn’t initialized, and it takes on whatever values happen to already be in that memory location. This becomes a vulnerability when leftover values/data in memory can be attacker-controlled.
Common Causes #
- Not initializing local variables at declaration which later are accessed.
- Not initializing heap data at allocation time, which later are accessed.
- Only partially initializing structs and objects, which later non-initialized members are accessed.
- Accidental failure to initialize variables down an uncommon control-flow path
- Eg: passsing a pointer to an uninitialized struct to a function, and expecting it to perform initialization, but then it returns early before any initialization occurs.
Note: Fuzzers and specific compiler instrumentation can assist to find and mitigate this type of vulnerabilities. In particular
MemorySanitizeris the adequate sanitizer in charge to detect uninitialized variable usage in fuzzers. In addition, compiler flags such as-ftrivial-auto-var-init=patternor-ftrivial-auto-var-init=zerocan force the initialization of variables and help mitigate these vulnerabiltities.
Examples #
CVE-2022-1809 #
1//////////////////////////////////////////////////////////////////////
2//XENO: Structure that isn't completely initialized
3//////////////////////////////////////////////////////////////////////
4/* vtables */
5typedef struct {
6 RAnal *anal;
7 RAnalCPPABI abi;
8 ut8 word_size;
9 bool (*read_addr) (RAnal *anal, ut64 addr, ut64 *buf);
10} RVTableContext;
11
12//////////////////////////////////////////////////////////////////////
13//XENO: Part of the path where incomplete initialized occurs
14//////////////////////////////////////////////////////////////////////
15
16//XENO: assume the following fields are ACID based on a malicious ACID binary under analysis:
17//XENO: anal->config->bits, anal->cur->arch
18
19R_API bool r_anal_vtable_begin(RAnal *anal, RVTableContext *context) {
20 context->anal = anal;
21 context->abi = anal->cxxabi;
22 context->word_size = (ut8) (anal->config->bits / 8);
23 const bool is_arm = anal->cur->arch && r_str_startswith (anal->cur->arch, "arm");
24 if (is_arm && context->word_size < 4) {
25 context->word_size = 4;
26 }
27 const bool be = anal->config->big_endian;
28 switch (context->word_size) {
29 case 1:
30 context->read_addr = be? vtable_read_addr_be8 : vtable_read_addr_le8;
31 break;
32 case 2:
33 context->read_addr = be? vtable_read_addr_be16 : vtable_read_addr_le16;
34 break;
35 case 4:
36 context->read_addr = be? vtable_read_addr_be32 : vtable_read_addr_le32;
37 break;
38 case 8:
39 context->read_addr = be? vtable_read_addr_be64 : vtable_read_addr_le64;
40 break;
41 default:
42 return false;
43 }
44 return true;
45}
46
47//////////////////////////////////////////////////////////////////////
48//XENO: Part of the path where uninitialized access occurs eventually
49//////////////////////////////////////////////////////////////////////
50
51
52R_API void r_anal_list_vtables(RAnal *anal, int rad) {
53 RVTableContext context;
54 r_anal_vtable_begin (anal, &context);
55
56 const char *noMethodName = "No Name found";
57 RVTableMethodInfo *curMethod;
58 RListIter *vtableIter;
59 RVTableInfo *table;
60
61 RList *vtables = r_anal_vtable_search (&context);
62//XENO: snip
63}
64
65R_API RList *r_anal_vtable_search(RVTableContext *context) {
66 RAnal *anal = context->anal;
67 if (!anal) {
68 return NULL;
69 }
70
71 RList *vtables = r_list_newf ((RListFree)r_anal_vtable_info_free);
72 if (!vtables) {
73 return NULL;
74 }
75
76 RList *sections = anal->binb.get_sections (anal->binb.bin);
77 if (!sections) {
78 r_list_free (vtables);
79 return NULL;
80 }
81
82 r_cons_break_push (NULL, NULL);
83
84 RListIter *iter;
85 RBinSection *section;
86 r_list_foreach (sections, iter, section) {
87 if (r_cons_is_breaked ()) {
88 break;
89 }
90
91 if (!vtable_section_can_contain_vtables (section)) {
92 continue;
93 }
94
95 ut64 startAddress = section->vaddr;
96 ut64 endAddress = startAddress + (section->vsize) - context->word_size;
97 ut64 ss = endAddress - startAddress;
98 if (ss > ST32_MAX) {
99 break;
100 }
101 while (startAddress <= endAddress) {
102 if (r_cons_is_breaked ()) {
103 break;
104 }
105 if (!anal->iob.is_valid_offset (anal->iob.io, startAddress, 0)) {
106 break;
107 }
108
109 if (vtable_is_addr_vtable_start (context, section, startAddress)) {
110 RVTableInfo *vtable = r_anal_vtable_parse_at (context, startAddress);
111 if (vtable) {
112 r_list_append (vtables, vtable);
113 ut64 size = r_anal_vtable_info_get_size (context, vtable);
114 if (size > 0) {
115 startAddress += size;
116 continue;
117 }
118 }
119 }
120 startAddress += context->word_size;
121 }
122 }
123//XENO: snip
124}
125
126static bool vtable_is_addr_vtable_start(RVTableContext *context, RBinSection *section, ut64 curAddress) {
127 if (context->abi == R_ANAL_CPP_ABI_MSVC) {
128 return vtable_is_addr_vtable_start_msvc (context, curAddress);
129 }
130 if (context->abi == R_ANAL_CPP_ABI_ITANIUM) {
131 return vtable_is_addr_vtable_start_itanium (context, section, curAddress);
132 }
133 r_return_val_if_reached (false);
134 return false;
135}
136
137static bool vtable_is_addr_vtable_start_msvc(RVTableContext *context, ut64 curAddress) {
138 RAnalRef *xref;
139 RListIter *xrefIter;
140
141 if (!curAddress || curAddress == UT64_MAX) {
142 return false;
143 }
144 if (curAddress && !vtable_is_value_in_text_section (context, curAddress, NULL)) {
145 return false;
146 }
147//XENO: snip
148}
149
150static bool vtable_is_value_in_text_section(RVTableContext *context, ut64 curAddress, ut64 *value) {
151 //value at the current address
152 ut64 curAddressValue;
153 if (!context->read_addr (context->anal, curAddress, &curAddressValue)) {
154 return false;
155 }
156 //if the value is in text section
157 bool ret = vtable_addr_in_text_section (context, curAddressValue);
158 if (value) {
159 *value = curAddressValue;
160 }
161 return ret;
162}
Before proceeding further, we need to acknowledge the members of the RVTableContext struct, in particular the function pointer read_addr. After noting this, we can start our analysis at r_anal_list_vtables in which we can see how a RVTableContext object stored at context is declared but not initialized, although its immediately passed to the r_anal_vtable_begin function to initialize it.
At r_anal_vtable_begin we see that various fields are initialized for context. We should remmeber that anal->config->bits and anal->cur->arch are ACID, meaning that an attacker can potentially control the value of context->word_size and is_arm. Controlling these two variables, an attacker could craft its way into the default case in the subsequent switch case, in which we can observe that context->read_addr fails to be initialized, and the funciton simply returns false.
Its important to note that at r_anal_list_vtables this return value its failed to be validated. Moving down the data flow, eventually we can spot that at line 153 in vtable_is_value_in_text_section, context->read_addr its invoked without it previously being initialized, potentially leading to an arbitrary PC control primitive.
An attacker would have to carefully groom the stack by calling other functions prior to vtable_is_value_in_text_section, in which may gain to set some ACID value in the stack at the same offset where context->read_addr points to.
CVE-2021-3608 #
1//////////////////////////////////////////////////////////////////////
2//XENO: Structure that isn't completely initialized
3//////////////////////////////////////////////////////////////////////
4
5typedef struct PvrdmaRing {
6 char name[MAX_RING_NAME_SZ];
7 PCIDevice *dev;
8 uint32_t max_elems;
9 size_t elem_sz;
10 PvrdmaRingState *ring_state; /* used only for unmap */
11 int npages;
12 void **pages;
13} PvrdmaRing;
14
15//////////////////////////////////////////////////////////////////////
16//XENO: Part of the path where incomplete initialized occurs AND uninitialized usage occurs
17//////////////////////////////////////////////////////////////////////
18
19//XENO: Assume dir_addr and num_pages are ACID
20//XENO: And assume that if the 2nd argument to rdma_pci_dma_map() is ACID
21//XENO: then it's basically just mapping more ACID data/structs into memory
22static int init_dev_ring(PvrdmaRing *ring, PvrdmaRingState **ring_state,
23 const char *name, PCIDevice *pci_dev,
24 dma_addr_t dir_addr, uint32_t num_pages)
25{
26 uint64_t *dir, *tbl;
27 int rc = 0;
28
29 dir = rdma_pci_dma_map(pci_dev, dir_addr, TARGET_PAGE_SIZE);
30 if (!dir) {
31 rdma_error_report("Failed to map to page directory (ring %s)", name);
32 rc = -ENOMEM;
33 goto out;
34 }
35 tbl = rdma_pci_dma_map(pci_dev, dir[0], TARGET_PAGE_SIZE);
36 if (!tbl) {
37 rdma_error_report("Failed to map to page table (ring %s)", name);
38 rc = -ENOMEM;
39 goto out_free_dir;
40 }
41
42 *ring_state = rdma_pci_dma_map(pci_dev, tbl[0], TARGET_PAGE_SIZE);
43 if (!*ring_state) {
44 rdma_error_report("Failed to map to ring state (ring %s)", name);
45 rc = -ENOMEM;
46 goto out_free_tbl;
47 }
48 /* RX ring is the second */
49 (*ring_state)++;
50 rc = pvrdma_ring_init(ring, name, pci_dev,
51 (PvrdmaRingState *)*ring_state,
52 (num_pages - 1) * TARGET_PAGE_SIZE /
53 sizeof(struct pvrdma_cqne),
54 sizeof(struct pvrdma_cqne),
55 (dma_addr_t *)&tbl[1], (dma_addr_t)num_pages - 1);
56 if (rc) {
57 rc = -ENOMEM;
58 goto out_free_ring_state;
59 }
60
61 goto out_free_tbl;
62
63out_free_ring_state:
64 rdma_pci_dma_unmap(pci_dev, *ring_state, TARGET_PAGE_SIZE);
65
66out_free_tbl:
67 rdma_pci_dma_unmap(pci_dev, tbl, TARGET_PAGE_SIZE);
68
69out_free_dir:
70 rdma_pci_dma_unmap(pci_dev, dir, TARGET_PAGE_SIZE);
71
72out:
73 return rc;
74}
75
76int pvrdma_ring_init(PvrdmaRing *ring, const char *name, PCIDevice *dev,
77 PvrdmaRingState *ring_state, uint32_t max_elems,
78 size_t elem_sz, dma_addr_t *tbl, uint32_t npages)
79{
80 int i;
81 int rc = 0;
82
83 pstrcpy(ring->name, MAX_RING_NAME_SZ, name);
84 ring->dev = dev;
85 ring->ring_state = ring_state;
86 ring->max_elems = max_elems;
87 ring->elem_sz = elem_sz;
88 /* TODO: Give a moment to think if we want to redo driver settings
89 qatomic_set(&ring->ring_state->prod_tail, 0);
90 qatomic_set(&ring->ring_state->cons_head, 0);
91 */
92 ring->npages = npages;
93 ring->pages = g_malloc(npages * sizeof(void *)); //XENO: array of npages pointers
94
95 for (i = 0; i < npages; i++) {
96 if (!tbl[i]) {
97 rdma_error_report("npages=%d but tbl[%d] is NULL", npages, i);
98 continue;
99 }
100
101 ring->pages[i] = rdma_pci_dma_map(dev, tbl[i], TARGET_PAGE_SIZE);
102 if (!ring->pages[i]) {
103 rc = -ENOMEM;
104 rdma_error_report("Failed to map to page %d in ring %s", i, name);
105 goto out_free;
106 }
107 memset(ring->pages[i], 0, TARGET_PAGE_SIZE);
108 }
109
110 goto out;
111
112out_free:
113 while (i--) {
114 rdma_pci_dma_unmap(dev, ring->pages[i], TARGET_PAGE_SIZE);
115 }
116 g_free(ring->pages);
117
118out:
119 return rc;
120}
An attacker could potentially control dir_addr and num_pages. This entails that at line 29, dir would also be ACID, and at like 35 and 42, tbl and ring_state would also be ACID respectively. Then we can observe that at line 50 pvrdma_ring_init gets invoked passing ring_state as the 4th argument, (num_pages - 1) * TARGET_PAGE_SIZE / sizeof(struct pvrdma_cqne) as the 5th argument &tbl[1] as the 7th argument and (dma_addr_t)num_pages - 1 as the 8th argument – all ACID.
In pvrdma_ring_init() we can note that at line 92, ring->npages is initialized to the 8th argument npages which is ACID, to then proceed to initialize ring->pages using malloc. Then a for loop at line 95 iterates over npages. If we remember, tbl is the 7th argument of this function and is also ACID, therefore an attacker should control the values pointed to by it.
In particular, we can observe that on line 101, ring->pages[i] is attempted to be initialized witht the result of the function rdma_pci_dma_map, passing as its second parameter tbl[i] which is ACID as previously mentioned. If this function fails, due to an invalid value held at tbl[i], which could be conditioned based on an arbitrary i product of an invalid npages (ACID), then control flow will pivot to out_free at line 112.
Here a while loop starting from the current value of i will be processed, decrementing the value of i for each iteration and the function rdma_pci_dma_unmap will be attempted to be invoked, passing an uninitialized ring->pages[i] as its second argument.
If an attacker could groom the heap so that the statement ring->pages = g_malloc(npages * sizeof(void *)) would set the value of ring->pages with an already used memory region populated with attacker-controlled data, assuming that the attacker may have some sort of information disclosure capability to set ring->pages[i] to some arbitrary value, this would lead to an arbitrary-free primitive.
CVE-2022-26721 #
1 //XENO: CVE-2022-26721 pseudocode
2 xpc_object_t content = xpc_dictionary_get_value(req, "source");
3 size_t count = xpc_array_get_count(content); //XENO: count SACI, based on number of array elements sent
4 size_t *descriptors = malloc(sizeof(size_t) * 4 * count);
5 size_t *accessBeginPointer = &descriptors[count * 0],
6 *accessDataLength = &descriptors[count * 1],
7 *mappedBaseAddress = &descriptors[count * 2],
8 *mappedLength = &descriptors[count * 3];
9
10 for(size_t i = 0; i < count; i++) {
11 accessBeginPointer[i] = accessDataLength[i] =
12 mappedBaseAddress[i] = mappedLength[i] = 0;
13
14 xpc_object_t chunk = xpc_array_get_value(content, i);
15
16 if(xpc_get_type(chunk) == XPC_TYPE_DATA) { /*...*/ }
17 else if(xpc_get_type(chunk) == XPC_TYPE_SHMEM) {
18 xpc_object_t map = xpc_array_get_value(chunk, 0);
19 size_t offset = min(xpc_array_get_uint64(chunk, 1), 0xFFF), //XENO: offset SACI
20 size = xpc_array_get_uint64(chunk, 2); //XENO: size ACID
21
22 size_t mapped_address;
23 size_t mapped_size = xpc_shmem_map(map, &mapped_address); //XENO: mapped_size ACID
24
25 //XENO: Sanity check to avoid CVE-2021-30724 integer underflow
26 if(mapped_size < offset) break;
27
28 size = min(size, mapped_size - offset);
29 // ...
30 }
31 }
32 // ...
33 // cleanup
34 for(size_t index = 0; index < count; index++) {
35 if(mappedLength[index]) {
36 munmap(
37 mappedBaseAddress[index],
38 mappedLength[index]
39 );
40 }
41 }
42 free(descriptors);
We can observe that on line 3, count is the result of the number of arrays from the XPC dictionary. An attacker can control the XPC message, so therefore should be able to control the value of count.
Subsequently, we can observe that descriptors is set to a buffer allocated with malloc at line 4, and that accessBeginPointer, accessDataLength, mappedBaseAddress and mappedLength are all being initialized as pointers pointing to different offsets to the previously allocated buffer of descriptors. Then at line 10, we encounter a for-loop that iterates over count, this is an ACID loop-counter driven for-loop.
We can see that for the current i the values of accessBeginPointer, accessDataLength, mappedBaseAddress and mappedLength are set to 0. Then at line 14, a specific XPC object is fetched from the XPC message, and if its type is of type XPC_TYPE_SHMEM as checked at line 17, then it will fetch a few members from that object. At line 19, a size_t value is retrieved and set to offset, then at line 23 a shared memory object is retrieved and mapped to mapped_address, while its size its stored in mapped_size. Since an attacker would have to map this shared memory region, it ultimately also controls its size, making mapped_size ACID.
Then at line 26, there is an if statement checking if the mapped_size value is lower than offset. Since an attacker could ultimately control both of these values, it can satisfy the condition to reach the break statement, and quit the for-loop. After this, another for-loop will be executed, which aslo iterates over count. For every iteration munmap() will be called with mappedBaseAddress[index] and mappedLength[index] as its parameters.
Since this for loop iterates over count, if count would be 3, and we were able to trigger the break statement on the first iteration, with i as 0, this will lead to a situation in which some of the munmap invokations in the clean up for-loop, will be called on uninitialized memory for index values that do not overlap the addresses of already zero-initialized accessBeginPointer, accessDataLength, mappedBaseAddress and mappedLength instances in descriptors.
Information Disclosure
Information disclosure can manifest when sensitive information or the layout of memory that was not meant to be access, its disclosed product of a vulnerabilty. The information returned can be of use to an attacker to disclose pointers to be able to bypass ASLR, to other more sensitive information such as cryptographic keys.
Common Root Causes
#
The root causes for these type of vulnerabiltiies are the same as linear and non-linear overflows, that instead of writing out-of-bounds, can read out-of-bounds.
An important caveat of this type of vulenerabilities is that not all out-of-bound reads would manifest as information disclosure vulnerabilities, as for an info-leak to take place, OOB read data must be returned back to the attacker, where in many OOB read scenarios this is not the case.
These types of vulnerabilties sometimes are intrinsic as the example we will be looking at below, but often times can be manufactured with an OOB-write primitive.
Example
#
CVE-2021-22925
#
1//XENO: data ACID string from CLI
2//XENO: Example: "curl telnet://example.com -tNEW_ENV=FOO,AAAA"
3//XENO: data would be "FOO,AAAA"
4static void suboption(struct Curl_easy *data)
5{
6 struct curl_slist *v;
7 unsigned char temp[2048];
8 ssize_t bytes_written;
9 size_t len;
10 int err;
11 char varname[128] = "";
12 char varval[128] = "";
13 struct TELNET *tn = data->req.p.telnet;
14 struct connectdata *conn = data->conn;
15
16//XENO: snip
17
18 case CURL_TELOPT_NEW_ENVIRON:
19 msnprintf((char *)temp, sizeof(temp),
20 "%c%c%c%c", CURL_IAC, CURL_SB, CURL_TELOPT_NEW_ENVIRON,
21 CURL_TELQUAL_IS);
22 len = 4;
23
24 for(v = tn->telnet_vars; v; v = v->next) {
25 size_t tmplen = (strlen(v->data) + 1);
26 /* Add the variable only if it fits */
27 if(len + tmplen < (int)sizeof(temp)-6) {
28 if(sscanf(v->data, "%127[^,],%127s", varname, varval)) {
29 msnprintf((char *)&temp[len], sizeof(temp) - len,
30 "%c%s%c%s", CURL_NEW_ENV_VAR, varname,
31 CURL_NEW_ENV_VALUE, varval);
32 len += tmplen;
33 }
34 }
35 }
36 msnprintf((char *)&temp[len], sizeof(temp) - len,
37 "%c%c", CURL_IAC, CURL_SE);
38 len += 2;
39 bytes_written = swrite(conn->sock[FIRSTSOCKET], temp, len);
40 if(bytes_written < 0) {
41 err = SOCKERRNO;
42 failf(data,"Sending data failed (%d)",err);
43 }
44 printsub(data, '>', &temp[2], len-2);
45 break;
46//XENO: snip
47}
In this example, we can observe a local stack buffer of size 2048 called temp. Not that this buffer is indeed uninitialized.
We can then spot the for-loop at line 24 which iterates over the telnet environment variables specified witht he command -t. Then at line 25 we spot a tmplen variable holding the result of strlen(v->data) + 1. We can then check that at line 27 there is a sanity check to ensure the that the value of len + templen does not go out-of-bounds, and then it calls sscanf at line 28.
Is not entirely important to know all the details of the specified fromat string passed to sscanf, only that at most 127 characters + a comma, + 127 characters + the null byte should be obtain. Thats essentially 256 characters in total at most.
However, if onle looks closely after the sscanf and the msnprintf calls, the len sentinel is added the value of tmplen, which can be much larger than 256 characters. At line 39, depending of how carefully the attacker crafed the commandline parameters and the number of parameters supplied, since temp is uninitialized, this could lead to sending back to the attacker via swrite ranges of the buffer temp that are not initialized, and could potentially be data in the stack.
#
Information Disclosure
Information disclosure can manifest when sensitive information or the layout of memory that was not meant to be access, its disclosed product of a vulnerabilty. The information returned can be of use to an attacker to disclose pointers to be able to bypass ASLR, to other more sensitive information such as cryptographic keys.
Common Root Causes #
The root causes for these type of vulnerabiltiies are the same as linear and non-linear overflows, that instead of writing out-of-bounds, can read out-of-bounds.
An important caveat of this type of vulenerabilities is that not all out-of-bound reads would manifest as information disclosure vulnerabilities, as for an info-leak to take place, OOB read data must be returned back to the attacker, where in many OOB read scenarios this is not the case.
These types of vulnerabilties sometimes are intrinsic as the example we will be looking at below, but often times can be manufactured with an OOB-write primitive.
Example #
CVE-2021-22925 #
1//XENO: data ACID string from CLI
2//XENO: Example: "curl telnet://example.com -tNEW_ENV=FOO,AAAA"
3//XENO: data would be "FOO,AAAA"
4static void suboption(struct Curl_easy *data)
5{
6 struct curl_slist *v;
7 unsigned char temp[2048];
8 ssize_t bytes_written;
9 size_t len;
10 int err;
11 char varname[128] = "";
12 char varval[128] = "";
13 struct TELNET *tn = data->req.p.telnet;
14 struct connectdata *conn = data->conn;
15
16//XENO: snip
17
18 case CURL_TELOPT_NEW_ENVIRON:
19 msnprintf((char *)temp, sizeof(temp),
20 "%c%c%c%c", CURL_IAC, CURL_SB, CURL_TELOPT_NEW_ENVIRON,
21 CURL_TELQUAL_IS);
22 len = 4;
23
24 for(v = tn->telnet_vars; v; v = v->next) {
25 size_t tmplen = (strlen(v->data) + 1);
26 /* Add the variable only if it fits */
27 if(len + tmplen < (int)sizeof(temp)-6) {
28 if(sscanf(v->data, "%127[^,],%127s", varname, varval)) {
29 msnprintf((char *)&temp[len], sizeof(temp) - len,
30 "%c%s%c%s", CURL_NEW_ENV_VAR, varname,
31 CURL_NEW_ENV_VALUE, varval);
32 len += tmplen;
33 }
34 }
35 }
36 msnprintf((char *)&temp[len], sizeof(temp) - len,
37 "%c%c", CURL_IAC, CURL_SE);
38 len += 2;
39 bytes_written = swrite(conn->sock[FIRSTSOCKET], temp, len);
40 if(bytes_written < 0) {
41 err = SOCKERRNO;
42 failf(data,"Sending data failed (%d)",err);
43 }
44 printsub(data, '>', &temp[2], len-2);
45 break;
46//XENO: snip
47}
In this example, we can observe a local stack buffer of size 2048 called temp. Not that this buffer is indeed uninitialized.
We can then spot the for-loop at line 24 which iterates over the telnet environment variables specified witht he command -t. Then at line 25 we spot a tmplen variable holding the result of strlen(v->data) + 1. We can then check that at line 27 there is a sanity check to ensure the that the value of len + templen does not go out-of-bounds, and then it calls sscanf at line 28.
Is not entirely important to know all the details of the specified fromat string passed to sscanf, only that at most 127 characters + a comma, + 127 characters + the null byte should be obtain. Thats essentially 256 characters in total at most.
However, if onle looks closely after the sscanf and the msnprintf calls, the len sentinel is added the value of tmplen, which can be much larger than 256 characters. At line 39, depending of how carefully the attacker crafed the commandline parameters and the number of parameters supplied, since temp is uninitialized, this could lead to sending back to the attacker via swrite ranges of the buffer temp that are not initialized, and could potentially be data in the stack.
Race Conditions
A race condition is where the system’s systantive behavior is dependent on the sequence or timing of other uncontrollable events. This becomes a security vulnerability when the system’s behaviour is dependent on the sequence or timing of attacker-controllable events, particularly in the handling of shared resources.
Within the set of race-condition behaviours we can differentiate two most common cases:
- Double-fetch conditions: When the system fetches an object or variable twice in different contexts/time spans that the attacker can manipulate or impact
- Time-of-check-time-of-use (TOCTOU): When the system fetches an object or variable several times in which the first fetches usually involves sanity checks of the subject item, while subsequent fetches asume the item is already checked and can be free to use. An attacker may be able to impact the sequence of events to break assumptions and impact system integrity.
Differences
#
-
Race-Conditions: In theory a race condition does not need to have several fetches, as sometimes by winning a specific race condition, (say by modifying a shared resource once, before some other processing takes place on that same shared resource) may be enough to cause some undefined behaviour.
-
Double-Fetches and TOCTOUs: On the other hand, double-fetches and TOCTOUs involve several accesses to the same resource.
- TOCTOU: When explicit sanity checks are applied to the processing of a shared resource before a subsequent fetch –violating any integrity assumtions previously preconceived on the state, content or value stored in this shared resource.
- Double-fetch: When there are no sanity checks in place, simply the content, state or value stored in a shared resource can be changed on a subsequent fetch, violating any consistency assumptions on the value of this shared resource.
Common Causes
#
- Shared Resources
- Volatile memory (DRAM)
- Non-volatile memory (SPI Flash, EEPROM, Filesystem, … etc)
- Parallelism
- Multithreading
- 2+ clients interacting with the same server
- 2+ tabs executing JavaScript in the same browser
- 2+ userspace threads/applications executing system calls in the same OS
- 2+ OS running in the same hypervisor
- Multiprocessing
- 2+ CPU cores executing in parallel in the same System-On-A-Chip (SoC)
- 2+ chips on a shared bus (PCIe access to central DRAM)
How Race Conditions are usually handled
#
- Mutual Exclusion
- Locks
- Mutexes
- Semaphores
Examples
#
CVE-2021-4207
#
1//XENO: cursor points to Guest OS shared memory, and is thus ACID
2static QEMUCursor *qxl_cursor(PCIQXLDevice *qxl, QXLCursor *cursor,
3 uint32_t group_id)
4{
5 QEMUCursor *c;
6 uint8_t *and_mask, *xor_mask;
7 size_t size;
8
9 c = cursor_alloc(cursor->header.width, cursor->header.height);
10 c->hot_x = cursor->header.hot_spot_x;
11 c->hot_y = cursor->header.hot_spot_y;
12 switch (cursor->header.type) {
13 case SPICE_CURSOR_TYPE_MONO:
14 /* Assume that the full cursor is available in a single chunk. */
15 size = 2 * cursor_get_mono_bpl(c) * c->height;
16 if (size != cursor->data_size) {
17 fprintf(stderr, "%s: bad monochrome cursor %ux%u with size %u\n",
18 __func__, c->width, c->height, cursor->data_size);
19 goto fail;
20 }
21 and_mask = cursor->chunk.data;
22 xor_mask = and_mask + cursor_get_mono_bpl(c) * c->height;
23 cursor_set_mono(c, 0xffffff, 0x000000, xor_mask, 1, and_mask);
24 if (qxl->debug > 2) {
25 cursor_print_ascii_art(c, "qxl/mono");
26 }
27 break;
28 case SPICE_CURSOR_TYPE_ALPHA:
29 size = sizeof(uint32_t) * cursor->header.width * cursor->header.height;
30 qxl_unpack_chunks(c->data, size, qxl, &cursor->chunk, group_id);
31 if (qxl->debug > 2) {
32 cursor_print_ascii_art(c, "qxl/alpha");
33 }
34 break;
35 default:
36 fprintf(stderr, "%s: not implemented: type %d\n",
37 __func__, cursor->header.type);
38 goto fail;
39 }
40 return c;
41
42fail:
43 cursor_put(c);
44 return NULL;
45}
46
47QEMUCursor *cursor_alloc(int width, int height)
48{
49 QEMUCursor *c;
50 int datasize = width * height * sizeof(uint32_t);
51
52 c = g_malloc0(sizeof(QEMUCursor) + datasize);
53 c->width = width;
54 c->height = height;
55 c->refcount = 1;
56 return c;
57}
58
59static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
60 QXLDataChunk *chunk, uint32_t group_id)
61{
62 uint32_t max_chunks = 32;
63 size_t offset = 0;
64 size_t bytes;
65
66 for (;;) {
67 bytes = MIN(size - offset, chunk->data_size);
68 memcpy(dest + offset, chunk->data, bytes);
69 offset += bytes;
70 if (offset == size) {
71 return;
72 }
73 chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id);
74 if (!chunk) {
75 return;
76 }
77 max_chunks--;
78 if (max_chunks == 0) {
79 return;
80 }
81 }
82}
At line 9 we can see that cursor->header.width and cursor->header.height are being fetched from shared memory to allocate a QEMUCursor object via cursor_alloc.
Furthermore, at line 12 there’s a switch statement on cursor->header.type which is also held in shared memory pointed to by cursor, therefore an attacker would be able to influence in which different switch case this code may land.
In particular, SPICE_CURSOR_TYPE_ALPHA case seems to do another fetch of both cursor->header.width and cursor->header.height to calculate the cursor size before it invokes qxl_unpack_chunks, and passes this size as its second parameter.
In qxl_unpack_chunks at line 68, we can observe that it uses this same size on a memcpy invocation in which we should be able to control the source data, and also the size. If an attacker would be able to win this double-fetch race condition, by and changing the value of cursor->header.width and cursor->header.height after the call of cursor_alloc at qxl_cursor but before the memcpy at qxl_unpack_chunks, a heap buffer overflow would occur.
CVE-2020-7460
#
1/*
2 * Copy-in the array of control messages constructed using alignment
3 * and padding suitable for a 32-bit environment and construct an
4 * mbuf using alignment and padding suitable for a 64-bit kernel.
5 * The alignment and padding are defined indirectly by CMSG_DATA(),
6 * CMSG_SPACE() and CMSG_LEN().
7 */
8//XENO: buf is an ACID address/contents userspace buffer, buflen is also ACID
9static int
10freebsd32_copyin_control(struct mbuf **mp, caddr_t buf, u_int buflen)
11{
12 struct mbuf *m;
13 void *md;
14 u_int idx, len, msglen;
15 int error;
16
17 buflen = FREEBSD32_ALIGN(buflen);
18
19 if (buflen > MCLBYTES)
20 return (EINVAL);
21
22 /*
23 * Iterate over the buffer and get the length of each message
24 * in there. This has 32-bit alignment and padding. Use it to
25 * determine the length of these messages when using 64-bit
26 * alignment and padding.
27 */
28 idx = 0;
29 len = 0;
30 while (idx < buflen) {
31 error = copyin(buf + idx, &msglen, sizeof(msglen));
32 if (error)
33 return (error);
34 if (msglen < sizeof(struct cmsghdr))
35 return (EINVAL);
36 msglen = FREEBSD32_ALIGN(msglen);
37 if (idx + msglen > buflen)
38 return (EINVAL);
39 idx += msglen;
40 msglen += CMSG_ALIGN(sizeof(struct cmsghdr)) -
41 FREEBSD32_ALIGN(sizeof(struct cmsghdr));
42 len += CMSG_ALIGN(msglen);
43 }
44
45 if (len > MCLBYTES)
46 return (EINVAL);
47
48 m = m_get(M_WAITOK, MT_CONTROL);
49 if (len > MLEN)
50 MCLGET(m, M_WAITOK);
51 m->m_len = len;
52
53 md = mtod(m, void *);
54 while (buflen > 0) {
55 error = copyin(buf, md, sizeof(struct cmsghdr));
56 if (error)
57 break;
58 msglen = *(u_int *)md;
59 msglen = FREEBSD32_ALIGN(msglen);
60
61 /* Modify the message length to account for alignment. */
62 *(u_int *)md = msglen + CMSG_ALIGN(sizeof(struct cmsghdr)) -
63 FREEBSD32_ALIGN(sizeof(struct cmsghdr));
64
65 md = (char *)md + CMSG_ALIGN(sizeof(struct cmsghdr));
66 buf += FREEBSD32_ALIGN(sizeof(struct cmsghdr));
67 buflen -= FREEBSD32_ALIGN(sizeof(struct cmsghdr));
68
69 msglen -= FREEBSD32_ALIGN(sizeof(struct cmsghdr));
70 if (msglen > 0) {
71 error = copyin(buf, md, msglen);
72 if (error)
73 break;
74 md = (char *)md + CMSG_ALIGN(msglen);
75 buf += msglen;
76 buflen -= msglen;
77 }
78 }
79
80 if (error)
81 m_free(m);
82 else
83 *mp = m;
84 return (error);
85}
We can observe at line 30, there is a while loop that will iterate all of the supplied user-space buffer, and will fetch the length of each message msglen via copyin in order to calculate the aligned message size for all messages. From line 32 up to line 42, these are sanity checks on msglen, ensuring that each length for each message meets a specific criteria.
Then at line 54, there’s another while loop that starts processing each message. Here we can see at line 55, each message header is copied from user-space, and the length for that message (msglen) is dereferenced from this message header structure, that then at line 71 its used as a length to copy the rest of the message.
If an attacker would be able to win the race and modify a single msglen after the the initial accumulation of aligned messsage lengths len has being calculated, an attacker would be able to exploit this race condition as a TOCTOU and cause a buffer overflow
CVE-2021-34514
#
1
2// Heavily simplified pseudocode for the vulnerable function
3void AlpcpCompleteDispatchMessage(_ALPC_DISPATCH_CONTEXT *DispatchContext)
4{
5 _ALPC_PORT *port;
6 _KALPC_MESSAGE *message;
7 _ALPC_COMPLETION_LIST *completionList;
8 _ALPC_MESSAGE_ATTRIBUTES *attributes;
9 _PORT_MESSAGE *userMappedMessage;
10
11 void *userMappedMessageData;
12 uint32_t completionBufferOffset;
13 uint32_t bufferLength;
14 uint32_t alignmentPadding = 0;
15
16 port = DispatchContext->TargetPort;
17 message = DispatchContext->Message;
18 completionList = port->CompletionList;
19 bufferLength = message->PortMessage.u1.s1.TotalLength;
20 bufferLength += completionList->AttributeSize + alignmentPadding;
21
22 // Finds free space in the completion list
23 completionBufferOffset = AlpcpAllocateCompletionBuffer(port, bufferLength);
24
25 userMappedMessage = (_PORT_MESSAGE *) ((uintptr_t) completionList->Data +
26 completionBufferOffset);
27
28 // Message header is copied into shared user memory
29 *userMappedMessage = message->PortMessage;
30 userMappedMessageData = userMappedMessage + 0x1;
31
32 // Copy message body into shared user memory
33 if (message->DataUserVa == (void *)0x0){
34 AlpcpReadMessageData(message, userMappedMessageData);
35 }
36 else
37 {
38 AlpcpGetDataFromUserVaSafe(message, userMappedMessageData);
39 }
40
41 if (completionList->AttributeFlags != 0x0)
42 {
43 // Calulate offset and copy attributes into shared user memory
44 attributes = (_ALPC_MESSAGE_ATTRIBUTES *) ( (uintptr t) userMappedMessage +
45 userMappedMessage->u1.s1.TotalLength +
46 alignmentPadding);
47
48 attributes->AllocatedAttributes = completionList->AttributeFlags;
49 attributes->ValidAttributes = 0;
50 AlpcpExposeAttributes(port, 0, message, completionList->AttributeFlags, attributes);
51 }
52 //...
53}
In this specific example, a race condition exists in the sequece the kernel process a ALPC message to user-space. We can observe at line 17 a message is retrieved from DispatchContext->Message and saved as _KALPC_MESSAGE message.
Then the kernel will proceed to allocate enough space to copy that message via AlpcpAllocateCompletionBuffer by using the message->PortMessage.u1.s1.TotalLength field previously saved in bufferLentgh.
Then the user-spaced mapped message address will be computed at line 25, which will point at an offset to the previously allocated completion-buffer at completionList->Data + completionBufferOffset. At line 29, the message header will be then written to this shared memory with user-space.
Then at line 44, _ALPC_MESSAGE_ATTRIBUTES will be computed in which between other things, it will fetched the message lenght, however it will do this via the userMappedMessage, meaning it will fetch the length of the message from the message heaader that was just copied to the shared user-space buffer.
The race-condition in this example its based on the premise that if an attacker was able to change this message header after the kernel copies it to the shared user-space buffer before it populates the _ALPC_MESSAGE_ATTRIBUTES, then these would contain attacker-controlled data. This is a good example of a single fetch race condition due to a miscalculation in the sequence of message processing, as either the attributes should be populated from a kernel-only private copy, or the message header should be copied to user-space after the _ALPC_MESSAGE_ATTRIBUTES have been populated
#
Race Conditions
A race condition is where the system’s systantive behavior is dependent on the sequence or timing of other uncontrollable events. This becomes a security vulnerability when the system’s behaviour is dependent on the sequence or timing of attacker-controllable events, particularly in the handling of shared resources.
Within the set of race-condition behaviours we can differentiate two most common cases:
- Double-fetch conditions: When the system fetches an object or variable twice in different contexts/time spans that the attacker can manipulate or impact
- Time-of-check-time-of-use (TOCTOU): When the system fetches an object or variable several times in which the first fetches usually involves sanity checks of the subject item, while subsequent fetches asume the item is already checked and can be free to use. An attacker may be able to impact the sequence of events to break assumptions and impact system integrity.
Differences #
-
Race-Conditions: In theory a race condition does not need to have several fetches, as sometimes by winning a specific race condition, (say by modifying a shared resource once, before some other processing takes place on that same shared resource) may be enough to cause some undefined behaviour.
-
Double-Fetches and TOCTOUs: On the other hand, double-fetches and TOCTOUs involve several accesses to the same resource.
- TOCTOU: When explicit sanity checks are applied to the processing of a shared resource before a subsequent fetch –violating any integrity assumtions previously preconceived on the state, content or value stored in this shared resource.
- Double-fetch: When there are no sanity checks in place, simply the content, state or value stored in a shared resource can be changed on a subsequent fetch, violating any consistency assumptions on the value of this shared resource.
Common Causes #
- Shared Resources
- Volatile memory (DRAM)
- Non-volatile memory (SPI Flash, EEPROM, Filesystem, … etc)
- Parallelism
- Multithreading
- 2+ clients interacting with the same server
- 2+ tabs executing JavaScript in the same browser
- 2+ userspace threads/applications executing system calls in the same OS
- 2+ OS running in the same hypervisor
- Multiprocessing
- 2+ CPU cores executing in parallel in the same System-On-A-Chip (SoC)
- 2+ chips on a shared bus (PCIe access to central DRAM)
- Multithreading
How Race Conditions are usually handled #
- Mutual Exclusion
- Locks
- Mutexes
- Semaphores
Examples #
CVE-2021-4207 #
1//XENO: cursor points to Guest OS shared memory, and is thus ACID
2static QEMUCursor *qxl_cursor(PCIQXLDevice *qxl, QXLCursor *cursor,
3 uint32_t group_id)
4{
5 QEMUCursor *c;
6 uint8_t *and_mask, *xor_mask;
7 size_t size;
8
9 c = cursor_alloc(cursor->header.width, cursor->header.height);
10 c->hot_x = cursor->header.hot_spot_x;
11 c->hot_y = cursor->header.hot_spot_y;
12 switch (cursor->header.type) {
13 case SPICE_CURSOR_TYPE_MONO:
14 /* Assume that the full cursor is available in a single chunk. */
15 size = 2 * cursor_get_mono_bpl(c) * c->height;
16 if (size != cursor->data_size) {
17 fprintf(stderr, "%s: bad monochrome cursor %ux%u with size %u\n",
18 __func__, c->width, c->height, cursor->data_size);
19 goto fail;
20 }
21 and_mask = cursor->chunk.data;
22 xor_mask = and_mask + cursor_get_mono_bpl(c) * c->height;
23 cursor_set_mono(c, 0xffffff, 0x000000, xor_mask, 1, and_mask);
24 if (qxl->debug > 2) {
25 cursor_print_ascii_art(c, "qxl/mono");
26 }
27 break;
28 case SPICE_CURSOR_TYPE_ALPHA:
29 size = sizeof(uint32_t) * cursor->header.width * cursor->header.height;
30 qxl_unpack_chunks(c->data, size, qxl, &cursor->chunk, group_id);
31 if (qxl->debug > 2) {
32 cursor_print_ascii_art(c, "qxl/alpha");
33 }
34 break;
35 default:
36 fprintf(stderr, "%s: not implemented: type %d\n",
37 __func__, cursor->header.type);
38 goto fail;
39 }
40 return c;
41
42fail:
43 cursor_put(c);
44 return NULL;
45}
46
47QEMUCursor *cursor_alloc(int width, int height)
48{
49 QEMUCursor *c;
50 int datasize = width * height * sizeof(uint32_t);
51
52 c = g_malloc0(sizeof(QEMUCursor) + datasize);
53 c->width = width;
54 c->height = height;
55 c->refcount = 1;
56 return c;
57}
58
59static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl,
60 QXLDataChunk *chunk, uint32_t group_id)
61{
62 uint32_t max_chunks = 32;
63 size_t offset = 0;
64 size_t bytes;
65
66 for (;;) {
67 bytes = MIN(size - offset, chunk->data_size);
68 memcpy(dest + offset, chunk->data, bytes);
69 offset += bytes;
70 if (offset == size) {
71 return;
72 }
73 chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id);
74 if (!chunk) {
75 return;
76 }
77 max_chunks--;
78 if (max_chunks == 0) {
79 return;
80 }
81 }
82}
At line 9 we can see that cursor->header.width and cursor->header.height are being fetched from shared memory to allocate a QEMUCursor object via cursor_alloc.
Furthermore, at line 12 there’s a switch statement on cursor->header.type which is also held in shared memory pointed to by cursor, therefore an attacker would be able to influence in which different switch case this code may land.
In particular, SPICE_CURSOR_TYPE_ALPHA case seems to do another fetch of both cursor->header.width and cursor->header.height to calculate the cursor size before it invokes qxl_unpack_chunks, and passes this size as its second parameter.
In qxl_unpack_chunks at line 68, we can observe that it uses this same size on a memcpy invocation in which we should be able to control the source data, and also the size. If an attacker would be able to win this double-fetch race condition, by and changing the value of cursor->header.width and cursor->header.height after the call of cursor_alloc at qxl_cursor but before the memcpy at qxl_unpack_chunks, a heap buffer overflow would occur.
CVE-2020-7460 #
1/*
2 * Copy-in the array of control messages constructed using alignment
3 * and padding suitable for a 32-bit environment and construct an
4 * mbuf using alignment and padding suitable for a 64-bit kernel.
5 * The alignment and padding are defined indirectly by CMSG_DATA(),
6 * CMSG_SPACE() and CMSG_LEN().
7 */
8//XENO: buf is an ACID address/contents userspace buffer, buflen is also ACID
9static int
10freebsd32_copyin_control(struct mbuf **mp, caddr_t buf, u_int buflen)
11{
12 struct mbuf *m;
13 void *md;
14 u_int idx, len, msglen;
15 int error;
16
17 buflen = FREEBSD32_ALIGN(buflen);
18
19 if (buflen > MCLBYTES)
20 return (EINVAL);
21
22 /*
23 * Iterate over the buffer and get the length of each message
24 * in there. This has 32-bit alignment and padding. Use it to
25 * determine the length of these messages when using 64-bit
26 * alignment and padding.
27 */
28 idx = 0;
29 len = 0;
30 while (idx < buflen) {
31 error = copyin(buf + idx, &msglen, sizeof(msglen));
32 if (error)
33 return (error);
34 if (msglen < sizeof(struct cmsghdr))
35 return (EINVAL);
36 msglen = FREEBSD32_ALIGN(msglen);
37 if (idx + msglen > buflen)
38 return (EINVAL);
39 idx += msglen;
40 msglen += CMSG_ALIGN(sizeof(struct cmsghdr)) -
41 FREEBSD32_ALIGN(sizeof(struct cmsghdr));
42 len += CMSG_ALIGN(msglen);
43 }
44
45 if (len > MCLBYTES)
46 return (EINVAL);
47
48 m = m_get(M_WAITOK, MT_CONTROL);
49 if (len > MLEN)
50 MCLGET(m, M_WAITOK);
51 m->m_len = len;
52
53 md = mtod(m, void *);
54 while (buflen > 0) {
55 error = copyin(buf, md, sizeof(struct cmsghdr));
56 if (error)
57 break;
58 msglen = *(u_int *)md;
59 msglen = FREEBSD32_ALIGN(msglen);
60
61 /* Modify the message length to account for alignment. */
62 *(u_int *)md = msglen + CMSG_ALIGN(sizeof(struct cmsghdr)) -
63 FREEBSD32_ALIGN(sizeof(struct cmsghdr));
64
65 md = (char *)md + CMSG_ALIGN(sizeof(struct cmsghdr));
66 buf += FREEBSD32_ALIGN(sizeof(struct cmsghdr));
67 buflen -= FREEBSD32_ALIGN(sizeof(struct cmsghdr));
68
69 msglen -= FREEBSD32_ALIGN(sizeof(struct cmsghdr));
70 if (msglen > 0) {
71 error = copyin(buf, md, msglen);
72 if (error)
73 break;
74 md = (char *)md + CMSG_ALIGN(msglen);
75 buf += msglen;
76 buflen -= msglen;
77 }
78 }
79
80 if (error)
81 m_free(m);
82 else
83 *mp = m;
84 return (error);
85}
We can observe at line 30, there is a while loop that will iterate all of the supplied user-space buffer, and will fetch the length of each message msglen via copyin in order to calculate the aligned message size for all messages. From line 32 up to line 42, these are sanity checks on msglen, ensuring that each length for each message meets a specific criteria.
Then at line 54, there’s another while loop that starts processing each message. Here we can see at line 55, each message header is copied from user-space, and the length for that message (msglen) is dereferenced from this message header structure, that then at line 71 its used as a length to copy the rest of the message.
If an attacker would be able to win the race and modify a single msglen after the the initial accumulation of aligned messsage lengths len has being calculated, an attacker would be able to exploit this race condition as a TOCTOU and cause a buffer overflow
CVE-2021-34514 #
1
2// Heavily simplified pseudocode for the vulnerable function
3void AlpcpCompleteDispatchMessage(_ALPC_DISPATCH_CONTEXT *DispatchContext)
4{
5 _ALPC_PORT *port;
6 _KALPC_MESSAGE *message;
7 _ALPC_COMPLETION_LIST *completionList;
8 _ALPC_MESSAGE_ATTRIBUTES *attributes;
9 _PORT_MESSAGE *userMappedMessage;
10
11 void *userMappedMessageData;
12 uint32_t completionBufferOffset;
13 uint32_t bufferLength;
14 uint32_t alignmentPadding = 0;
15
16 port = DispatchContext->TargetPort;
17 message = DispatchContext->Message;
18 completionList = port->CompletionList;
19 bufferLength = message->PortMessage.u1.s1.TotalLength;
20 bufferLength += completionList->AttributeSize + alignmentPadding;
21
22 // Finds free space in the completion list
23 completionBufferOffset = AlpcpAllocateCompletionBuffer(port, bufferLength);
24
25 userMappedMessage = (_PORT_MESSAGE *) ((uintptr_t) completionList->Data +
26 completionBufferOffset);
27
28 // Message header is copied into shared user memory
29 *userMappedMessage = message->PortMessage;
30 userMappedMessageData = userMappedMessage + 0x1;
31
32 // Copy message body into shared user memory
33 if (message->DataUserVa == (void *)0x0){
34 AlpcpReadMessageData(message, userMappedMessageData);
35 }
36 else
37 {
38 AlpcpGetDataFromUserVaSafe(message, userMappedMessageData);
39 }
40
41 if (completionList->AttributeFlags != 0x0)
42 {
43 // Calulate offset and copy attributes into shared user memory
44 attributes = (_ALPC_MESSAGE_ATTRIBUTES *) ( (uintptr t) userMappedMessage +
45 userMappedMessage->u1.s1.TotalLength +
46 alignmentPadding);
47
48 attributes->AllocatedAttributes = completionList->AttributeFlags;
49 attributes->ValidAttributes = 0;
50 AlpcpExposeAttributes(port, 0, message, completionList->AttributeFlags, attributes);
51 }
52 //...
53}
In this specific example, a race condition exists in the sequece the kernel process a ALPC message to user-space. We can observe at line 17 a message is retrieved from DispatchContext->Message and saved as _KALPC_MESSAGE message.
Then the kernel will proceed to allocate enough space to copy that message via AlpcpAllocateCompletionBuffer by using the message->PortMessage.u1.s1.TotalLength field previously saved in bufferLentgh.
Then the user-spaced mapped message address will be computed at line 25, which will point at an offset to the previously allocated completion-buffer at completionList->Data + completionBufferOffset. At line 29, the message header will be then written to this shared memory with user-space.
Then at line 44, _ALPC_MESSAGE_ATTRIBUTES will be computed in which between other things, it will fetched the message lenght, however it will do this via the userMappedMessage, meaning it will fetch the length of the message from the message heaader that was just copied to the shared user-space buffer.
The race-condition in this example its based on the premise that if an attacker was able to change this message header after the kernel copies it to the shared user-space buffer before it populates the _ALPC_MESSAGE_ATTRIBUTES, then these would contain attacker-controlled data. This is a good example of a single fetch race condition due to a miscalculation in the sequence of message processing, as either the attributes should be populated from a kernel-only private copy, or the message header should be copied to user-space after the _ALPC_MESSAGE_ATTRIBUTES have been populated
Use-After-Frees
Use after frees are vulnerabilities in which deallocated data its used after been freed, while replaced with attacker controlled data.
Common Causes
#
- Attacker controlled pointer passed to free
- Premature free caused by a race-condition
- Premature/double frees caused by logic bugs
- Wrong management of object’s lifetime in different scopes
Potential primitives
#
Sometimes an use-after-free vulnerability its intrinsic in the code-base being audited. However, its fairly common to find a related vulnerability, that can be manufactured to an use-after-free:
-
Use-After-Free: If an object gets freed, and theres still a way to induce the program to use this freed object, an attacker could induce this premature free in order to abuse a subsequent usage of the object with attacker-controlled data. This usually happens after the attacker has reclaimed the object’s freed memory so that its populated under attacker-controlled data.
-
Arbitrary-Free: If an attacker is able to induce a premature free with some arbitratry pointer, and the attacker can predict/anticipate where some target memory is in the address-space, or use an information disclosure vulnerability in order to gain this information, an arbitrary-free primitive can be easily promoted to an use-after-free primitive.
-
Double-Free: If an attacker can induce (either via a logical bug or some programming error) a situation in which two calls to free are performed on the same pointer P, a double free could be promoted to an use-after-free in the following way:
- First free on original value of
P to object X is performed.
- Attacker then reclaims the freed memory pointed to by
P with object Y, which usually must be either of same size or type (depending on allocator hardening) than object X.
- Attacker manages to trigger the second free on
P to object Y.
- Attacker triggers a code-path in which uses object
Y with attacker-controlled data.
Note: On C++ codebases put close attention to delete overrides aswell as free implementations
In addition, similar vulnerabilities can be achieved on stack memory where a stack local variable its used passed its scope, often referred to as stack- buffer use-after-return. These vulnerabilities are usually more tedious to exploit. An attacker would usually have to carefully groom stack memory by performing function calls in order to initialize local variables with either attacker-controlled data or semi-attacker controlled data in the stack, in hope that the local out-of-scope variable falls under some attacker-controlled data from previous stack-frames when the function call that references this dangling local vairable gets invoked.
Examples
#
CVE-2021-28460
#
1
2struct pwm_state {
3 unsigned int period;
4 unsigned int duty_cycle;
5 enum pwm_polarity polarity;
6 bool enabled;
7
8 void *extended_state;
9 size_t extended_state_size;
10};
11
12struct pwm_chardev_params {
13 unsigned int pwm_index;
14 struct pwm_state state;
15};
16
17static int pwm_ioctl_apply_state(void __user *arg, struct pwm_dev *data)
18{
19 int ret = 0;
20 struct pwm_chardev_params input_data;
21 void __user *user_extended_state;
22
23 memset(&input_data, 0, sizeof(input_data));
24
25 if (copy_from_user(&input_data, arg, sizeof(input_data))) {
26 ret = -EFAULT;
27 goto out;
28 }
29
30 user_extended_state = input_data.state.extended_state;
31
32 if (user_extended_state) {
33 input_data.state.extended_state = kzalloc(
34 input_data.state.extended_state_size, GFP_KERNEL);
35 if (!input_data.state.extended_state) {
36 ret = -ENOMEM;
37 goto out;
38 }
39 if (copy_from_user(input_data.state.extended_state,
40 user_extended_state,
41 input_data.state.extended_state_size)) {
42 ret = -EFAULT;
43 goto out;
44 }
45 }
46
47 if (input_data.pwm_index >= data->chip->npwm) {
48 dev_err(data->device, "pwm_index %u does not exist, npwm: %u\n",
49 input_data.pwm_index, data->chip->npwm);
50 ret = -ENODEV;
51 goto out;
52 }
53
54 ret = pwm_apply_state(&data->chip->pwms[input_data.pwm_index],
55 &input_data.state);
56 if (ret) {
57 dev_err(data->device, "pwm_apply_state error: %d\n", ret);
58 goto out;
59 }
60
61out:
62 // pwm_apply_state keeps a copy of extended_state, so free this
63 kfree(input_data.state.extended_state);
64 return ret;
65}
At line 25 we can observe a call to copy_from_user to populate arg to the pwm_chardev_params typed input_data in kernel-space.
We can see at line 27 that if copy_from_user returns a non-zero value, it will branch to out, in which simply calls kfree on input_data.state.extended_state.
The vulnerability here is based on the misunderstanding of copy_from_user semantics. Essentially, copy_from_user will attempt to copy a block of memory from user-space to kernel-space. If lets say there is a gap of unmmaped memory in user-space within the block that its being desired to be copied, then copy_from_user will fail, returning the number of bytes that were not able to be copied.
Based on the documentation, before calling copy_from_user, one should call access_ok first to ensure the region of memory to be copied is accesible. If not, even on failure copy_from_user will still conduct the memory-copy operation, and it will just zero-extend the bytes that failed to be access from user-space.
Therefore, if on line 25 copy_from_user returns a non-zero value, then by the time it branches to line 63, input_data.state.extended_state may contain data from user-space, and the invokation to kfree could lead to an arbitrary-free primitive.
CVE-2020-29661
#
1struct pid
2{
3 atomic_t count;
4 unsigned int level;
5 /* lists of tasks that use this pid */
6 struct hlist_head tasks[PIDTYPE_MAX];
7 struct rcu_head rcu;
8 struct upid numbers[1];
9};
10
11/*pid->count-- w/ possible free()*/
12void put_pid(struct pid *pid){
13 struct pid_namespace *ns;
14
15 if (!pid)
16 return;
17
18 ns = pid->numbers[pid->level].ns;
19 if ((atomic_read(&pid->count) == 1) ||
20 atomic_dec_and_test(&pid->count)) {
21 kmem_cache_free(ns->pid_cachep, pid);
22 put_pid_ns(ns);
23 }
24}
25
26/*pid->count++*/
27static inline struct pid *get_pid(struct pid *pid){
28 if (pid)
29 atomic_inc(&pid->count);
30 return pid;
31}
32
33struct tty_struct {
34...
35 spinlock_t ctrl_lock;
36...
37 struct pid *pgrp; /* Protected by ctrl_lock */
38...
39 struct tty_struct *link;
40...
41}
42#define get_current() (current_thread_info()->task)
43#define current get_current()
44
45//XENO: tty can be either master or slave
46//XENO: real_tty is always slave
47//XENO: p is an ACID pid_t
48static int tiocspgrp(struct tty_struct *tty, struct tty_struct *real_tty, pid_t __user *p)
49{
50 struct pid *pgrp;
51 pid_t pgrp_nr;
52 int retval = tty_check_change(real_tty);
53
54 if (retval == -EIO)
55 return -ENOTTY;
56 if (retval)
57 return retval;
58 if (!current->signal->tty ||
59 (current->signal->tty != real_tty) ||
60 (real_tty->session != task_session(current)))
61 return -ENOTTY;
62 if (get_user(pgrp_nr, p))
63 return -EFAULT;
64 if (pgrp_nr < 0)
65 return -EINVAL;
66 rcu_read_lock();
67 pgrp = find_vpid(pgrp_nr);
68 retval = -ESRCH;
69 if (!pgrp)
70 goto out_unlock;
71 retval = -EPERM;
72 if (session_of_pgrp(pgrp) != task_session(current))
73 goto out_unlock;
74 retval = 0;
75 spin_lock_irq(&tty->ctrl_lock);
76 put_pid(real_tty->pgrp);
77 real_tty->pgrp = get_pid(pgrp);
78 spin_unlock_irq(&tty->ctrl_lock);
79out_unlock:
80 rcu_read_unlock();
81 return retval;
82}
The vulnerability here is actually quite simple. Basically the wrong lock was used when calling put_pid(real_tty->pgrp) for the slave tty while the lock of the master tty was the one being hold. In the case in which multiple CPU cores or kernel threads would be executing the same code in parallel, the pid object could be freed prematurely.
CVE-2020-2674
#
1
2/** @copydoc VUSBIROOTHUBCONNECTOR::pfnFreeUrb */
3DECLINLINE(int) VUSBIRhFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
4{
5 return pInterface->pfnFreeUrb(pInterface, pUrb); //XENO: goto vusbRhConnFreeUrb() (assigned in vusbRhConstruct())
6}
7
8
9/** @copydoc VUSBIROOTHUBCONNECTOR::pfnSubmitUrb */
10DECLINLINE(int) VUSBIRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, struct PDMLED *pLed)
11{
12 return pInterface->pfnSubmitUrb(pInterface, pUrb, pLed); //XENO: goto vusbRhSubmitUrb() (assigned in vusbRhConstruct())
13}
14
15/**
16 * Releases the given VUSB device pointer.
17 *
18 * @returns New reference count.
19 * @retval 0 if no onw is holding a reference anymore causing the device to be destroyed.
20 */
21DECLINLINE(uint32_t) vusbDevRelease(PVUSBDEV pThis)
22{
23 AssertPtrReturn(pThis, UINT32_MAX);
24
25 uint32_t cRefs = ASMAtomicDecU32(&pThis->cRefs);
26 AssertMsg(cRefs < _1M, ("%#x %p\n", cRefs, pThis));
27 if (cRefs == 0)
28 vusbDevDestroy(pThis);
29 return cRefs;
30}
31
32
33/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnFreeUrb} */
34static DECLCALLBACK(int) vusbRhConnFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
35{
36 RT_NOREF(pInterface);
37 pUrb->pVUsb->pfnFree(pUrb); //XENO: goto vusbRhFreeUrb() (assigned in vusbRhNewUrb())
38 return VINF_SUCCESS;
39}
40
41/**
42 * Callback for freeing an URB.
43 * @param pUrb The URB to free.
44 */
45static DECLCALLBACK(void) vusbRhFreeUrb(PVUSBURB pUrb)
46{
47 /*
48 * Assert sanity.
49 */
50 vusbUrbAssert(pUrb);
51 PVUSBROOTHUB pRh = (PVUSBROOTHUB)pUrb->pVUsb->pvFreeCtx;
52 Assert(pRh);
53
54 Assert(pUrb->enmState != VUSBURBSTATE_FREE);
55
56 /*
57 * Free the URB description (logging builds only).
58 */
59 if (pUrb->pszDesc)
60 {
61 RTStrFree(pUrb->pszDesc);
62 pUrb->pszDesc = NULL;
63 }
64
65 /* The URB comes from the roothub if there is no device (invalid address). */
66 if (pUrb->pVUsb->pDev)
67 {
68 PVUSBDEV pDev = pUrb->pVUsb->pDev;
69
70 vusbUrbPoolFree(&pUrb->pVUsb->pDev->UrbPool, pUrb);
71 vusbDevRelease(pDev);
72 }
73 else
74 vusbUrbPoolFree(&pRh->Hub.Dev.UrbPool, pUrb);
75}
76
77/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnSubmitUrb} */
78static DECLCALLBACK(int) vusbRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, PPDMLED pLed)
79{
80 PVUSBROOTHUB pRh = VUSBIROOTHUBCONNECTOR_2_VUSBROOTHUB(pInterface);
81 STAM_PROFILE_START(&pRh->StatSubmitUrb, a);
82
83 /* If there is a sniffer on the roothub record the URB there. */
84 if (pRh->hSniffer != VUSBSNIFFER_NIL)
85 {
86 int rc = VUSBSnifferRecordEvent(pRh->hSniffer, pUrb, VUSBSNIFFEREVENT_SUBMIT);
87 if (RT_FAILURE(rc))
88 LogRel(("VUSB: Capturing URB submit event on the root hub failed with %Rrc\n", rc));
89 }
90
91 /*
92 * The device was resolved when we allocated the URB.
93 * Submit it to the device if we found it, if not fail with device-not-ready.
94 */
95 int rc;
96 if ( pUrb->pVUsb->pDev
97 && pUrb->pVUsb->pDev->pUsbIns)
98 {
99 switch (pUrb->enmDir)
100 {
101 case VUSBDIRECTION_IN:
102 pLed->Asserted.s.fReading = pLed->Actual.s.fReading = 1;
103 rc = vusbUrbSubmit(pUrb);
104 pLed->Actual.s.fReading = 0;
105 break;
106 case VUSBDIRECTION_OUT:
107 pLed->Asserted.s.fWriting = pLed->Actual.s.fWriting = 1;
108 rc = vusbUrbSubmit(pUrb);
109 pLed->Actual.s.fWriting = 0;
110 break;
111 default:
112 rc = vusbUrbSubmit(pUrb);
113 break;
114 }
115
116 if (RT_FAILURE(rc))
117 {
118 LogFlow(("vusbRhSubmitUrb: freeing pUrb=%p\n", pUrb));
119 pUrb->pVUsb->pfnFree(pUrb);
120 }
121 }
122 else
123 {
124 vusbDevRetain(&pRh->Hub.Dev);
125 pUrb->pVUsb->pDev = &pRh->Hub.Dev;
126 Log(("vusb: pRh=%p: SUBMIT: Address %i not found!!!\n", pRh, pUrb->DstAddress));
127
128 pUrb->enmState = VUSBURBSTATE_REAPED;
129 pUrb->enmStatus = VUSBSTATUS_DNR;
130 vusbUrbCompletionRh(pUrb);
131 rc = VINF_SUCCESS;
132 }
133
134 STAM_PROFILE_STOP(&pRh->StatSubmitUrb, a);
135 return rc;
136}
137
138//XENO: START HERE
139/**
140 * Service a general transport descriptor.
141 */
142static bool ohciR3ServiceTd(POHCI pThis, VUSBXFERTYPE enmType, PCOHCIED pEd, uint32_t EdAddr, uint32_t TdAddr,
143 uint32_t *pNextTdAddr, const char *pszListName)
144{
145 RT_NOREF(pszListName);
146
147 /*
148 * Read the TD and setup the buffer data.
149 */
150 OHCITD Td;
151 ohciR3ReadTd(pThis, TdAddr, &Td);
152 OHCIBUF Buf;
153 ohciR3BufInit(&Buf, Td.cbp, Td.be);
154
155 *pNextTdAddr = Td.NextTD & ED_PTR_MASK;
156
157 /*
158 * Determine the direction.
159 */
160 VUSBDIRECTION enmDir;
161 switch (pEd->hwinfo & ED_HWINFO_DIR)
162 {
163 case ED_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
164 case ED_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
165 default:
166 switch (Td.hwinfo & TD_HWINFO_DIR)
167 {
168 case TD_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
169 case TD_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
170 case 0: enmDir = VUSBDIRECTION_SETUP; break;
171 default:
172 Log(("ohciR3ServiceTd: Invalid direction!!!! Td.hwinfo=%#x Ed.hwdinfo=%#x\n", Td.hwinfo, pEd->hwinfo));
173 ohciR3RaiseUnrecoverableError(pThis, 2);
174 return false;
175 }
176 break;
177 }
178
179 pThis->fIdle = false; /* Mark as active */
180
181 /*
182 * Allocate and initialize a new URB.
183 */
184 PVUSBURB pUrb = VUSBIRhNewUrb(pThis->RootHub.pIRhConn, pEd->hwinfo & ED_HWINFO_FUNCTION, NULL,
185 enmType, enmDir, Buf.cbTotal, 1, NULL);
186 if (!pUrb)
187 return false; /* retry later... */
188
189 pUrb->EndPt = (pEd->hwinfo & ED_HWINFO_ENDPOINT) >> ED_HWINFO_ENDPOINT_SHIFT;
190 pUrb->fShortNotOk = !(Td.hwinfo & TD_HWINFO_ROUNDING);
191 pUrb->enmStatus = VUSBSTATUS_OK;
192 pUrb->pHci->EdAddr = EdAddr;
193 pUrb->pHci->fUnlinked = false;
194 pUrb->pHci->cTds = 1;
195 pUrb->paTds[0].TdAddr = TdAddr;
196 pUrb->pHci->u32FrameNo = pThis->HcFmNumber;
197 AssertCompile(sizeof(pUrb->paTds[0].TdCopy) >= sizeof(Td));
198 memcpy(pUrb->paTds[0].TdCopy, &Td, sizeof(Td));
199
200 /* copy data if out bound transfer. */
201 pUrb->cbData = Buf.cbTotal;
202 if ( Buf.cbTotal
203 && Buf.cVecs > 0
204 && enmDir != VUSBDIRECTION_IN)
205 {
206 /* Be paranoid. */ //XENO: That's what I like to hear! :D
207 if ( Buf.aVecs[0].cb > pUrb->cbData
208 || ( Buf.cVecs > 1
209 && Buf.aVecs[1].cb > (pUrb->cbData - Buf.aVecs[0].cb)))
210 {
211 ohciR3RaiseUnrecoverableError(pThis, 3);
212 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
213 return false;
214 }
215
216 ohciR3PhysRead(pThis, Buf.aVecs[0].Addr, pUrb->abData, Buf.aVecs[0].cb);
217 if (Buf.cVecs > 1)
218 ohciR3PhysRead(pThis, Buf.aVecs[1].Addr, &pUrb->abData[Buf.aVecs[0].cb], Buf.aVecs[1].cb);
219 }
220
221 /*
222 * Submit the URB.
223 */
224 ohciR3InFlightAdd(pThis, TdAddr, pUrb);
225 Log(("%s: ohciR3ServiceTd: submitting TdAddr=%#010x EdAddr=%#010x cbData=%#x\n",
226 pUrb->pszDesc, TdAddr, EdAddr, pUrb->cbData));
227
228 ohciR3Unlock(pThis);
229 int rc = VUSBIRhSubmitUrb(pThis->RootHub.pIRhConn, pUrb, &pThis->RootHub.Led);
230 ohciR3Lock(pThis);
231 if (RT_SUCCESS(rc))
232 return true;
233
234 /* Failure cleanup. Can happen if we're still resetting the device or out of resources. */
235 Log(("ohciR3ServiceTd: failed submitting TdAddr=%#010x EdAddr=%#010x pUrb=%p!!\n",
236 TdAddr, EdAddr, pUrb));
237 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
238 ohciR3InFlightRemove(pThis, TdAddr);
239 return false;
240}
We can see that at line 184 in ohciR3ServiceTd function, a PVUSBURB object pUrb its being allocated via VUSBIRhNewUrb(). Long story short, a logical error exist which does not track the lifetime of this object across function boundaries.
At line 229 VUSBIRhSubmitUrb gets invoked, as as we can see pThis->RootHub.pIRhConn its passed as its first parameter and pUrb its passed as its second parameter. VUSBIRhSubmitUrb will endup invoking vusbRhSubmitUrb, in which we can see at line 112, if vusbUrbSubmit fails an error code checked at line 116 will provoke pUrb to be freed at line 119, and the function will terminate returning the error code. Back at ohciR3ServiceTd at line 231 we see that if the return code from VUSBIRhSubmitUrb succeeded, the function will end returning true.
On the other hand, if VUSBIRhSubmitUrb failed pUrb would have been already freed as previously mentioned. The function will proceed until a VUSBIRhFreeUrb invocation which the same two parameters will be passed as it did on vusbRhSubmitUrb–that is pThis->RootHub.pIRhConn and pUrb–which will result in attempting to free pUrb a second time, showcasing a double-free vulnerability.
#
Use-After-Frees
Use after frees are vulnerabilities in which deallocated data its used after been freed, while replaced with attacker controlled data.
Common Causes #
- Attacker controlled pointer passed to free
- Premature free caused by a race-condition
- Premature/double frees caused by logic bugs
- Wrong management of object’s lifetime in different scopes
Potential primitives #
Sometimes an use-after-free vulnerability its intrinsic in the code-base being audited. However, its fairly common to find a related vulnerability, that can be manufactured to an use-after-free:
-
Use-After-Free: If an object gets freed, and theres still a way to induce the program to use this freed object, an attacker could induce this premature free in order to abuse a subsequent usage of the object with attacker-controlled data. This usually happens after the attacker has reclaimed the object’s freed memory so that its populated under attacker-controlled data.
-
Arbitrary-Free: If an attacker is able to induce a premature free with some arbitratry pointer, and the attacker can predict/anticipate where some target memory is in the address-space, or use an information disclosure vulnerability in order to gain this information, an arbitrary-free primitive can be easily promoted to an use-after-free primitive.
-
Double-Free: If an attacker can induce (either via a logical bug or some programming error) a situation in which two calls to free are performed on the same pointer
P, a double free could be promoted to an use-after-free in the following way:- First free on original value of
Pto objectXis performed. - Attacker then reclaims the freed memory pointed to by
Pwith objectY, which usually must be either of same size or type (depending on allocator hardening) than objectX. - Attacker manages to trigger the second free on
Pto objectY. - Attacker triggers a code-path in which uses object
Ywith attacker-controlled data.
- First free on original value of
Note: On C++ codebases put close attention to delete overrides aswell as free implementations
In addition, similar vulnerabilities can be achieved on stack memory where a stack local variable its used passed its scope, often referred to as stack- buffer use-after-return. These vulnerabilities are usually more tedious to exploit. An attacker would usually have to carefully groom stack memory by performing function calls in order to initialize local variables with either attacker-controlled data or semi-attacker controlled data in the stack, in hope that the local out-of-scope variable falls under some attacker-controlled data from previous stack-frames when the function call that references this dangling local vairable gets invoked.
Examples #
CVE-2021-28460 #
1
2struct pwm_state {
3 unsigned int period;
4 unsigned int duty_cycle;
5 enum pwm_polarity polarity;
6 bool enabled;
7
8 void *extended_state;
9 size_t extended_state_size;
10};
11
12struct pwm_chardev_params {
13 unsigned int pwm_index;
14 struct pwm_state state;
15};
16
17static int pwm_ioctl_apply_state(void __user *arg, struct pwm_dev *data)
18{
19 int ret = 0;
20 struct pwm_chardev_params input_data;
21 void __user *user_extended_state;
22
23 memset(&input_data, 0, sizeof(input_data));
24
25 if (copy_from_user(&input_data, arg, sizeof(input_data))) {
26 ret = -EFAULT;
27 goto out;
28 }
29
30 user_extended_state = input_data.state.extended_state;
31
32 if (user_extended_state) {
33 input_data.state.extended_state = kzalloc(
34 input_data.state.extended_state_size, GFP_KERNEL);
35 if (!input_data.state.extended_state) {
36 ret = -ENOMEM;
37 goto out;
38 }
39 if (copy_from_user(input_data.state.extended_state,
40 user_extended_state,
41 input_data.state.extended_state_size)) {
42 ret = -EFAULT;
43 goto out;
44 }
45 }
46
47 if (input_data.pwm_index >= data->chip->npwm) {
48 dev_err(data->device, "pwm_index %u does not exist, npwm: %u\n",
49 input_data.pwm_index, data->chip->npwm);
50 ret = -ENODEV;
51 goto out;
52 }
53
54 ret = pwm_apply_state(&data->chip->pwms[input_data.pwm_index],
55 &input_data.state);
56 if (ret) {
57 dev_err(data->device, "pwm_apply_state error: %d\n", ret);
58 goto out;
59 }
60
61out:
62 // pwm_apply_state keeps a copy of extended_state, so free this
63 kfree(input_data.state.extended_state);
64 return ret;
65}
At line 25 we can observe a call to copy_from_user to populate arg to the pwm_chardev_params typed input_data in kernel-space.
We can see at line 27 that if copy_from_user returns a non-zero value, it will branch to out, in which simply calls kfree on input_data.state.extended_state.
The vulnerability here is based on the misunderstanding of copy_from_user semantics. Essentially, copy_from_user will attempt to copy a block of memory from user-space to kernel-space. If lets say there is a gap of unmmaped memory in user-space within the block that its being desired to be copied, then copy_from_user will fail, returning the number of bytes that were not able to be copied.
Based on the documentation, before calling copy_from_user, one should call access_ok first to ensure the region of memory to be copied is accesible. If not, even on failure copy_from_user will still conduct the memory-copy operation, and it will just zero-extend the bytes that failed to be access from user-space.
Therefore, if on line 25 copy_from_user returns a non-zero value, then by the time it branches to line 63, input_data.state.extended_state may contain data from user-space, and the invokation to kfree could lead to an arbitrary-free primitive.
CVE-2020-29661 #
1struct pid
2{
3 atomic_t count;
4 unsigned int level;
5 /* lists of tasks that use this pid */
6 struct hlist_head tasks[PIDTYPE_MAX];
7 struct rcu_head rcu;
8 struct upid numbers[1];
9};
10
11/*pid->count-- w/ possible free()*/
12void put_pid(struct pid *pid){
13 struct pid_namespace *ns;
14
15 if (!pid)
16 return;
17
18 ns = pid->numbers[pid->level].ns;
19 if ((atomic_read(&pid->count) == 1) ||
20 atomic_dec_and_test(&pid->count)) {
21 kmem_cache_free(ns->pid_cachep, pid);
22 put_pid_ns(ns);
23 }
24}
25
26/*pid->count++*/
27static inline struct pid *get_pid(struct pid *pid){
28 if (pid)
29 atomic_inc(&pid->count);
30 return pid;
31}
32
33struct tty_struct {
34...
35 spinlock_t ctrl_lock;
36...
37 struct pid *pgrp; /* Protected by ctrl_lock */
38...
39 struct tty_struct *link;
40...
41}
42#define get_current() (current_thread_info()->task)
43#define current get_current()
44
45//XENO: tty can be either master or slave
46//XENO: real_tty is always slave
47//XENO: p is an ACID pid_t
48static int tiocspgrp(struct tty_struct *tty, struct tty_struct *real_tty, pid_t __user *p)
49{
50 struct pid *pgrp;
51 pid_t pgrp_nr;
52 int retval = tty_check_change(real_tty);
53
54 if (retval == -EIO)
55 return -ENOTTY;
56 if (retval)
57 return retval;
58 if (!current->signal->tty ||
59 (current->signal->tty != real_tty) ||
60 (real_tty->session != task_session(current)))
61 return -ENOTTY;
62 if (get_user(pgrp_nr, p))
63 return -EFAULT;
64 if (pgrp_nr < 0)
65 return -EINVAL;
66 rcu_read_lock();
67 pgrp = find_vpid(pgrp_nr);
68 retval = -ESRCH;
69 if (!pgrp)
70 goto out_unlock;
71 retval = -EPERM;
72 if (session_of_pgrp(pgrp) != task_session(current))
73 goto out_unlock;
74 retval = 0;
75 spin_lock_irq(&tty->ctrl_lock);
76 put_pid(real_tty->pgrp);
77 real_tty->pgrp = get_pid(pgrp);
78 spin_unlock_irq(&tty->ctrl_lock);
79out_unlock:
80 rcu_read_unlock();
81 return retval;
82}
The vulnerability here is actually quite simple. Basically the wrong lock was used when calling put_pid(real_tty->pgrp) for the slave tty while the lock of the master tty was the one being hold. In the case in which multiple CPU cores or kernel threads would be executing the same code in parallel, the pid object could be freed prematurely.
CVE-2020-2674 #
1
2/** @copydoc VUSBIROOTHUBCONNECTOR::pfnFreeUrb */
3DECLINLINE(int) VUSBIRhFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
4{
5 return pInterface->pfnFreeUrb(pInterface, pUrb); //XENO: goto vusbRhConnFreeUrb() (assigned in vusbRhConstruct())
6}
7
8
9/** @copydoc VUSBIROOTHUBCONNECTOR::pfnSubmitUrb */
10DECLINLINE(int) VUSBIRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, struct PDMLED *pLed)
11{
12 return pInterface->pfnSubmitUrb(pInterface, pUrb, pLed); //XENO: goto vusbRhSubmitUrb() (assigned in vusbRhConstruct())
13}
14
15/**
16 * Releases the given VUSB device pointer.
17 *
18 * @returns New reference count.
19 * @retval 0 if no onw is holding a reference anymore causing the device to be destroyed.
20 */
21DECLINLINE(uint32_t) vusbDevRelease(PVUSBDEV pThis)
22{
23 AssertPtrReturn(pThis, UINT32_MAX);
24
25 uint32_t cRefs = ASMAtomicDecU32(&pThis->cRefs);
26 AssertMsg(cRefs < _1M, ("%#x %p\n", cRefs, pThis));
27 if (cRefs == 0)
28 vusbDevDestroy(pThis);
29 return cRefs;
30}
31
32
33/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnFreeUrb} */
34static DECLCALLBACK(int) vusbRhConnFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
35{
36 RT_NOREF(pInterface);
37 pUrb->pVUsb->pfnFree(pUrb); //XENO: goto vusbRhFreeUrb() (assigned in vusbRhNewUrb())
38 return VINF_SUCCESS;
39}
40
41/**
42 * Callback for freeing an URB.
43 * @param pUrb The URB to free.
44 */
45static DECLCALLBACK(void) vusbRhFreeUrb(PVUSBURB pUrb)
46{
47 /*
48 * Assert sanity.
49 */
50 vusbUrbAssert(pUrb);
51 PVUSBROOTHUB pRh = (PVUSBROOTHUB)pUrb->pVUsb->pvFreeCtx;
52 Assert(pRh);
53
54 Assert(pUrb->enmState != VUSBURBSTATE_FREE);
55
56 /*
57 * Free the URB description (logging builds only).
58 */
59 if (pUrb->pszDesc)
60 {
61 RTStrFree(pUrb->pszDesc);
62 pUrb->pszDesc = NULL;
63 }
64
65 /* The URB comes from the roothub if there is no device (invalid address). */
66 if (pUrb->pVUsb->pDev)
67 {
68 PVUSBDEV pDev = pUrb->pVUsb->pDev;
69
70 vusbUrbPoolFree(&pUrb->pVUsb->pDev->UrbPool, pUrb);
71 vusbDevRelease(pDev);
72 }
73 else
74 vusbUrbPoolFree(&pRh->Hub.Dev.UrbPool, pUrb);
75}
76
77/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnSubmitUrb} */
78static DECLCALLBACK(int) vusbRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, PPDMLED pLed)
79{
80 PVUSBROOTHUB pRh = VUSBIROOTHUBCONNECTOR_2_VUSBROOTHUB(pInterface);
81 STAM_PROFILE_START(&pRh->StatSubmitUrb, a);
82
83 /* If there is a sniffer on the roothub record the URB there. */
84 if (pRh->hSniffer != VUSBSNIFFER_NIL)
85 {
86 int rc = VUSBSnifferRecordEvent(pRh->hSniffer, pUrb, VUSBSNIFFEREVENT_SUBMIT);
87 if (RT_FAILURE(rc))
88 LogRel(("VUSB: Capturing URB submit event on the root hub failed with %Rrc\n", rc));
89 }
90
91 /*
92 * The device was resolved when we allocated the URB.
93 * Submit it to the device if we found it, if not fail with device-not-ready.
94 */
95 int rc;
96 if ( pUrb->pVUsb->pDev
97 && pUrb->pVUsb->pDev->pUsbIns)
98 {
99 switch (pUrb->enmDir)
100 {
101 case VUSBDIRECTION_IN:
102 pLed->Asserted.s.fReading = pLed->Actual.s.fReading = 1;
103 rc = vusbUrbSubmit(pUrb);
104 pLed->Actual.s.fReading = 0;
105 break;
106 case VUSBDIRECTION_OUT:
107 pLed->Asserted.s.fWriting = pLed->Actual.s.fWriting = 1;
108 rc = vusbUrbSubmit(pUrb);
109 pLed->Actual.s.fWriting = 0;
110 break;
111 default:
112 rc = vusbUrbSubmit(pUrb);
113 break;
114 }
115
116 if (RT_FAILURE(rc))
117 {
118 LogFlow(("vusbRhSubmitUrb: freeing pUrb=%p\n", pUrb));
119 pUrb->pVUsb->pfnFree(pUrb);
120 }
121 }
122 else
123 {
124 vusbDevRetain(&pRh->Hub.Dev);
125 pUrb->pVUsb->pDev = &pRh->Hub.Dev;
126 Log(("vusb: pRh=%p: SUBMIT: Address %i not found!!!\n", pRh, pUrb->DstAddress));
127
128 pUrb->enmState = VUSBURBSTATE_REAPED;
129 pUrb->enmStatus = VUSBSTATUS_DNR;
130 vusbUrbCompletionRh(pUrb);
131 rc = VINF_SUCCESS;
132 }
133
134 STAM_PROFILE_STOP(&pRh->StatSubmitUrb, a);
135 return rc;
136}
137
138//XENO: START HERE
139/**
140 * Service a general transport descriptor.
141 */
142static bool ohciR3ServiceTd(POHCI pThis, VUSBXFERTYPE enmType, PCOHCIED pEd, uint32_t EdAddr, uint32_t TdAddr,
143 uint32_t *pNextTdAddr, const char *pszListName)
144{
145 RT_NOREF(pszListName);
146
147 /*
148 * Read the TD and setup the buffer data.
149 */
150 OHCITD Td;
151 ohciR3ReadTd(pThis, TdAddr, &Td);
152 OHCIBUF Buf;
153 ohciR3BufInit(&Buf, Td.cbp, Td.be);
154
155 *pNextTdAddr = Td.NextTD & ED_PTR_MASK;
156
157 /*
158 * Determine the direction.
159 */
160 VUSBDIRECTION enmDir;
161 switch (pEd->hwinfo & ED_HWINFO_DIR)
162 {
163 case ED_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
164 case ED_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
165 default:
166 switch (Td.hwinfo & TD_HWINFO_DIR)
167 {
168 case TD_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
169 case TD_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
170 case 0: enmDir = VUSBDIRECTION_SETUP; break;
171 default:
172 Log(("ohciR3ServiceTd: Invalid direction!!!! Td.hwinfo=%#x Ed.hwdinfo=%#x\n", Td.hwinfo, pEd->hwinfo));
173 ohciR3RaiseUnrecoverableError(pThis, 2);
174 return false;
175 }
176 break;
177 }
178
179 pThis->fIdle = false; /* Mark as active */
180
181 /*
182 * Allocate and initialize a new URB.
183 */
184 PVUSBURB pUrb = VUSBIRhNewUrb(pThis->RootHub.pIRhConn, pEd->hwinfo & ED_HWINFO_FUNCTION, NULL,
185 enmType, enmDir, Buf.cbTotal, 1, NULL);
186 if (!pUrb)
187 return false; /* retry later... */
188
189 pUrb->EndPt = (pEd->hwinfo & ED_HWINFO_ENDPOINT) >> ED_HWINFO_ENDPOINT_SHIFT;
190 pUrb->fShortNotOk = !(Td.hwinfo & TD_HWINFO_ROUNDING);
191 pUrb->enmStatus = VUSBSTATUS_OK;
192 pUrb->pHci->EdAddr = EdAddr;
193 pUrb->pHci->fUnlinked = false;
194 pUrb->pHci->cTds = 1;
195 pUrb->paTds[0].TdAddr = TdAddr;
196 pUrb->pHci->u32FrameNo = pThis->HcFmNumber;
197 AssertCompile(sizeof(pUrb->paTds[0].TdCopy) >= sizeof(Td));
198 memcpy(pUrb->paTds[0].TdCopy, &Td, sizeof(Td));
199
200 /* copy data if out bound transfer. */
201 pUrb->cbData = Buf.cbTotal;
202 if ( Buf.cbTotal
203 && Buf.cVecs > 0
204 && enmDir != VUSBDIRECTION_IN)
205 {
206 /* Be paranoid. */ //XENO: That's what I like to hear! :D
207 if ( Buf.aVecs[0].cb > pUrb->cbData
208 || ( Buf.cVecs > 1
209 && Buf.aVecs[1].cb > (pUrb->cbData - Buf.aVecs[0].cb)))
210 {
211 ohciR3RaiseUnrecoverableError(pThis, 3);
212 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
213 return false;
214 }
215
216 ohciR3PhysRead(pThis, Buf.aVecs[0].Addr, pUrb->abData, Buf.aVecs[0].cb);
217 if (Buf.cVecs > 1)
218 ohciR3PhysRead(pThis, Buf.aVecs[1].Addr, &pUrb->abData[Buf.aVecs[0].cb], Buf.aVecs[1].cb);
219 }
220
221 /*
222 * Submit the URB.
223 */
224 ohciR3InFlightAdd(pThis, TdAddr, pUrb);
225 Log(("%s: ohciR3ServiceTd: submitting TdAddr=%#010x EdAddr=%#010x cbData=%#x\n",
226 pUrb->pszDesc, TdAddr, EdAddr, pUrb->cbData));
227
228 ohciR3Unlock(pThis);
229 int rc = VUSBIRhSubmitUrb(pThis->RootHub.pIRhConn, pUrb, &pThis->RootHub.Led);
230 ohciR3Lock(pThis);
231 if (RT_SUCCESS(rc))
232 return true;
233
234 /* Failure cleanup. Can happen if we're still resetting the device or out of resources. */
235 Log(("ohciR3ServiceTd: failed submitting TdAddr=%#010x EdAddr=%#010x pUrb=%p!!\n",
236 TdAddr, EdAddr, pUrb));
237 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
238 ohciR3InFlightRemove(pThis, TdAddr);
239 return false;
240}
We can see that at line 184 in ohciR3ServiceTd function, a PVUSBURB object pUrb its being allocated via VUSBIRhNewUrb(). Long story short, a logical error exist which does not track the lifetime of this object across function boundaries.
At line 229 VUSBIRhSubmitUrb gets invoked, as as we can see pThis->RootHub.pIRhConn its passed as its first parameter and pUrb its passed as its second parameter. VUSBIRhSubmitUrb will endup invoking vusbRhSubmitUrb, in which we can see at line 112, if vusbUrbSubmit fails an error code checked at line 116 will provoke pUrb to be freed at line 119, and the function will terminate returning the error code. Back at ohciR3ServiceTd at line 231 we see that if the return code from VUSBIRhSubmitUrb succeeded, the function will end returning true.
On the other hand, if VUSBIRhSubmitUrb failed pUrb would have been already freed as previously mentioned. The function will proceed until a VUSBIRhFreeUrb invocation which the same two parameters will be passed as it did on vusbRhSubmitUrb–that is pThis->RootHub.pIRhConn and pUrb–which will result in attempting to free pUrb a second time, showcasing a double-free vulnerability.
Type Confusion
The use of attacker-controlled data to change the interpretation of a data’s type
Common Causes
#
- Design paradigms that allow a variable ot struct member to be interpreted as a different type, depending on the circumstances.
- Object Oriented Programming
- Sub-type of the aforementioned design paradigm
- I.e: The ability to have C++ objects interpreted as multiple parents/children in a class hierarchy
C++ Casting
#
- C-style cast (i.e.
foo a = (foo*)b)
- Not safe
static_cast<TargetClass>(Object)
- Checked at compile time but not at runtime
- Not-fafe
dynamic_cast<TargetClass>(Object)
- Checked at runtime
- Safe, but it causes performance overhead
reinterpret_cast<TargetClass>(Object)
- Not safe
C++ Type Confusion
#
- Up-casts are allowed
- Down-casting objects that have been previously up-casted is not allowed
Cat *c = new Cat();
Animal *a = static_cast<Animal>(c); // This is allowed
Dog *d = static_cast<Dog>(a); // This is not allowed
Examples:
#
Note: Most of these examples are vulnerabilities found in XNU, enabled by time-sensitive context-switching which specific side-effects manifested in type-confusions as product of interpeting a specific member of an object as of a different type
CVE-2021-30857
#
1struct ipc_object {
2 ipc_object_bits_t io_bits;
3 ipc_object_refs_t io_references;
4 lck_spin_t io_lock_data;
5} __attribute__((aligned(8)));
6
7//XENO: ie_object is a pointer to the ip_object field within the port that this ipc_entry references
8//XENO: Which is why ip_object_to_port(entry->ie_object) returns a pointer to a port
9struct ipc_entry {
10 struct ipc_object *XNU_PTRAUTH_SIGNED_PTR("ipc_entry.ie_object") ie_object;
11 ipc_entry_bits_t ie_bits;
12 uint32_t ie_dist : IPC_ENTRY_DIST_BITS;
13 mach_port_index_t ie_index : IPC_ENTRY_INDEX_BITS;
14 union {
15 mach_port_index_t next; /* next in freelist, or... */
16 ipc_table_index_t request; /* dead name request notify */
17 } index;
18};
19
20struct ipc_port {
21 /*
22 * Initial sub-structure in common with ipc_pset
23 * First element is an ipc_object second is a
24 * message queue
25 */
26 struct ipc_object ip_object;
27 struct ipc_mqueue ip_messages;
28
29 union {
30 struct ipc_space * receiver;
31 struct ipc_port * destination;
32 ipc_port_timestamp_t timestamp;
33 } data;
34
35 /* update host_request_notification if this union is changed */
36 union {
37 ipc_kobject_t XNU_PTRAUTH_SIGNED_PTR("ipc_port.kobject") kobject;
38 ipc_kobject_label_t XNU_PTRAUTH_SIGNED_PTR("ipc_port.kolabel") kolabel;
39 ipc_importance_task_t imp_task;
40 ipc_port_t sync_inheritor_port;
41 struct knote *sync_inheritor_knote;
42 struct turnstile *sync_inheritor_ts;
43 } kdata;
44 //...
45}
46
47//XENO: "Calling host_request_notification adds the port to a doubly linked list
48//XENO: of ports that will receive date/time change notifications." from [5]
49//XENO: This function can be called on demand by userspace
50kern_return_t
51host_request_notification(
52 host_t host,
53 host_flavor_t notify_type,
54 ipc_port_t port)
55{
56 host_notify_t entry;
57
58 if (host == HOST_NULL)
59 return (KERN_INVALID_ARGUMENT);
60
61 if (!IP_VALID(port))
62 return (KERN_INVALID_CAPABILITY);
63
64 if (notify_type > HOST_NOTIFY_TYPE_MAX || notify_type < 0)
65 return (KERN_INVALID_ARGUMENT);
66
67 entry = (host_notify_t)zalloc(host_notify_zone);
68 if (entry == NULL)
69 return (KERN_RESOURCE_SHORTAGE);
70
71 lck_mtx_lock(&host_notify_lock);
72
73 ip_lock(port);
74 if (!ip_active(port) || port->ip_tempowner || ip_kotype(port) != IKOT_NONE) {
75 ip_unlock(port);
76
77 lck_mtx_unlock(&host_notify_lock);
78 zfree(host_notify_zone, entry);
79
80 return (KERN_FAILURE);
81 }
82
83 entry->port = port;
84 ipc_kobject_set_atomically(port, (ipc_kobject_t)entry, IKOT_HOST_NOTIFY); //XENO: This changes the port.kobject to entry,
85 ip_unlock(port); //XENO: and sets IKOT_HOST_NOTIFY in port.ip_object.io_bits
86
87 enqueue_tail(&host_notify_queue[notify_type], (queue_entry_t)entry); //XENO: Add to linked list of things to notify
88 lck_mtx_unlock(&host_notify_lock);
89
90 return (KERN_SUCCESS);
91}
92
93/*
94 * Routine: ipc_right_copyin
95 * Purpose:
96 * Copyin a capability from a space.
97 * If successful, the caller gets a ref
98 * for the resulting object, unless it is IO_DEAD,
99 * and possibly a send-once right which should
100 * be used in a port-deleted notification.
101 *
102 * If deadok is not TRUE, the copyin operation
103 * will fail instead of producing IO_DEAD.
104 *
105 * The entry is never deallocated (except
106 * when KERN_INVALID_NAME), so the caller
107 * should deallocate the entry if its type
108 * is MACH_PORT_TYPE_NONE.
109 * Conditions:
110 * The space is write-locked and active.
111 * Returns:
112 * KERN_SUCCESS Acquired an object, possibly IO_DEAD.
113 * KERN_INVALID_RIGHT Name doesn't denote correct right.
114 * KERN_INVALID_CAPABILITY Trying to move an kobject port or an immovable right,
115 * or moving the last ref of pinned right
116 * KERN_INVALID_ARGUMENT Port is unguarded or guard mismatch
117 */
118//XENO: Start analysis here
119kern_return_t
120ipc_right_copyin(
121 ipc_space_t space,
122 mach_port_name_t name,
123 ipc_entry_t entry,
124 mach_msg_type_name_t msgt_name,
125 ipc_object_copyin_flags_t flags,
126 ipc_object_t *objectp,
127 ipc_port_t *sorightp,
128 ipc_port_t *releasep,
129 int *assertcntp,
130 mach_port_context_t context,
131 mach_msg_guard_flags_t *guard_flags)
132{
133 ipc_entry_bits_t bits;
134 ipc_port_t port;
135 kern_return_t kr;
136 boolean_t deadok = !!(flags & IPC_OBJECT_COPYIN_FLAGS_DEADOK);
137 boolean_t allow_imm_send = !!(flags & IPC_OBJECT_COPYIN_FLAGS_ALLOW_IMMOVABLE_SEND);
138 boolean_t soft_fail_imm_send = !!(flags & IPC_OBJECT_COPYIN_FLAGS_SOFT_FAIL_IMMOVABLE_SEND);
139
140 *releasep = IP_NULL;
141 *assertcntp = 0;
142
143 bits = entry->ie_bits;
144
145 assert(is_active(space));
146
147 switch (msgt_name) {
148 case MACH_MSG_TYPE_MAKE_SEND: {
149 if ((bits & MACH_PORT_TYPE_RECEIVE) == 0) {
150 goto invalid_right;
151 }
152
153 port = ip_object_to_port(entry->ie_object);
154 assert(port != IP_NULL);
155
156 ip_lock(port);
157 assert(port->ip_receiver_name == name);
158 assert(port->ip_receiver == space);
159
160 ipc_port_make_send_locked(port);
161 ip_unlock(port);
162
163 *objectp = ip_to_object(port);
164 *sorightp = IP_NULL;
165 break;
166 }
167
168 case MACH_MSG_TYPE_MAKE_SEND_ONCE: {
169 if ((bits & MACH_PORT_TYPE_RECEIVE) == 0) {
170 goto invalid_right;
171 }
172
173 port = ip_object_to_port(entry->ie_object);
174 assert(port != IP_NULL);
175
176 ip_lock(port);
177 require_ip_active(port);
178 assert(port->ip_receiver_name == name);
179 assert(port->ip_receiver == space);
180
181 ipc_port_make_sonce_locked(port);
182 ip_unlock(port);
183
184 *objectp = ip_to_object(port);
185 *sorightp = IP_NULL;
186 break;
187 }
188
189 case MACH_MSG_TYPE_MOVE_RECEIVE: {
190 ipc_port_t request = IP_NULL;
191
192 if ((bits & MACH_PORT_TYPE_RECEIVE) == 0) {
193 goto invalid_right;
194 }
195
196 /*
197 * Disallow moving receive-right kobjects/kolabel, e.g. mk_timer ports
198 * The ipc_port structure uses the kdata union of kobject and
199 * imp_task exclusively. Thus, general use of a kobject port as
200 * a receive right can cause type confusion in the importance
201 * code.
202 */
203 if (io_is_kobject(entry->ie_object) ||
204 io_is_kolabeled(entry->ie_object)) {
205 /*
206 * Distinguish an invalid right, e.g., trying to move
207 * a send right as a receive right, from this
208 * situation which is, "This is a valid receive right,
209 * but it's also a kobject and you can't move it."
210 */
211 mach_port_guard_exception(name, 0, 0, kGUARD_EXC_IMMOVABLE);
212 return KERN_INVALID_CAPABILITY;
213 }
214
215 port = ip_object_to_port(entry->ie_object);
216 assert(port != IP_NULL);
217
218 ip_lock(port);
219 require_ip_active(port);
220 assert(port->ip_receiver_name == name);
221 assert(port->ip_receiver == space);
222
223 if (port->ip_immovable_receive || port->ip_specialreply) {
224 assert(port->ip_receiver != ipc_space_kernel);
225 ip_unlock(port);
226 assert(current_task() != kernel_task);
227 mach_port_guard_exception(name, 0, 0, kGUARD_EXC_IMMOVABLE);
228 return KERN_INVALID_CAPABILITY;
229 }
230
231 if (guard_flags != NULL) {
232 kr = ipc_right_copyin_check_guard_locked(name, port, context, guard_flags);
233 if (kr != KERN_SUCCESS) {
234 ip_unlock(port);
235 return kr;
236 }
237 }
238
239 if (bits & MACH_PORT_TYPE_SEND) {
240 assert(IE_BITS_TYPE(bits) ==
241 MACH_PORT_TYPE_SEND_RECEIVE);
242 assert(IE_BITS_UREFS(bits) > 0);
243 assert(port->ip_srights > 0);
244
245 ipc_hash_insert(space, ip_to_object(port),
246 name, entry);
247 ip_reference(port);
248 } else {
249 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_RECEIVE);
250 assert(IE_BITS_UREFS(bits) == 0);
251
252 request = ipc_right_request_cancel_macro(space, port,
253 name, entry);
254 entry->ie_object = IO_NULL;
255 }
256 entry->ie_bits = bits & ~MACH_PORT_TYPE_RECEIVE;
257 entry->ie_bits |= MACH_PORT_TYPE_EX_RECEIVE;
258 ipc_entry_modified(space, name, entry);
259
260 /* ipc_port_clear_receiver unguards the port and clears the ip_immovable_receive bit */
261 (void)ipc_port_clear_receiver(port, FALSE); /* don't destroy the port/mqueue */
262 if (guard_flags != NULL) {
263 /* this flag will be cleared during copyout */
264 *guard_flags = *guard_flags | MACH_MSG_GUARD_FLAGS_UNGUARDED_ON_SEND;
265 }
266
267#if IMPORTANCE_INHERITANCE
268 /*
269 * Account for boosts the current task is going to lose when
270 * copying this right in. Tempowner ports have either not
271 * been accounting to any task (and therefore are already in
272 * "limbo" state w.r.t. assertions) or to some other specific
273 * task. As we have no way to drop the latter task's assertions
274 * here, We'll deduct those when we enqueue it on its
275 * destination port (see ipc_port_check_circularity()).
276 */
277 if (port->ip_tempowner == 0) {
278 assert(IIT_NULL == port->ip_imp_task);
279
280 /* ports in limbo have to be tempowner */
281 port->ip_tempowner = 1;
282 *assertcntp = port->ip_impcount;
283 }
284#endif /* IMPORTANCE_INHERITANCE */
285
286 ip_unlock(port);
287
288 *objectp = ip_to_object(port);
289 *sorightp = request;
290 break;
291 }
292
293 case MACH_MSG_TYPE_COPY_SEND: {
294 if (bits & MACH_PORT_TYPE_DEAD_NAME) {
295 goto copy_dead;
296 }
297
298 /* allow for dead send-once rights */
299
300 if ((bits & MACH_PORT_TYPE_SEND_RIGHTS) == 0) {
301 goto invalid_right;
302 }
303
304 assert(IE_BITS_UREFS(bits) > 0);
305
306 port = ip_object_to_port(entry->ie_object);
307 assert(port != IP_NULL);
308
309 if (ipc_right_check(space, port, name, entry, IPC_OBJECT_COPYIN_FLAGS_NONE)) {
310 bits = entry->ie_bits;
311 *releasep = port;
312 goto copy_dead;
313 }
314 /* port is locked and active */
315
316 if ((bits & MACH_PORT_TYPE_SEND) == 0) {
317 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_SEND_ONCE);
318 assert(port->ip_sorights > 0);
319
320 ip_unlock(port);
321 goto invalid_right;
322 }
323
324 if (!allow_imm_send && port->ip_immovable_send) {
325 if (!ip_is_control(port) || immovable_control_port_enabled) {
326 ip_unlock(port);
327 if (!soft_fail_imm_send) {
328 mach_port_guard_exception_immovable(name, port, MPG_FLAGS_NONE);
329 }
330 return KERN_INVALID_CAPABILITY;
331 }
332 }
333
334 ipc_port_copy_send_locked(port);
335 ip_unlock(port);
336
337 *objectp = ip_to_object(port);
338 *sorightp = IP_NULL;
339 break;
340 }
341
342 case MACH_MSG_TYPE_MOVE_SEND: {
343 ipc_port_t request = IP_NULL;
344
345 if (bits & MACH_PORT_TYPE_DEAD_NAME) {
346 goto move_dead;
347 }
348
349 /* allow for dead send-once rights */
350
351 if ((bits & MACH_PORT_TYPE_SEND_RIGHTS) == 0) {
352 goto invalid_right;
353 }
354
355 assert(IE_BITS_UREFS(bits) > 0);
356
357 port = ip_object_to_port(entry->ie_object);
358 assert(port != IP_NULL);
359
360 if (ipc_right_check(space, port, name, entry, IPC_OBJECT_COPYIN_FLAGS_NONE)) {
361 bits = entry->ie_bits;
362 *releasep = port;
363 goto move_dead;
364 }
365 /* port is locked and active */
366
367 if ((bits & MACH_PORT_TYPE_SEND) == 0) {
368 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_SEND_ONCE);
369 assert(port->ip_sorights > 0);
370 ip_unlock(port);
371 goto invalid_right;
372 }
373
374 if (!allow_imm_send && port->ip_immovable_send) {
375 if (!ip_is_control(port) || immovable_control_port_enabled) {
376 ip_unlock(port);
377 if (!soft_fail_imm_send) {
378 mach_port_guard_exception_immovable(name, port, MPG_FLAGS_NONE);
379 }
380 return KERN_INVALID_CAPABILITY;
381 }
382 }
383
384 if (IE_BITS_UREFS(bits) == 1) {
385 assert(port->ip_srights > 0);
386 if (bits & MACH_PORT_TYPE_RECEIVE) {
387 assert(port->ip_receiver_name == name);
388 assert(port->ip_receiver == space);
389 assert(IE_BITS_TYPE(bits) ==
390 MACH_PORT_TYPE_SEND_RECEIVE);
391 assert(port->ip_pinned == 0);
392
393 ip_reference(port);
394 } else {
395 assert(IE_BITS_TYPE(bits) ==
396 MACH_PORT_TYPE_SEND);
397
398 request = ipc_right_request_cancel_macro(space, port,
399 name, entry);
400 ipc_hash_delete(space, ip_to_object(port),
401 name, entry);
402 entry->ie_object = IO_NULL;
403 /* transfer entry's reference to caller */
404 }
405 entry->ie_bits = bits & ~
406 (IE_BITS_UREFS_MASK | MACH_PORT_TYPE_SEND);
407 } else {
408 ipc_port_copy_send_locked(port);
409 /* if urefs are pegged due to overflow, leave them pegged */
410 if (IE_BITS_UREFS(bits) < MACH_PORT_UREFS_MAX) {
411 entry->ie_bits = bits - 1; /* decrement urefs */
412 }
413 }
414
415 ipc_entry_modified(space, name, entry);
416 ip_unlock(port);
417
418 *objectp = ip_to_object(port);
419 *sorightp = request;
420 break;
421 }
422
423 case MACH_MSG_TYPE_MOVE_SEND_ONCE: {
424 ipc_port_t request;
425
426 if (bits & MACH_PORT_TYPE_DEAD_NAME) {
427 goto move_dead;
428 }
429
430 /* allow for dead send rights */
431
432 if ((bits & MACH_PORT_TYPE_SEND_RIGHTS) == 0) {
433 goto invalid_right;
434 }
435
436 assert(IE_BITS_UREFS(bits) > 0);
437
438 port = ip_object_to_port(entry->ie_object);
439 assert(port != IP_NULL);
440
441 if (ipc_right_check(space, port, name, entry, flags)) {
442 bits = entry->ie_bits;
443 *releasep = port;
444 goto move_dead;
445 }
446 /*
447 * port is locked, but may not be active:
448 * Allow copyin of inactive ports with no dead name request and treat it
449 * as if the copyin of the port was successful and port became inactive
450 * later.
451 */
452
453 if ((bits & MACH_PORT_TYPE_SEND_ONCE) == 0) {
454 assert(bits & MACH_PORT_TYPE_SEND);
455 assert(port->ip_srights > 0);
456
457 ip_unlock(port);
458 goto invalid_right;
459 }
460
461 if (!allow_imm_send && port->ip_immovable_send) {
462 if (!ip_is_control(port) || immovable_control_port_enabled) {
463 ip_unlock(port);
464 if (!soft_fail_imm_send) {
465 mach_port_guard_exception_immovable(name, port, MPG_FLAGS_NONE);
466 }
467 return KERN_INVALID_CAPABILITY;
468 }
469 }
470
471 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_SEND_ONCE);
472 assert(IE_BITS_UREFS(bits) == 1);
473 assert(port->ip_sorights > 0);
474
475 request = ipc_right_request_cancel_macro(space, port, name, entry);
476 ip_unlock(port);
477
478 entry->ie_object = IO_NULL;
479 entry->ie_bits = bits & ~
480 (IE_BITS_UREFS_MASK | MACH_PORT_TYPE_SEND_ONCE);
481 ipc_entry_modified(space, name, entry);
482 *objectp = ip_to_object(port);
483 *sorightp = request;
484 break;
485 }
486
487 default:
488invalid_right:
489 return KERN_INVALID_RIGHT;
490 }
491
492 return KERN_SUCCESS;
493
494copy_dead:
495 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_DEAD_NAME);
496 assert(IE_BITS_UREFS(bits) > 0);
497 assert(entry->ie_request == IE_REQ_NONE);
498 assert(entry->ie_object == 0);
499
500 if (!deadok) {
501 goto invalid_right;
502 }
503
504 *objectp = IO_DEAD;
505 *sorightp = IP_NULL;
506 return KERN_SUCCESS;
507
508move_dead:
509 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_DEAD_NAME);
510 assert(IE_BITS_UREFS(bits) > 0);
511 assert(entry->ie_request == IE_REQ_NONE);
512 assert(entry->ie_object == 0);
513
514 if (!deadok) {
515 goto invalid_right;
516 }
517
518 if (IE_BITS_UREFS(bits) == 1) {
519 bits &= ~MACH_PORT_TYPE_DEAD_NAME;
520 }
521 /* if urefs are pegged due to overflow, leave them pegged */
522 if (IE_BITS_UREFS(bits) < MACH_PORT_UREFS_MAX) {
523 entry->ie_bits = bits - 1; /* decrement urefs */
524 }
525 ipc_entry_modified(space, name, entry);
526 *objectp = IO_DEAD;
527 *sorightp = IP_NULL;
528 return KERN_SUCCESS;
529}
This is an XNU vulnerability. Therefore, when looking at the sample code above, remember that preemption and context switches can occur at nearly any instruction, unless preemption has been explicitly disabled. Objects not protected by locks or other synchronization mechanisms can be accessed or modified concurrently by other threads, potentially leading to race conditions.
That being said, lets take a look at the structure of ipc_port. We can notice a kdata member being a union type. In which field of type ipc_kobject_t kobject and a ipc_importance_task_t imp_task are held.
Now lets look at host_request_notification At the end of this function we can see a call to ipc_kobject_set_atomically this function essentially set the port.ip_object.io_bits to set the flag IKOT_HOST_NOTIFY, setting the port.kobject to a type of host_notify_entry. In other words, the host_request_notification method allows userspace to take a regular, userspace-owned mach port and set the kobject field to point to a host_notify_entry object.
If we look at the comments at line 196 at ipc_right_copyin, it describes the purpose of the subsequent check, checking if the ipc_entry_t->ie_object (which is a pointer to a ipc_port), is of type kobject or kolabeled.
However due to a context-switch, the funtion host_notify_entry could change the same port object to hold a host_notify_entry in its kdata.kobject field, and cause a type confusion when the context-switch returns back to ipc_right_copyin when it should expect the port to hold a kdata.ipc_importance_task_t instead.
CVE-2020-3853
#
1//XENO: If you look at the documentation for the userspace version of this function
2//XENO: (found in osfmk/man/mach_port_destroy.html) it says:
3//XENO: "The mach_port_destroy function de-allocates all rights denoted by a name.
4//XENO: The name becomes immediately available for reuse."
5/*
6 * Routine: mach_port_destroy [kernel call]
7 * Purpose:
8 * Cleans up and destroys all rights denoted by a name
9 * in a space. The destruction of a receive right
10 * destroys the port, unless a port-destroyed request
11 * has been made for it; the destruction of a port-set right
12 * destroys the port set.
13 * Conditions:
14 * Nothing locked.
15 * Returns:
16 * KERN_SUCCESS The name is destroyed.
17 * KERN_INVALID_TASK The space is null.
18 * KERN_INVALID_TASK The space is dead.
19 * KERN_INVALID_NAME The name doesn't denote a right.
20 */
21
22kern_return_t
23mach_port_destroy(
24 ipc_space_t space,
25 mach_port_name_t name)
26{
27 ipc_entry_t entry;
28 kern_return_t kr;
29
30 if (space == IS_NULL)
31 return KERN_INVALID_TASK;
32
33 if (!MACH_PORT_VALID(name))
34 return KERN_SUCCESS;
35
36 kr = ipc_right_lookup_write(space, name, &entry);
37 if (kr != KERN_SUCCESS) {
38 mach_port_guard_exception(name, 0, 0, kGUARD_EXC_INVALID_NAME);
39 return kr;
40 }
41 /* space is write-locked and active */
42
43 kr = ipc_right_destroy(space, name, entry, TRUE, 0); /* unlocks space */
44 return kr;
45}
46
47//XENO: See the userspace-side documentation in osfmk/man/mach_port_insert_right.html
48//XENO: For more information about how this function is intended to be used
49/*
50 * Routine: mach_port_insert_right [kernel call]
51 * Purpose:
52 * Inserts a right into a space, as if the space
53 * voluntarily received the right in a message,
54 * except that the right gets the specified name.
55 * Conditions:
56 * Nothing locked.
57 * Returns:
58 * KERN_SUCCESS Inserted the right.
59 * KERN_INVALID_TASK The space is null.
60 * KERN_INVALID_TASK The space is dead.
61 * KERN_INVALID_VALUE The name isn't a legal name.
62 * KERN_NAME_EXISTS The name already denotes a right.
63 * KERN_INVALID_VALUE Message doesn't carry a port right.
64 * KERN_INVALID_CAPABILITY Port is null or dead.
65 * KERN_UREFS_OVERFLOW Urefs limit would be exceeded.
66 * KERN_RIGHT_EXISTS Space has rights under another name.
67 * KERN_RESOURCE_SHORTAGE Couldn't allocate memory.
68 */
69
70kern_return_t
71mach_port_insert_right(
72 ipc_space_t space,
73 mach_port_name_t name,
74 ipc_port_t poly,
75 mach_msg_type_name_t polyPoly)
76{
77 if (space == IS_NULL) {
78 return KERN_INVALID_TASK;
79 }
80
81 if (!MACH_PORT_VALID(name) ||
82 !MACH_MSG_TYPE_PORT_ANY_RIGHT(polyPoly)) {
83 return KERN_INVALID_VALUE;
84 }
85
86 if (!IP_VALID(poly)) {
87 return KERN_INVALID_CAPABILITY;
88 }
89
90 return ipc_object_copyout_name(space, ip_to_object(poly),
91 polyPoly, name);
92}
93
94/*
95 * Routine: ipc_object_translate
96 * Purpose:
97 * Look up an object in a space.
98 * Conditions:
99 * Nothing locked before. If successful, the object
100 * is returned active and locked. The caller doesn't get a ref.
101 * Returns:
102 * KERN_SUCCESS Object returned locked.
103 * KERN_INVALID_TASK The space is dead.
104 * KERN_INVALID_NAME The name doesn't denote a right
105 * KERN_INVALID_RIGHT Name doesn't denote the correct right
106 */
107kern_return_t
108ipc_object_translate(
109 ipc_space_t space,
110 mach_port_name_t name,
111 mach_port_right_t right,
112 ipc_object_t *objectp)
113{
114 ipc_entry_t entry;
115 ipc_object_t object;
116 kern_return_t kr;
117
118 if (!MACH_PORT_RIGHT_VALID_TRANSLATE(right)) {
119 return KERN_INVALID_RIGHT;
120 }
121
122 kr = ipc_right_lookup_read(space, name, &entry);
123 if (kr != KERN_SUCCESS) {
124 return kr;
125 }
126 /* space is read-locked and active */
127
128 if ((entry->ie_bits & MACH_PORT_TYPE(right)) == MACH_PORT_TYPE_NONE) {
129 is_read_unlock(space);
130 return KERN_INVALID_RIGHT;
131 }
132
133 object = entry->ie_object;
134 assert(object != IO_NULL);
135
136 io_lock(object);
137 is_read_unlock(space);
138
139 if (!io_active(object)) {
140 io_unlock(object);
141 return KERN_INVALID_NAME;
142 }
143
144 *objectp = object;
145 return KERN_SUCCESS;
146}
147
148static inline kern_return_t
149ipc_port_translate(
150 ipc_space_t space,
151 mach_port_name_t name,
152 mach_port_right_t right,
153 ipc_port_t *portp)
154{
155 ipc_object_t object;
156 kern_return_t kr;
157
158 kr = ipc_object_translate(space, name, right, &object);
159 *portp = (kr == KERN_SUCCESS) ? ip_object_to_port(object) : IP_NULL;
160 return kr;
161}
162
163#define ipc_port_translate_receive(space, name, portp) \
164 ipc_port_translate((space), (name), MACH_PORT_RIGHT_RECEIVE, portp)
165
166static mach_port_qos_t mk_timer_qos = {
167 FALSE, TRUE, 0, sizeof (mk_timer_expire_msg_t)
168};
169
170/*
171 * Routine: mach_port_allocate_internal [kernel private]
172 * Purpose:
173 * Allocates a right in a space. Supports all of the
174 * special cases, a specific name, a real-time port, etc.
175 * The name may be any legal name in the space that doesn't
176 * currently denote a right.
177 * Conditions:
178 * Nothing locked.
179 * Returns:
180 * KERN_SUCCESS The right is allocated.
181 * KERN_INVALID_TASK The space is null.
182 * KERN_INVALID_TASK The space is dead.
183 * KERN_INVALID_VALUE "right" isn't a legal kind of right.
184 * KERN_RESOURCE_SHORTAGE Couldn't allocate memory.
185 * KERN_NO_SPACE No room in space for another right.
186 */
187kern_return_t
188mach_port_allocate_internal(
189 ipc_space_t space,
190 mach_port_right_t right,
191 mach_port_qos_t *qosp,
192 mach_port_name_t *namep)
193{
194 kern_return_t kr;
195
196 assert(space != IS_NULL);
197
198 switch (right) {
199 case MACH_PORT_RIGHT_RECEIVE:
200 {
201 ipc_kmsg_t kmsg = IKM_NULL;
202 ipc_port_t port;
203
204 /*
205 * For in-kernel uses, only allow small (from the kmsg zone)
206 * preallocated messages for the port.
207 */
208 if (qosp->prealloc) {
209 mach_msg_size_t size = qosp->len;
210
211 if (size > IKM_SAVED_MSG_SIZE - MAX_TRAILER_SIZE) {
212 panic("mach_port_allocate_internal: too large a prealloc kmsg");
213 }
214 kmsg = (ipc_kmsg_t)ipc_kmsg_prealloc(size + MAX_TRAILER_SIZE);
215 if (kmsg == IKM_NULL) {
216 return KERN_RESOURCE_SHORTAGE;
217 }
218 }
219
220 if (qosp->name) {
221 kr = ipc_port_alloc_name(space, IPC_PORT_INIT_MESSAGE_QUEUE,
222 *namep, &port);
223 } else {
224 kr = ipc_port_alloc(space, IPC_PORT_INIT_MESSAGE_QUEUE,
225 namep, &port);
226 }
227 if (kr == KERN_SUCCESS) {
228 if (kmsg != IKM_NULL) {
229 ipc_kmsg_set_prealloc(kmsg, port);
230 }
231 ip_unlock(port);
232 } else if (kmsg != IKM_NULL) {
233 ipc_kmsg_free(kmsg);
234 }
235 break;
236 }
237
238 case MACH_PORT_RIGHT_PORT_SET:
239 {
240 ipc_pset_t pset;
241
242 if (qosp->name) {
243 kr = ipc_pset_alloc_name(space, *namep, &pset);
244 } else {
245 kr = ipc_pset_alloc(space, namep, &pset);
246 }
247 if (kr == KERN_SUCCESS) {
248 ips_unlock(pset);
249 }
250 break;
251 }
252
253 case MACH_PORT_RIGHT_DEAD_NAME:
254 kr = ipc_object_alloc_dead(space, namep);
255 break;
256
257 default:
258 kr = KERN_INVALID_VALUE;
259 break;
260 }
261
262 return kr;
263}
264
265//XENO: Start here
266mach_port_name_t
267mk_timer_create_trap(
268 __unused struct mk_timer_create_trap_args *args)
269{
270 mk_timer_t timer;
271 ipc_space_t myspace = current_space();
272 mach_port_name_t name = MACH_PORT_NULL;
273 ipc_port_t port;
274 kern_return_t result;
275
276 timer = (mk_timer_t)zalloc(mk_timer_zone);
277 if (timer == NULL) {
278 return MACH_PORT_NULL;
279 }
280
281 result = mach_port_allocate_internal(myspace, MACH_PORT_RIGHT_RECEIVE,
282 &mk_timer_qos, &name);
283 if (result == KERN_SUCCESS) {
284 result = ipc_port_translate_receive(myspace, name, &port);
285 }
286
287 if (result != KERN_SUCCESS) {
288 zfree(mk_timer_zone, timer);
289
290 return MACH_PORT_NULL;
291 }
292
293 simple_lock_init(&timer->lock, 0);
294 thread_call_setup(&timer->call_entry, mk_timer_expire, timer);
295 timer->is_armed = timer->is_dead = FALSE;
296 timer->active = 0;
297
298 timer->port = port;
299 ipc_kobject_set_atomically(port, (ipc_kobject_t)timer, IKOT_TIMER);
300
301 port->ip_srights++;
302 ip_reference(port);
303 ip_unlock(port);
304
305 return name;
306}
RCA: TODO
CVE-2021-30869
#
1//XENO: "Calling host_request_notification adds the port to a doubly linked list
2//XENO: of ports that will receive date/time change notifications." from [5]
3//XENO: This function can be called on demand by userspace
4kern_return_t
5host_request_notification(
6 host_t host,
7 host_flavor_t notify_type,
8 ipc_port_t port)
9{
10 host_notify_t entry;
11
12 if (host == HOST_NULL)
13 return (KERN_INVALID_ARGUMENT);
14
15 if (!IP_VALID(port))
16 return (KERN_INVALID_CAPABILITY);
17
18 if (notify_type > HOST_NOTIFY_TYPE_MAX || notify_type < 0)
19 return (KERN_INVALID_ARGUMENT);
20
21 entry = (host_notify_t)zalloc(host_notify_zone);
22 if (entry == NULL)
23 return (KERN_RESOURCE_SHORTAGE);
24
25 lck_mtx_lock(&host_notify_lock);
26
27 ip_lock(port);
28 if (!ip_active(port) || port->ip_tempowner || ip_kotype(port) != IKOT_NONE) {
29 ip_unlock(port);
30
31 lck_mtx_unlock(&host_notify_lock);
32 zfree(host_notify_zone, entry);
33
34 return (KERN_FAILURE);
35 }
36
37 entry->port = port;
38 ipc_kobject_set_atomically(port, (ipc_kobject_t)entry, IKOT_HOST_NOTIFY); //XENO: This changes the port.kobject to entry,
39 ip_unlock(port); //XENO: and sets IKOT_HOST_NOTIFY in port.ip_object.io_bits
40
41 enqueue_tail(&host_notify_queue[notify_type], (queue_entry_t)entry); //XENO: Add to linked list of things to notify
42 lck_mtx_unlock(&host_notify_lock);
43
44 return (KERN_SUCCESS);
45}
46
47//XENO: This function is what links a SPR to a destination port
48//XENO: It is called when a message is sent, via:
49//XENO: mach_msg_trap()
50//XENO: -> mach_msg_overwrite_trap()
51//XENO: -> ipc_kmsg_copyin()
52//XENO: -> ipc_kmsg_copyin_header()
53//XENO: -> ipc_kmsg_set_qos()
54//XENO: -> ipc_port_link_special_reply_port()
55/*
56 * Routine: ipc_port_link_special_reply_port
57 * Purpose:
58 * Link the special reply port with the destination port.
59 * Allocates turnstile to dest port.
60 *
61 * Conditions:
62 * Nothing is locked.
63 */
64void
65ipc_port_link_special_reply_port(
66 ipc_port_t special_reply_port,
67 ipc_port_t dest_port,
68 boolean_t sync_bootstrap_checkin)
69{
70 boolean_t drop_turnstile_ref = FALSE;
71
72 /* Check if dest_port needs a turnstile */
73 ipc_port_send_turnstile_prepare(dest_port);
74
75 /* Lock the special reply port and establish the linkage */
76 ip_lock(special_reply_port);
77 imq_lock(&special_reply_port->ip_messages);
78
79 if (sync_bootstrap_checkin && special_reply_port->ip_specialreply) {
80 special_reply_port->ip_sync_bootstrap_checkin = 1;
81 }
82
83 /* Check if we need to drop the acquired turnstile ref on dest port */
84 if (!special_reply_port->ip_specialreply ||
85 special_reply_port->ip_sync_link_state != PORT_SYNC_LINK_ANY ||
86 special_reply_port->ip_sync_inheritor_port != IPC_PORT_NULL) {
87 drop_turnstile_ref = TRUE;
88 } else {
89 /* take a reference on dest_port */
90 ip_reference(dest_port);
91 special_reply_port->ip_sync_inheritor_port = dest_port; //XENO: This is the linkage to the SPR to dest port
92 special_reply_port->ip_sync_link_state = PORT_SYNC_LINK_PORT;
93 }
94
95 imq_unlock(&special_reply_port->ip_messages);
96 ip_unlock(special_reply_port);
97
98 if (drop_turnstile_ref) {
99 ipc_port_send_turnstile_complete(dest_port);
100 }
101
102 return;
103}
104
105//XENO: This function is called when a message is received by a port, via
106//XENO: mach_msg_receive() ->
107//XENO: -> mach_msg_receive_results()
108//XENO: -> mach_msg_receive_results_complete()
109//XENO: -> ipc_port_adjust_special_reply_port_locked()
110/*
111 * Routine: ipc_port_adjust_special_reply_port_locked
112 * Purpose:
113 * If the special port has a turnstile, update its inheritor.
114 * Condition:
115 * Special reply port locked on entry.
116 * Special reply port unlocked on return.
117 * The passed in port is a special reply port.
118 * Returns:
119 * None.
120 */
121void
122ipc_port_adjust_special_reply_port_locked(
123 ipc_port_t special_reply_port,
124 struct knote *kn,
125 uint8_t flags,
126 boolean_t get_turnstile)
127{
128 ipc_port_t dest_port = IPC_PORT_NULL;
129 int sync_link_state = PORT_SYNC_LINK_NO_LINKAGE;
130 turnstile_inheritor_t inheritor = TURNSTILE_INHERITOR_NULL;
131 struct turnstile *ts = TURNSTILE_NULL;
132
133 ip_lock_held(special_reply_port); // ip_sync_link_state is touched
134 imq_lock(&special_reply_port->ip_messages);
135
136 if (!special_reply_port->ip_specialreply) {
137 // only mach_msg_receive_results_complete() calls this with any port
138 assert(get_turnstile);
139 goto not_special;
140 }
141
142 if (flags & IPC_PORT_ADJUST_SR_RECEIVED_MSG) {
143 ipc_special_reply_port_msg_sent_reset(special_reply_port);
144 }
145
146 if (flags & IPC_PORT_ADJUST_UNLINK_THREAD) {
147 special_reply_port->ip_messages.imq_srp_owner_thread = NULL;
148 }
149
150 if (flags & IPC_PORT_ADJUST_RESET_BOOSTRAP_CHECKIN) {
151 special_reply_port->ip_sync_bootstrap_checkin = 0;
152 }
153
154 /* Check if the special reply port is marked non-special */
155 if (special_reply_port->ip_sync_link_state == PORT_SYNC_LINK_ANY) {
156not_special:
157 if (get_turnstile) {
158 turnstile_complete((uintptr_t)special_reply_port,
159 port_rcv_turnstile_address(special_reply_port), NULL, TURNSTILE_SYNC_IPC);
160 }
161 imq_unlock(&special_reply_port->ip_messages);
162 ip_unlock(special_reply_port);
163 if (get_turnstile) {
164 turnstile_cleanup();
165 }
166 return;
167 }
168
169 if (flags & IPC_PORT_ADJUST_SR_LINK_WORKLOOP) {
170 if (ITH_KNOTE_VALID(kn, MACH_MSG_TYPE_PORT_SEND_ONCE)) {
171 inheritor = filt_machport_stash_port(kn, special_reply_port,
172 &sync_link_state);
173 }
174 } else if (flags & IPC_PORT_ADJUST_SR_ALLOW_SYNC_LINKAGE) {
175 sync_link_state = PORT_SYNC_LINK_ANY;
176 }
177
178 /* Check if need to break linkage */
179 if (!get_turnstile && sync_link_state == PORT_SYNC_LINK_NO_LINKAGE &&
180 special_reply_port->ip_sync_link_state == PORT_SYNC_LINK_NO_LINKAGE) {
181 imq_unlock(&special_reply_port->ip_messages);
182 ip_unlock(special_reply_port);
183 return;
184 }
185
186 switch (special_reply_port->ip_sync_link_state) {
187 case PORT_SYNC_LINK_PORT:
188 dest_port = special_reply_port->ip_sync_inheritor_port;
189 special_reply_port->ip_sync_inheritor_port = IPC_PORT_NULL;
190 break;
191 case PORT_SYNC_LINK_WORKLOOP_KNOTE:
192 special_reply_port->ip_sync_inheritor_knote = NULL;
193 break;
194 case PORT_SYNC_LINK_WORKLOOP_STASH:
195 special_reply_port->ip_sync_inheritor_ts = NULL;
196 break;
197 }
198
199 special_reply_port->ip_sync_link_state = sync_link_state;
200
201 switch (sync_link_state) {
202 case PORT_SYNC_LINK_WORKLOOP_KNOTE:
203 special_reply_port->ip_sync_inheritor_knote = kn;
204 break;
205 case PORT_SYNC_LINK_WORKLOOP_STASH:
206 special_reply_port->ip_sync_inheritor_ts = inheritor;
207 break;
208 case PORT_SYNC_LINK_NO_LINKAGE:
209 if (flags & IPC_PORT_ADJUST_SR_ENABLE_EVENT) {
210 ipc_special_reply_port_lost_link(special_reply_port);
211 }
212 break;
213 }
214
215 /* Get thread's turnstile donated to special reply port */
216 if (get_turnstile) {
217 turnstile_complete((uintptr_t)special_reply_port,
218 port_rcv_turnstile_address(special_reply_port), NULL, TURNSTILE_SYNC_IPC);
219 } else {
220 ts = ipc_port_rcv_turnstile(special_reply_port);
221 if (ts) {
222 turnstile_reference(ts);
223 ipc_port_recv_update_inheritor(special_reply_port, ts,
224 TURNSTILE_IMMEDIATE_UPDATE);
225 }
226 }
227
228 imq_unlock(&special_reply_port->ip_messages);
229 ip_unlock(special_reply_port);
230
231 if (get_turnstile) {
232 turnstile_cleanup();
233 } else if (ts) {
234 /* Call turnstile cleanup after dropping the interlock */
235 turnstile_update_inheritor_complete(ts, TURNSTILE_INTERLOCK_NOT_HELD);
236 turnstile_deallocate_safe(ts);
237 }
238
239 /* Release the ref on the dest port and its turnstile */
240 if (dest_port) {
241 ipc_port_send_turnstile_complete(dest_port);
242 /* release the reference on the dest port */
243 ip_release(dest_port);
244 }
245}
RCA: TODO
#
Type Confusion
The use of attacker-controlled data to change the interpretation of a data’s type
Common Causes #
- Design paradigms that allow a variable ot struct member to be interpreted as a different type, depending on the circumstances.
- Object Oriented Programming
- Sub-type of the aforementioned design paradigm
- I.e: The ability to have C++ objects interpreted as multiple parents/children in a class hierarchy
C++ Casting #
- C-style cast (i.e.
foo a = (foo*)b)- Not safe
static_cast<TargetClass>(Object)- Checked at compile time but not at runtime
- Not-fafe
dynamic_cast<TargetClass>(Object)- Checked at runtime
- Safe, but it causes performance overhead
reinterpret_cast<TargetClass>(Object)- Not safe
C++ Type Confusion #
- Up-casts are allowed
- Down-casting objects that have been previously up-casted is not allowed
Cat *c = new Cat();
Animal *a = static_cast<Animal>(c); // This is allowed
Dog *d = static_cast<Dog>(a); // This is not allowed
Examples: #
Note: Most of these examples are vulnerabilities found in XNU, enabled by time-sensitive context-switching which specific side-effects manifested in type-confusions as product of interpeting a specific member of an object as of a different type
CVE-2021-30857 #
1struct ipc_object {
2 ipc_object_bits_t io_bits;
3 ipc_object_refs_t io_references;
4 lck_spin_t io_lock_data;
5} __attribute__((aligned(8)));
6
7//XENO: ie_object is a pointer to the ip_object field within the port that this ipc_entry references
8//XENO: Which is why ip_object_to_port(entry->ie_object) returns a pointer to a port
9struct ipc_entry {
10 struct ipc_object *XNU_PTRAUTH_SIGNED_PTR("ipc_entry.ie_object") ie_object;
11 ipc_entry_bits_t ie_bits;
12 uint32_t ie_dist : IPC_ENTRY_DIST_BITS;
13 mach_port_index_t ie_index : IPC_ENTRY_INDEX_BITS;
14 union {
15 mach_port_index_t next; /* next in freelist, or... */
16 ipc_table_index_t request; /* dead name request notify */
17 } index;
18};
19
20struct ipc_port {
21 /*
22 * Initial sub-structure in common with ipc_pset
23 * First element is an ipc_object second is a
24 * message queue
25 */
26 struct ipc_object ip_object;
27 struct ipc_mqueue ip_messages;
28
29 union {
30 struct ipc_space * receiver;
31 struct ipc_port * destination;
32 ipc_port_timestamp_t timestamp;
33 } data;
34
35 /* update host_request_notification if this union is changed */
36 union {
37 ipc_kobject_t XNU_PTRAUTH_SIGNED_PTR("ipc_port.kobject") kobject;
38 ipc_kobject_label_t XNU_PTRAUTH_SIGNED_PTR("ipc_port.kolabel") kolabel;
39 ipc_importance_task_t imp_task;
40 ipc_port_t sync_inheritor_port;
41 struct knote *sync_inheritor_knote;
42 struct turnstile *sync_inheritor_ts;
43 } kdata;
44 //...
45}
46
47//XENO: "Calling host_request_notification adds the port to a doubly linked list
48//XENO: of ports that will receive date/time change notifications." from [5]
49//XENO: This function can be called on demand by userspace
50kern_return_t
51host_request_notification(
52 host_t host,
53 host_flavor_t notify_type,
54 ipc_port_t port)
55{
56 host_notify_t entry;
57
58 if (host == HOST_NULL)
59 return (KERN_INVALID_ARGUMENT);
60
61 if (!IP_VALID(port))
62 return (KERN_INVALID_CAPABILITY);
63
64 if (notify_type > HOST_NOTIFY_TYPE_MAX || notify_type < 0)
65 return (KERN_INVALID_ARGUMENT);
66
67 entry = (host_notify_t)zalloc(host_notify_zone);
68 if (entry == NULL)
69 return (KERN_RESOURCE_SHORTAGE);
70
71 lck_mtx_lock(&host_notify_lock);
72
73 ip_lock(port);
74 if (!ip_active(port) || port->ip_tempowner || ip_kotype(port) != IKOT_NONE) {
75 ip_unlock(port);
76
77 lck_mtx_unlock(&host_notify_lock);
78 zfree(host_notify_zone, entry);
79
80 return (KERN_FAILURE);
81 }
82
83 entry->port = port;
84 ipc_kobject_set_atomically(port, (ipc_kobject_t)entry, IKOT_HOST_NOTIFY); //XENO: This changes the port.kobject to entry,
85 ip_unlock(port); //XENO: and sets IKOT_HOST_NOTIFY in port.ip_object.io_bits
86
87 enqueue_tail(&host_notify_queue[notify_type], (queue_entry_t)entry); //XENO: Add to linked list of things to notify
88 lck_mtx_unlock(&host_notify_lock);
89
90 return (KERN_SUCCESS);
91}
92
93/*
94 * Routine: ipc_right_copyin
95 * Purpose:
96 * Copyin a capability from a space.
97 * If successful, the caller gets a ref
98 * for the resulting object, unless it is IO_DEAD,
99 * and possibly a send-once right which should
100 * be used in a port-deleted notification.
101 *
102 * If deadok is not TRUE, the copyin operation
103 * will fail instead of producing IO_DEAD.
104 *
105 * The entry is never deallocated (except
106 * when KERN_INVALID_NAME), so the caller
107 * should deallocate the entry if its type
108 * is MACH_PORT_TYPE_NONE.
109 * Conditions:
110 * The space is write-locked and active.
111 * Returns:
112 * KERN_SUCCESS Acquired an object, possibly IO_DEAD.
113 * KERN_INVALID_RIGHT Name doesn't denote correct right.
114 * KERN_INVALID_CAPABILITY Trying to move an kobject port or an immovable right,
115 * or moving the last ref of pinned right
116 * KERN_INVALID_ARGUMENT Port is unguarded or guard mismatch
117 */
118//XENO: Start analysis here
119kern_return_t
120ipc_right_copyin(
121 ipc_space_t space,
122 mach_port_name_t name,
123 ipc_entry_t entry,
124 mach_msg_type_name_t msgt_name,
125 ipc_object_copyin_flags_t flags,
126 ipc_object_t *objectp,
127 ipc_port_t *sorightp,
128 ipc_port_t *releasep,
129 int *assertcntp,
130 mach_port_context_t context,
131 mach_msg_guard_flags_t *guard_flags)
132{
133 ipc_entry_bits_t bits;
134 ipc_port_t port;
135 kern_return_t kr;
136 boolean_t deadok = !!(flags & IPC_OBJECT_COPYIN_FLAGS_DEADOK);
137 boolean_t allow_imm_send = !!(flags & IPC_OBJECT_COPYIN_FLAGS_ALLOW_IMMOVABLE_SEND);
138 boolean_t soft_fail_imm_send = !!(flags & IPC_OBJECT_COPYIN_FLAGS_SOFT_FAIL_IMMOVABLE_SEND);
139
140 *releasep = IP_NULL;
141 *assertcntp = 0;
142
143 bits = entry->ie_bits;
144
145 assert(is_active(space));
146
147 switch (msgt_name) {
148 case MACH_MSG_TYPE_MAKE_SEND: {
149 if ((bits & MACH_PORT_TYPE_RECEIVE) == 0) {
150 goto invalid_right;
151 }
152
153 port = ip_object_to_port(entry->ie_object);
154 assert(port != IP_NULL);
155
156 ip_lock(port);
157 assert(port->ip_receiver_name == name);
158 assert(port->ip_receiver == space);
159
160 ipc_port_make_send_locked(port);
161 ip_unlock(port);
162
163 *objectp = ip_to_object(port);
164 *sorightp = IP_NULL;
165 break;
166 }
167
168 case MACH_MSG_TYPE_MAKE_SEND_ONCE: {
169 if ((bits & MACH_PORT_TYPE_RECEIVE) == 0) {
170 goto invalid_right;
171 }
172
173 port = ip_object_to_port(entry->ie_object);
174 assert(port != IP_NULL);
175
176 ip_lock(port);
177 require_ip_active(port);
178 assert(port->ip_receiver_name == name);
179 assert(port->ip_receiver == space);
180
181 ipc_port_make_sonce_locked(port);
182 ip_unlock(port);
183
184 *objectp = ip_to_object(port);
185 *sorightp = IP_NULL;
186 break;
187 }
188
189 case MACH_MSG_TYPE_MOVE_RECEIVE: {
190 ipc_port_t request = IP_NULL;
191
192 if ((bits & MACH_PORT_TYPE_RECEIVE) == 0) {
193 goto invalid_right;
194 }
195
196 /*
197 * Disallow moving receive-right kobjects/kolabel, e.g. mk_timer ports
198 * The ipc_port structure uses the kdata union of kobject and
199 * imp_task exclusively. Thus, general use of a kobject port as
200 * a receive right can cause type confusion in the importance
201 * code.
202 */
203 if (io_is_kobject(entry->ie_object) ||
204 io_is_kolabeled(entry->ie_object)) {
205 /*
206 * Distinguish an invalid right, e.g., trying to move
207 * a send right as a receive right, from this
208 * situation which is, "This is a valid receive right,
209 * but it's also a kobject and you can't move it."
210 */
211 mach_port_guard_exception(name, 0, 0, kGUARD_EXC_IMMOVABLE);
212 return KERN_INVALID_CAPABILITY;
213 }
214
215 port = ip_object_to_port(entry->ie_object);
216 assert(port != IP_NULL);
217
218 ip_lock(port);
219 require_ip_active(port);
220 assert(port->ip_receiver_name == name);
221 assert(port->ip_receiver == space);
222
223 if (port->ip_immovable_receive || port->ip_specialreply) {
224 assert(port->ip_receiver != ipc_space_kernel);
225 ip_unlock(port);
226 assert(current_task() != kernel_task);
227 mach_port_guard_exception(name, 0, 0, kGUARD_EXC_IMMOVABLE);
228 return KERN_INVALID_CAPABILITY;
229 }
230
231 if (guard_flags != NULL) {
232 kr = ipc_right_copyin_check_guard_locked(name, port, context, guard_flags);
233 if (kr != KERN_SUCCESS) {
234 ip_unlock(port);
235 return kr;
236 }
237 }
238
239 if (bits & MACH_PORT_TYPE_SEND) {
240 assert(IE_BITS_TYPE(bits) ==
241 MACH_PORT_TYPE_SEND_RECEIVE);
242 assert(IE_BITS_UREFS(bits) > 0);
243 assert(port->ip_srights > 0);
244
245 ipc_hash_insert(space, ip_to_object(port),
246 name, entry);
247 ip_reference(port);
248 } else {
249 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_RECEIVE);
250 assert(IE_BITS_UREFS(bits) == 0);
251
252 request = ipc_right_request_cancel_macro(space, port,
253 name, entry);
254 entry->ie_object = IO_NULL;
255 }
256 entry->ie_bits = bits & ~MACH_PORT_TYPE_RECEIVE;
257 entry->ie_bits |= MACH_PORT_TYPE_EX_RECEIVE;
258 ipc_entry_modified(space, name, entry);
259
260 /* ipc_port_clear_receiver unguards the port and clears the ip_immovable_receive bit */
261 (void)ipc_port_clear_receiver(port, FALSE); /* don't destroy the port/mqueue */
262 if (guard_flags != NULL) {
263 /* this flag will be cleared during copyout */
264 *guard_flags = *guard_flags | MACH_MSG_GUARD_FLAGS_UNGUARDED_ON_SEND;
265 }
266
267#if IMPORTANCE_INHERITANCE
268 /*
269 * Account for boosts the current task is going to lose when
270 * copying this right in. Tempowner ports have either not
271 * been accounting to any task (and therefore are already in
272 * "limbo" state w.r.t. assertions) or to some other specific
273 * task. As we have no way to drop the latter task's assertions
274 * here, We'll deduct those when we enqueue it on its
275 * destination port (see ipc_port_check_circularity()).
276 */
277 if (port->ip_tempowner == 0) {
278 assert(IIT_NULL == port->ip_imp_task);
279
280 /* ports in limbo have to be tempowner */
281 port->ip_tempowner = 1;
282 *assertcntp = port->ip_impcount;
283 }
284#endif /* IMPORTANCE_INHERITANCE */
285
286 ip_unlock(port);
287
288 *objectp = ip_to_object(port);
289 *sorightp = request;
290 break;
291 }
292
293 case MACH_MSG_TYPE_COPY_SEND: {
294 if (bits & MACH_PORT_TYPE_DEAD_NAME) {
295 goto copy_dead;
296 }
297
298 /* allow for dead send-once rights */
299
300 if ((bits & MACH_PORT_TYPE_SEND_RIGHTS) == 0) {
301 goto invalid_right;
302 }
303
304 assert(IE_BITS_UREFS(bits) > 0);
305
306 port = ip_object_to_port(entry->ie_object);
307 assert(port != IP_NULL);
308
309 if (ipc_right_check(space, port, name, entry, IPC_OBJECT_COPYIN_FLAGS_NONE)) {
310 bits = entry->ie_bits;
311 *releasep = port;
312 goto copy_dead;
313 }
314 /* port is locked and active */
315
316 if ((bits & MACH_PORT_TYPE_SEND) == 0) {
317 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_SEND_ONCE);
318 assert(port->ip_sorights > 0);
319
320 ip_unlock(port);
321 goto invalid_right;
322 }
323
324 if (!allow_imm_send && port->ip_immovable_send) {
325 if (!ip_is_control(port) || immovable_control_port_enabled) {
326 ip_unlock(port);
327 if (!soft_fail_imm_send) {
328 mach_port_guard_exception_immovable(name, port, MPG_FLAGS_NONE);
329 }
330 return KERN_INVALID_CAPABILITY;
331 }
332 }
333
334 ipc_port_copy_send_locked(port);
335 ip_unlock(port);
336
337 *objectp = ip_to_object(port);
338 *sorightp = IP_NULL;
339 break;
340 }
341
342 case MACH_MSG_TYPE_MOVE_SEND: {
343 ipc_port_t request = IP_NULL;
344
345 if (bits & MACH_PORT_TYPE_DEAD_NAME) {
346 goto move_dead;
347 }
348
349 /* allow for dead send-once rights */
350
351 if ((bits & MACH_PORT_TYPE_SEND_RIGHTS) == 0) {
352 goto invalid_right;
353 }
354
355 assert(IE_BITS_UREFS(bits) > 0);
356
357 port = ip_object_to_port(entry->ie_object);
358 assert(port != IP_NULL);
359
360 if (ipc_right_check(space, port, name, entry, IPC_OBJECT_COPYIN_FLAGS_NONE)) {
361 bits = entry->ie_bits;
362 *releasep = port;
363 goto move_dead;
364 }
365 /* port is locked and active */
366
367 if ((bits & MACH_PORT_TYPE_SEND) == 0) {
368 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_SEND_ONCE);
369 assert(port->ip_sorights > 0);
370 ip_unlock(port);
371 goto invalid_right;
372 }
373
374 if (!allow_imm_send && port->ip_immovable_send) {
375 if (!ip_is_control(port) || immovable_control_port_enabled) {
376 ip_unlock(port);
377 if (!soft_fail_imm_send) {
378 mach_port_guard_exception_immovable(name, port, MPG_FLAGS_NONE);
379 }
380 return KERN_INVALID_CAPABILITY;
381 }
382 }
383
384 if (IE_BITS_UREFS(bits) == 1) {
385 assert(port->ip_srights > 0);
386 if (bits & MACH_PORT_TYPE_RECEIVE) {
387 assert(port->ip_receiver_name == name);
388 assert(port->ip_receiver == space);
389 assert(IE_BITS_TYPE(bits) ==
390 MACH_PORT_TYPE_SEND_RECEIVE);
391 assert(port->ip_pinned == 0);
392
393 ip_reference(port);
394 } else {
395 assert(IE_BITS_TYPE(bits) ==
396 MACH_PORT_TYPE_SEND);
397
398 request = ipc_right_request_cancel_macro(space, port,
399 name, entry);
400 ipc_hash_delete(space, ip_to_object(port),
401 name, entry);
402 entry->ie_object = IO_NULL;
403 /* transfer entry's reference to caller */
404 }
405 entry->ie_bits = bits & ~
406 (IE_BITS_UREFS_MASK | MACH_PORT_TYPE_SEND);
407 } else {
408 ipc_port_copy_send_locked(port);
409 /* if urefs are pegged due to overflow, leave them pegged */
410 if (IE_BITS_UREFS(bits) < MACH_PORT_UREFS_MAX) {
411 entry->ie_bits = bits - 1; /* decrement urefs */
412 }
413 }
414
415 ipc_entry_modified(space, name, entry);
416 ip_unlock(port);
417
418 *objectp = ip_to_object(port);
419 *sorightp = request;
420 break;
421 }
422
423 case MACH_MSG_TYPE_MOVE_SEND_ONCE: {
424 ipc_port_t request;
425
426 if (bits & MACH_PORT_TYPE_DEAD_NAME) {
427 goto move_dead;
428 }
429
430 /* allow for dead send rights */
431
432 if ((bits & MACH_PORT_TYPE_SEND_RIGHTS) == 0) {
433 goto invalid_right;
434 }
435
436 assert(IE_BITS_UREFS(bits) > 0);
437
438 port = ip_object_to_port(entry->ie_object);
439 assert(port != IP_NULL);
440
441 if (ipc_right_check(space, port, name, entry, flags)) {
442 bits = entry->ie_bits;
443 *releasep = port;
444 goto move_dead;
445 }
446 /*
447 * port is locked, but may not be active:
448 * Allow copyin of inactive ports with no dead name request and treat it
449 * as if the copyin of the port was successful and port became inactive
450 * later.
451 */
452
453 if ((bits & MACH_PORT_TYPE_SEND_ONCE) == 0) {
454 assert(bits & MACH_PORT_TYPE_SEND);
455 assert(port->ip_srights > 0);
456
457 ip_unlock(port);
458 goto invalid_right;
459 }
460
461 if (!allow_imm_send && port->ip_immovable_send) {
462 if (!ip_is_control(port) || immovable_control_port_enabled) {
463 ip_unlock(port);
464 if (!soft_fail_imm_send) {
465 mach_port_guard_exception_immovable(name, port, MPG_FLAGS_NONE);
466 }
467 return KERN_INVALID_CAPABILITY;
468 }
469 }
470
471 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_SEND_ONCE);
472 assert(IE_BITS_UREFS(bits) == 1);
473 assert(port->ip_sorights > 0);
474
475 request = ipc_right_request_cancel_macro(space, port, name, entry);
476 ip_unlock(port);
477
478 entry->ie_object = IO_NULL;
479 entry->ie_bits = bits & ~
480 (IE_BITS_UREFS_MASK | MACH_PORT_TYPE_SEND_ONCE);
481 ipc_entry_modified(space, name, entry);
482 *objectp = ip_to_object(port);
483 *sorightp = request;
484 break;
485 }
486
487 default:
488invalid_right:
489 return KERN_INVALID_RIGHT;
490 }
491
492 return KERN_SUCCESS;
493
494copy_dead:
495 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_DEAD_NAME);
496 assert(IE_BITS_UREFS(bits) > 0);
497 assert(entry->ie_request == IE_REQ_NONE);
498 assert(entry->ie_object == 0);
499
500 if (!deadok) {
501 goto invalid_right;
502 }
503
504 *objectp = IO_DEAD;
505 *sorightp = IP_NULL;
506 return KERN_SUCCESS;
507
508move_dead:
509 assert(IE_BITS_TYPE(bits) == MACH_PORT_TYPE_DEAD_NAME);
510 assert(IE_BITS_UREFS(bits) > 0);
511 assert(entry->ie_request == IE_REQ_NONE);
512 assert(entry->ie_object == 0);
513
514 if (!deadok) {
515 goto invalid_right;
516 }
517
518 if (IE_BITS_UREFS(bits) == 1) {
519 bits &= ~MACH_PORT_TYPE_DEAD_NAME;
520 }
521 /* if urefs are pegged due to overflow, leave them pegged */
522 if (IE_BITS_UREFS(bits) < MACH_PORT_UREFS_MAX) {
523 entry->ie_bits = bits - 1; /* decrement urefs */
524 }
525 ipc_entry_modified(space, name, entry);
526 *objectp = IO_DEAD;
527 *sorightp = IP_NULL;
528 return KERN_SUCCESS;
529}
This is an XNU vulnerability. Therefore, when looking at the sample code above, remember that preemption and context switches can occur at nearly any instruction, unless preemption has been explicitly disabled. Objects not protected by locks or other synchronization mechanisms can be accessed or modified concurrently by other threads, potentially leading to race conditions.
That being said, lets take a look at the structure of ipc_port. We can notice a kdata member being a union type. In which field of type ipc_kobject_t kobject and a ipc_importance_task_t imp_task are held.
Now lets look at host_request_notification At the end of this function we can see a call to ipc_kobject_set_atomically this function essentially set the port.ip_object.io_bits to set the flag IKOT_HOST_NOTIFY, setting the port.kobject to a type of host_notify_entry. In other words, the host_request_notification method allows userspace to take a regular, userspace-owned mach port and set the kobject field to point to a host_notify_entry object.
If we look at the comments at line 196 at ipc_right_copyin, it describes the purpose of the subsequent check, checking if the ipc_entry_t->ie_object (which is a pointer to a ipc_port), is of type kobject or kolabeled.
However due to a context-switch, the funtion host_notify_entry could change the same port object to hold a host_notify_entry in its kdata.kobject field, and cause a type confusion when the context-switch returns back to ipc_right_copyin when it should expect the port to hold a kdata.ipc_importance_task_t instead.
CVE-2020-3853 #
1//XENO: If you look at the documentation for the userspace version of this function
2//XENO: (found in osfmk/man/mach_port_destroy.html) it says:
3//XENO: "The mach_port_destroy function de-allocates all rights denoted by a name.
4//XENO: The name becomes immediately available for reuse."
5/*
6 * Routine: mach_port_destroy [kernel call]
7 * Purpose:
8 * Cleans up and destroys all rights denoted by a name
9 * in a space. The destruction of a receive right
10 * destroys the port, unless a port-destroyed request
11 * has been made for it; the destruction of a port-set right
12 * destroys the port set.
13 * Conditions:
14 * Nothing locked.
15 * Returns:
16 * KERN_SUCCESS The name is destroyed.
17 * KERN_INVALID_TASK The space is null.
18 * KERN_INVALID_TASK The space is dead.
19 * KERN_INVALID_NAME The name doesn't denote a right.
20 */
21
22kern_return_t
23mach_port_destroy(
24 ipc_space_t space,
25 mach_port_name_t name)
26{
27 ipc_entry_t entry;
28 kern_return_t kr;
29
30 if (space == IS_NULL)
31 return KERN_INVALID_TASK;
32
33 if (!MACH_PORT_VALID(name))
34 return KERN_SUCCESS;
35
36 kr = ipc_right_lookup_write(space, name, &entry);
37 if (kr != KERN_SUCCESS) {
38 mach_port_guard_exception(name, 0, 0, kGUARD_EXC_INVALID_NAME);
39 return kr;
40 }
41 /* space is write-locked and active */
42
43 kr = ipc_right_destroy(space, name, entry, TRUE, 0); /* unlocks space */
44 return kr;
45}
46
47//XENO: See the userspace-side documentation in osfmk/man/mach_port_insert_right.html
48//XENO: For more information about how this function is intended to be used
49/*
50 * Routine: mach_port_insert_right [kernel call]
51 * Purpose:
52 * Inserts a right into a space, as if the space
53 * voluntarily received the right in a message,
54 * except that the right gets the specified name.
55 * Conditions:
56 * Nothing locked.
57 * Returns:
58 * KERN_SUCCESS Inserted the right.
59 * KERN_INVALID_TASK The space is null.
60 * KERN_INVALID_TASK The space is dead.
61 * KERN_INVALID_VALUE The name isn't a legal name.
62 * KERN_NAME_EXISTS The name already denotes a right.
63 * KERN_INVALID_VALUE Message doesn't carry a port right.
64 * KERN_INVALID_CAPABILITY Port is null or dead.
65 * KERN_UREFS_OVERFLOW Urefs limit would be exceeded.
66 * KERN_RIGHT_EXISTS Space has rights under another name.
67 * KERN_RESOURCE_SHORTAGE Couldn't allocate memory.
68 */
69
70kern_return_t
71mach_port_insert_right(
72 ipc_space_t space,
73 mach_port_name_t name,
74 ipc_port_t poly,
75 mach_msg_type_name_t polyPoly)
76{
77 if (space == IS_NULL) {
78 return KERN_INVALID_TASK;
79 }
80
81 if (!MACH_PORT_VALID(name) ||
82 !MACH_MSG_TYPE_PORT_ANY_RIGHT(polyPoly)) {
83 return KERN_INVALID_VALUE;
84 }
85
86 if (!IP_VALID(poly)) {
87 return KERN_INVALID_CAPABILITY;
88 }
89
90 return ipc_object_copyout_name(space, ip_to_object(poly),
91 polyPoly, name);
92}
93
94/*
95 * Routine: ipc_object_translate
96 * Purpose:
97 * Look up an object in a space.
98 * Conditions:
99 * Nothing locked before. If successful, the object
100 * is returned active and locked. The caller doesn't get a ref.
101 * Returns:
102 * KERN_SUCCESS Object returned locked.
103 * KERN_INVALID_TASK The space is dead.
104 * KERN_INVALID_NAME The name doesn't denote a right
105 * KERN_INVALID_RIGHT Name doesn't denote the correct right
106 */
107kern_return_t
108ipc_object_translate(
109 ipc_space_t space,
110 mach_port_name_t name,
111 mach_port_right_t right,
112 ipc_object_t *objectp)
113{
114 ipc_entry_t entry;
115 ipc_object_t object;
116 kern_return_t kr;
117
118 if (!MACH_PORT_RIGHT_VALID_TRANSLATE(right)) {
119 return KERN_INVALID_RIGHT;
120 }
121
122 kr = ipc_right_lookup_read(space, name, &entry);
123 if (kr != KERN_SUCCESS) {
124 return kr;
125 }
126 /* space is read-locked and active */
127
128 if ((entry->ie_bits & MACH_PORT_TYPE(right)) == MACH_PORT_TYPE_NONE) {
129 is_read_unlock(space);
130 return KERN_INVALID_RIGHT;
131 }
132
133 object = entry->ie_object;
134 assert(object != IO_NULL);
135
136 io_lock(object);
137 is_read_unlock(space);
138
139 if (!io_active(object)) {
140 io_unlock(object);
141 return KERN_INVALID_NAME;
142 }
143
144 *objectp = object;
145 return KERN_SUCCESS;
146}
147
148static inline kern_return_t
149ipc_port_translate(
150 ipc_space_t space,
151 mach_port_name_t name,
152 mach_port_right_t right,
153 ipc_port_t *portp)
154{
155 ipc_object_t object;
156 kern_return_t kr;
157
158 kr = ipc_object_translate(space, name, right, &object);
159 *portp = (kr == KERN_SUCCESS) ? ip_object_to_port(object) : IP_NULL;
160 return kr;
161}
162
163#define ipc_port_translate_receive(space, name, portp) \
164 ipc_port_translate((space), (name), MACH_PORT_RIGHT_RECEIVE, portp)
165
166static mach_port_qos_t mk_timer_qos = {
167 FALSE, TRUE, 0, sizeof (mk_timer_expire_msg_t)
168};
169
170/*
171 * Routine: mach_port_allocate_internal [kernel private]
172 * Purpose:
173 * Allocates a right in a space. Supports all of the
174 * special cases, a specific name, a real-time port, etc.
175 * The name may be any legal name in the space that doesn't
176 * currently denote a right.
177 * Conditions:
178 * Nothing locked.
179 * Returns:
180 * KERN_SUCCESS The right is allocated.
181 * KERN_INVALID_TASK The space is null.
182 * KERN_INVALID_TASK The space is dead.
183 * KERN_INVALID_VALUE "right" isn't a legal kind of right.
184 * KERN_RESOURCE_SHORTAGE Couldn't allocate memory.
185 * KERN_NO_SPACE No room in space for another right.
186 */
187kern_return_t
188mach_port_allocate_internal(
189 ipc_space_t space,
190 mach_port_right_t right,
191 mach_port_qos_t *qosp,
192 mach_port_name_t *namep)
193{
194 kern_return_t kr;
195
196 assert(space != IS_NULL);
197
198 switch (right) {
199 case MACH_PORT_RIGHT_RECEIVE:
200 {
201 ipc_kmsg_t kmsg = IKM_NULL;
202 ipc_port_t port;
203
204 /*
205 * For in-kernel uses, only allow small (from the kmsg zone)
206 * preallocated messages for the port.
207 */
208 if (qosp->prealloc) {
209 mach_msg_size_t size = qosp->len;
210
211 if (size > IKM_SAVED_MSG_SIZE - MAX_TRAILER_SIZE) {
212 panic("mach_port_allocate_internal: too large a prealloc kmsg");
213 }
214 kmsg = (ipc_kmsg_t)ipc_kmsg_prealloc(size + MAX_TRAILER_SIZE);
215 if (kmsg == IKM_NULL) {
216 return KERN_RESOURCE_SHORTAGE;
217 }
218 }
219
220 if (qosp->name) {
221 kr = ipc_port_alloc_name(space, IPC_PORT_INIT_MESSAGE_QUEUE,
222 *namep, &port);
223 } else {
224 kr = ipc_port_alloc(space, IPC_PORT_INIT_MESSAGE_QUEUE,
225 namep, &port);
226 }
227 if (kr == KERN_SUCCESS) {
228 if (kmsg != IKM_NULL) {
229 ipc_kmsg_set_prealloc(kmsg, port);
230 }
231 ip_unlock(port);
232 } else if (kmsg != IKM_NULL) {
233 ipc_kmsg_free(kmsg);
234 }
235 break;
236 }
237
238 case MACH_PORT_RIGHT_PORT_SET:
239 {
240 ipc_pset_t pset;
241
242 if (qosp->name) {
243 kr = ipc_pset_alloc_name(space, *namep, &pset);
244 } else {
245 kr = ipc_pset_alloc(space, namep, &pset);
246 }
247 if (kr == KERN_SUCCESS) {
248 ips_unlock(pset);
249 }
250 break;
251 }
252
253 case MACH_PORT_RIGHT_DEAD_NAME:
254 kr = ipc_object_alloc_dead(space, namep);
255 break;
256
257 default:
258 kr = KERN_INVALID_VALUE;
259 break;
260 }
261
262 return kr;
263}
264
265//XENO: Start here
266mach_port_name_t
267mk_timer_create_trap(
268 __unused struct mk_timer_create_trap_args *args)
269{
270 mk_timer_t timer;
271 ipc_space_t myspace = current_space();
272 mach_port_name_t name = MACH_PORT_NULL;
273 ipc_port_t port;
274 kern_return_t result;
275
276 timer = (mk_timer_t)zalloc(mk_timer_zone);
277 if (timer == NULL) {
278 return MACH_PORT_NULL;
279 }
280
281 result = mach_port_allocate_internal(myspace, MACH_PORT_RIGHT_RECEIVE,
282 &mk_timer_qos, &name);
283 if (result == KERN_SUCCESS) {
284 result = ipc_port_translate_receive(myspace, name, &port);
285 }
286
287 if (result != KERN_SUCCESS) {
288 zfree(mk_timer_zone, timer);
289
290 return MACH_PORT_NULL;
291 }
292
293 simple_lock_init(&timer->lock, 0);
294 thread_call_setup(&timer->call_entry, mk_timer_expire, timer);
295 timer->is_armed = timer->is_dead = FALSE;
296 timer->active = 0;
297
298 timer->port = port;
299 ipc_kobject_set_atomically(port, (ipc_kobject_t)timer, IKOT_TIMER);
300
301 port->ip_srights++;
302 ip_reference(port);
303 ip_unlock(port);
304
305 return name;
306}
RCA: TODO
CVE-2021-30869 #
1//XENO: "Calling host_request_notification adds the port to a doubly linked list
2//XENO: of ports that will receive date/time change notifications." from [5]
3//XENO: This function can be called on demand by userspace
4kern_return_t
5host_request_notification(
6 host_t host,
7 host_flavor_t notify_type,
8 ipc_port_t port)
9{
10 host_notify_t entry;
11
12 if (host == HOST_NULL)
13 return (KERN_INVALID_ARGUMENT);
14
15 if (!IP_VALID(port))
16 return (KERN_INVALID_CAPABILITY);
17
18 if (notify_type > HOST_NOTIFY_TYPE_MAX || notify_type < 0)
19 return (KERN_INVALID_ARGUMENT);
20
21 entry = (host_notify_t)zalloc(host_notify_zone);
22 if (entry == NULL)
23 return (KERN_RESOURCE_SHORTAGE);
24
25 lck_mtx_lock(&host_notify_lock);
26
27 ip_lock(port);
28 if (!ip_active(port) || port->ip_tempowner || ip_kotype(port) != IKOT_NONE) {
29 ip_unlock(port);
30
31 lck_mtx_unlock(&host_notify_lock);
32 zfree(host_notify_zone, entry);
33
34 return (KERN_FAILURE);
35 }
36
37 entry->port = port;
38 ipc_kobject_set_atomically(port, (ipc_kobject_t)entry, IKOT_HOST_NOTIFY); //XENO: This changes the port.kobject to entry,
39 ip_unlock(port); //XENO: and sets IKOT_HOST_NOTIFY in port.ip_object.io_bits
40
41 enqueue_tail(&host_notify_queue[notify_type], (queue_entry_t)entry); //XENO: Add to linked list of things to notify
42 lck_mtx_unlock(&host_notify_lock);
43
44 return (KERN_SUCCESS);
45}
46
47//XENO: This function is what links a SPR to a destination port
48//XENO: It is called when a message is sent, via:
49//XENO: mach_msg_trap()
50//XENO: -> mach_msg_overwrite_trap()
51//XENO: -> ipc_kmsg_copyin()
52//XENO: -> ipc_kmsg_copyin_header()
53//XENO: -> ipc_kmsg_set_qos()
54//XENO: -> ipc_port_link_special_reply_port()
55/*
56 * Routine: ipc_port_link_special_reply_port
57 * Purpose:
58 * Link the special reply port with the destination port.
59 * Allocates turnstile to dest port.
60 *
61 * Conditions:
62 * Nothing is locked.
63 */
64void
65ipc_port_link_special_reply_port(
66 ipc_port_t special_reply_port,
67 ipc_port_t dest_port,
68 boolean_t sync_bootstrap_checkin)
69{
70 boolean_t drop_turnstile_ref = FALSE;
71
72 /* Check if dest_port needs a turnstile */
73 ipc_port_send_turnstile_prepare(dest_port);
74
75 /* Lock the special reply port and establish the linkage */
76 ip_lock(special_reply_port);
77 imq_lock(&special_reply_port->ip_messages);
78
79 if (sync_bootstrap_checkin && special_reply_port->ip_specialreply) {
80 special_reply_port->ip_sync_bootstrap_checkin = 1;
81 }
82
83 /* Check if we need to drop the acquired turnstile ref on dest port */
84 if (!special_reply_port->ip_specialreply ||
85 special_reply_port->ip_sync_link_state != PORT_SYNC_LINK_ANY ||
86 special_reply_port->ip_sync_inheritor_port != IPC_PORT_NULL) {
87 drop_turnstile_ref = TRUE;
88 } else {
89 /* take a reference on dest_port */
90 ip_reference(dest_port);
91 special_reply_port->ip_sync_inheritor_port = dest_port; //XENO: This is the linkage to the SPR to dest port
92 special_reply_port->ip_sync_link_state = PORT_SYNC_LINK_PORT;
93 }
94
95 imq_unlock(&special_reply_port->ip_messages);
96 ip_unlock(special_reply_port);
97
98 if (drop_turnstile_ref) {
99 ipc_port_send_turnstile_complete(dest_port);
100 }
101
102 return;
103}
104
105//XENO: This function is called when a message is received by a port, via
106//XENO: mach_msg_receive() ->
107//XENO: -> mach_msg_receive_results()
108//XENO: -> mach_msg_receive_results_complete()
109//XENO: -> ipc_port_adjust_special_reply_port_locked()
110/*
111 * Routine: ipc_port_adjust_special_reply_port_locked
112 * Purpose:
113 * If the special port has a turnstile, update its inheritor.
114 * Condition:
115 * Special reply port locked on entry.
116 * Special reply port unlocked on return.
117 * The passed in port is a special reply port.
118 * Returns:
119 * None.
120 */
121void
122ipc_port_adjust_special_reply_port_locked(
123 ipc_port_t special_reply_port,
124 struct knote *kn,
125 uint8_t flags,
126 boolean_t get_turnstile)
127{
128 ipc_port_t dest_port = IPC_PORT_NULL;
129 int sync_link_state = PORT_SYNC_LINK_NO_LINKAGE;
130 turnstile_inheritor_t inheritor = TURNSTILE_INHERITOR_NULL;
131 struct turnstile *ts = TURNSTILE_NULL;
132
133 ip_lock_held(special_reply_port); // ip_sync_link_state is touched
134 imq_lock(&special_reply_port->ip_messages);
135
136 if (!special_reply_port->ip_specialreply) {
137 // only mach_msg_receive_results_complete() calls this with any port
138 assert(get_turnstile);
139 goto not_special;
140 }
141
142 if (flags & IPC_PORT_ADJUST_SR_RECEIVED_MSG) {
143 ipc_special_reply_port_msg_sent_reset(special_reply_port);
144 }
145
146 if (flags & IPC_PORT_ADJUST_UNLINK_THREAD) {
147 special_reply_port->ip_messages.imq_srp_owner_thread = NULL;
148 }
149
150 if (flags & IPC_PORT_ADJUST_RESET_BOOSTRAP_CHECKIN) {
151 special_reply_port->ip_sync_bootstrap_checkin = 0;
152 }
153
154 /* Check if the special reply port is marked non-special */
155 if (special_reply_port->ip_sync_link_state == PORT_SYNC_LINK_ANY) {
156not_special:
157 if (get_turnstile) {
158 turnstile_complete((uintptr_t)special_reply_port,
159 port_rcv_turnstile_address(special_reply_port), NULL, TURNSTILE_SYNC_IPC);
160 }
161 imq_unlock(&special_reply_port->ip_messages);
162 ip_unlock(special_reply_port);
163 if (get_turnstile) {
164 turnstile_cleanup();
165 }
166 return;
167 }
168
169 if (flags & IPC_PORT_ADJUST_SR_LINK_WORKLOOP) {
170 if (ITH_KNOTE_VALID(kn, MACH_MSG_TYPE_PORT_SEND_ONCE)) {
171 inheritor = filt_machport_stash_port(kn, special_reply_port,
172 &sync_link_state);
173 }
174 } else if (flags & IPC_PORT_ADJUST_SR_ALLOW_SYNC_LINKAGE) {
175 sync_link_state = PORT_SYNC_LINK_ANY;
176 }
177
178 /* Check if need to break linkage */
179 if (!get_turnstile && sync_link_state == PORT_SYNC_LINK_NO_LINKAGE &&
180 special_reply_port->ip_sync_link_state == PORT_SYNC_LINK_NO_LINKAGE) {
181 imq_unlock(&special_reply_port->ip_messages);
182 ip_unlock(special_reply_port);
183 return;
184 }
185
186 switch (special_reply_port->ip_sync_link_state) {
187 case PORT_SYNC_LINK_PORT:
188 dest_port = special_reply_port->ip_sync_inheritor_port;
189 special_reply_port->ip_sync_inheritor_port = IPC_PORT_NULL;
190 break;
191 case PORT_SYNC_LINK_WORKLOOP_KNOTE:
192 special_reply_port->ip_sync_inheritor_knote = NULL;
193 break;
194 case PORT_SYNC_LINK_WORKLOOP_STASH:
195 special_reply_port->ip_sync_inheritor_ts = NULL;
196 break;
197 }
198
199 special_reply_port->ip_sync_link_state = sync_link_state;
200
201 switch (sync_link_state) {
202 case PORT_SYNC_LINK_WORKLOOP_KNOTE:
203 special_reply_port->ip_sync_inheritor_knote = kn;
204 break;
205 case PORT_SYNC_LINK_WORKLOOP_STASH:
206 special_reply_port->ip_sync_inheritor_ts = inheritor;
207 break;
208 case PORT_SYNC_LINK_NO_LINKAGE:
209 if (flags & IPC_PORT_ADJUST_SR_ENABLE_EVENT) {
210 ipc_special_reply_port_lost_link(special_reply_port);
211 }
212 break;
213 }
214
215 /* Get thread's turnstile donated to special reply port */
216 if (get_turnstile) {
217 turnstile_complete((uintptr_t)special_reply_port,
218 port_rcv_turnstile_address(special_reply_port), NULL, TURNSTILE_SYNC_IPC);
219 } else {
220 ts = ipc_port_rcv_turnstile(special_reply_port);
221 if (ts) {
222 turnstile_reference(ts);
223 ipc_port_recv_update_inheritor(special_reply_port, ts,
224 TURNSTILE_IMMEDIATE_UPDATE);
225 }
226 }
227
228 imq_unlock(&special_reply_port->ip_messages);
229 ip_unlock(special_reply_port);
230
231 if (get_turnstile) {
232 turnstile_cleanup();
233 } else if (ts) {
234 /* Call turnstile cleanup after dropping the interlock */
235 turnstile_update_inheritor_complete(ts, TURNSTILE_INTERLOCK_NOT_HELD);
236 turnstile_deallocate_safe(ts);
237 }
238
239 /* Release the ref on the dest port and its turnstile */
240 if (dest_port) {
241 ipc_port_send_turnstile_complete(dest_port);
242 /* release the reference on the dest port */
243 ip_release(dest_port);
244 }
245}
RCA: TODO
Auditing Program Building Blocks #
Auditing Variables
Variable Relationships
#
Variables are related to one another if their values depend on each other in some fashion or if they are used together to represent some sort of application state.
- For example, a function might have one variable that points to a writeable location in a buffer and another variable that keeps track of the amount of space left in that buffer. These variables are related to one another and their values should change together as the buffer gets manipulated
Here is an example that showcases this concept:
1cdata = s = apr_palloc(pool, len + 1);
2
3for (scan = elem->first_cdata.first; scan != NULL; scan = scan->next) {
4 tlen = strlen(scan->text);
5 memcpy(s, scan->text, tlen);
6 s += tlen;
7}
8
9for (child = elem->first_child; child != NULL; child = child->next) {
10 for (scan = child->following_cdata.first; scan != NULL; scan = scan->next) {
11 tlen = strlen(scan->text);
12 memcpy(s, scan->text, tlen);
13 s += tlen;
14 }
15}
16
17/* ... snip ...*/
18
19if (strip_white) {
20 while (apr_isspace(*cdata))
21 ++cdata
22
23 while (len-- > 0 && apr_isspace(cdata[len]))
24 continue;
25
26 cdata[len - 1] = '\0';
27}
28
29return cdata;
In the code snippet above we can see a data buffer, s (also set to cdata) is allocated via apr_palloc(), and then string data elements from two linked lists are copied into the data buffer. The length of the cdata buffer, len, was calculated previously. At this point there are two related variables, a pointer to the buffer cdata and a variable representing the buffer’s length len. However in the preceeding code, the leading white-space are skipped by incrementing the pointer to the cdata variable at line 21. However, the len variable is not changed to reflect this shrinking in size. Therefore, the relationship between these two variables has been violated.
Note: The more related variables there are in a part of an application, the higher the likelyhood for an inconsistent state error.
Structure and Object Mismanagement
#
Applications often use large structures to manage program and session state, and group related data elements. The essence of OOP encourages this behavior, and is often the case that code reviewers are confronted with code that makes extensive use of opaque objects or structures, which are often manipulated through insufficiently documented interfaces. Code reviewers should familiarize themselves with these interfaces to learn the purpose of objects and their consituent memebers.
One goal of auditing object-oriented code should be to determine wheter it’s possible to desynchornize related structure members or leave them in an unexpected or incosistent state.
The following showcases an example of this in OpenSSH 3.6.1
void buffer_init(Buffer *buffer) {
buffer->alloc = 4096;
buffer->buf = xmalloc(buffer->alloc);
buffer->offset = 0;
buffer->end = 0;
}
From the function above, we can deduce a number of relationships:
- The
alloc member should always represent the amount of bytes allocated in the buffer.
offset and end are offsets into the buffer buf- both must be less than
alloc
offset should be less than end
Now look at the following function:
void * buffer_append_space(Buffer *buffer, u_int len) {
void *p;
if (len > 0x100000)
fatal("buffer_append_space: len %u not supported", len);
if (buffer->offset == buffer->end) {
buffer->offset = 0;
buffer->end = 0;
}
restart:
if (buffer->end + len < buffer->alloc) {
p = buffer->buf + buffer->end;
buffer->end += len;
return p;
}
if (buffer->offset > buffer->alloc / 2) {
memmove(buffer->buf, buffer->buf + buffer->offset, buffer->end - buffer->offset);
buffer->end -= buffer->offset;
buffer->offset = 0;
goto restart;
}
buffer->alloc += len + 32768;
if (buffer->alloc > 0xa00000)
fatal("buffer_append_space: alloc %u not supported", buffer->alloc);
buffer->buf = xrealloc(buffer->buf, buffer->alloc);
goto restart;
}
void *xrealloc(void *ptr, size_t new_size) {
void *new_ptr;
if (new_size == 0)
fatal("xrealloc: zero size");
if (ptr == NULL)
new_ptr = malloc(new_size);
else
new_ptr = realloc(ptr, new_size);
if (new_ptr == NULL)
fatal("xrealloc: out of memory (new_size %lu bytes)", (u_long) new_size);
return new_ptr;
}
// Invoked in `fatal`
void buffer_free(Buffer *buffer) {
memset(buffer->buf, 0, buffer->alloc);
xfree(buffer->buf);
}
We can see that xrealloc calls fatal upon failure. The fatal function cleans up several globals, including buffers used for handling data input and output with the buffer_free() routine. Therefore, if an allocation fails or the inbuilt size threshold is reached, and the buffer being resized is one of those global variables, the memset function in buffer_free writes a large amount of data past tge buffer bounds.
This example highlights how structure mismanagement bugs can occur.
Vairable Relationships Summary
#
-
Determine what each variable in the definition means and how each variable relates to the others. After you understand the relationships, check the memeber functions or interface functions to determine wether inconsistencies could occur in indentified vairable relationships. To do this identify code-paths in which one variable is updated and the other one isn’t.
-
When variables are read, determine wether a code path exist in which the variable is not initialized with a value. Pay close attention to cleanup epilogues that are jumped from multiple locations in a function, as they are the most likely place where vulnerabilities such as UDA might occur.
-
Watch out for functions that assume variables are initialized elsewhere in the program. When you find this type of code, attempt to determine whether there’s a way to call functions making assumptions at points when those assuptions are incorrect.
Arithmetic Boundaries
#
The following offer a methodological approach to spot arithmetic issues
- Discover operations that, if a boundary condition could be triggered (an integer overflow/underflow of some kind), would have security-related consequences–primary length-based calculations and comparisons
- Determine a set of values for each operand that trigger the relevant airthmetic boundary wrap
- Determine wether this code path can be reached within the set determined in the step above
- Identify the data type of the variable involved
- Determine the points at which the variable is assigned a value
- Determine the constraints on the variable from assignment until the vulnerable operation
- Determine supporting code path constraints – as other variable constraints to reach a desirable code path.
Union Type Confusion
#
The union-derived data type is used to store multiple data elements at the same location in memory. The intented purpose for this type of storage is to denote that each of the data elements are mutually exclusive. Ocassionaly, these union types can be confused with one another as the Type-confusion examples covered in XNU. Most vulnerabilties of this nature stem from misunderstanding a variable used to define what kind of data the structure contains.
List and Tables
#
Linked lists and hash tables are often used in applications to keep a collection of data elements in a form that’s easy to retrieve and manipulate.
Linked list are used frequently for storing related data elements. Linked lists can be singly or doubly linked:
- Singly linked lista are those in which elements contain a pointer to the next element
- Double linekd lists are those in which elements contain pointers to both the next and previous elements in the list.
In addition, linked lists can be circular, meaning the last element of the list can link back to the first element, and for doubly linked lists, the previous pointer of the first element of the list can point back to the last element.
When auditing code that makes use of linked lists, you should examine how well the algorithm implements the list and how it deals with boundary conditions when accessing elements. Its helpful when dealing with these to ask the following questions:
- Does the algorithm deal correctly with manipulating list elements when the list is empty?
- What are the implications of duplicate elements?
- Do previous and next pointers always get updated correctly?
- Are data-ranges accounted for correctly?
Hashing Algorithms
#
Hash tables are another popular data structure typically used for speedy access to data elements. A hash table is typically implemented as an array of linked lists, which use the list element as an input to a hash function. The result of the hash function is an index to an array. Following are some useful questions to answer:
- Is the hashing algorithm susceptible to invalid results? Most hashing algorithms attempt to guarantee that the result of lies within a certain range, usually the array size. One potential attack vector is checking if the modulos operator can return negative results. In addition, hash collisions should be evaluated if they can occur.
- What are the implications of invalidating elements? elements could be unliked from the table incorrectly
#
Auditing Variables
Variable Relationships #
Variables are related to one another if their values depend on each other in some fashion or if they are used together to represent some sort of application state.
- For example, a function might have one variable that points to a writeable location in a buffer and another variable that keeps track of the amount of space left in that buffer. These variables are related to one another and their values should change together as the buffer gets manipulated
Here is an example that showcases this concept:
1cdata = s = apr_palloc(pool, len + 1);
2
3for (scan = elem->first_cdata.first; scan != NULL; scan = scan->next) {
4 tlen = strlen(scan->text);
5 memcpy(s, scan->text, tlen);
6 s += tlen;
7}
8
9for (child = elem->first_child; child != NULL; child = child->next) {
10 for (scan = child->following_cdata.first; scan != NULL; scan = scan->next) {
11 tlen = strlen(scan->text);
12 memcpy(s, scan->text, tlen);
13 s += tlen;
14 }
15}
16
17/* ... snip ...*/
18
19if (strip_white) {
20 while (apr_isspace(*cdata))
21 ++cdata
22
23 while (len-- > 0 && apr_isspace(cdata[len]))
24 continue;
25
26 cdata[len - 1] = '\0';
27}
28
29return cdata;
In the code snippet above we can see a data buffer, s (also set to cdata) is allocated via apr_palloc(), and then string data elements from two linked lists are copied into the data buffer. The length of the cdata buffer, len, was calculated previously. At this point there are two related variables, a pointer to the buffer cdata and a variable representing the buffer’s length len. However in the preceeding code, the leading white-space are skipped by incrementing the pointer to the cdata variable at line 21. However, the len variable is not changed to reflect this shrinking in size. Therefore, the relationship between these two variables has been violated.
Note: The more related variables there are in a part of an application, the higher the likelyhood for an inconsistent state error.
Structure and Object Mismanagement #
Applications often use large structures to manage program and session state, and group related data elements. The essence of OOP encourages this behavior, and is often the case that code reviewers are confronted with code that makes extensive use of opaque objects or structures, which are often manipulated through insufficiently documented interfaces. Code reviewers should familiarize themselves with these interfaces to learn the purpose of objects and their consituent memebers.
One goal of auditing object-oriented code should be to determine wheter it’s possible to desynchornize related structure members or leave them in an unexpected or incosistent state.
The following showcases an example of this in OpenSSH 3.6.1
void buffer_init(Buffer *buffer) {
buffer->alloc = 4096;
buffer->buf = xmalloc(buffer->alloc);
buffer->offset = 0;
buffer->end = 0;
}
From the function above, we can deduce a number of relationships:
- The
allocmember should always represent the amount of bytes allocated in the buffer. offsetandendare offsets into the bufferbuf- both must be less than
alloc offsetshould be less thanend
Now look at the following function:
void * buffer_append_space(Buffer *buffer, u_int len) {
void *p;
if (len > 0x100000)
fatal("buffer_append_space: len %u not supported", len);
if (buffer->offset == buffer->end) {
buffer->offset = 0;
buffer->end = 0;
}
restart:
if (buffer->end + len < buffer->alloc) {
p = buffer->buf + buffer->end;
buffer->end += len;
return p;
}
if (buffer->offset > buffer->alloc / 2) {
memmove(buffer->buf, buffer->buf + buffer->offset, buffer->end - buffer->offset);
buffer->end -= buffer->offset;
buffer->offset = 0;
goto restart;
}
buffer->alloc += len + 32768;
if (buffer->alloc > 0xa00000)
fatal("buffer_append_space: alloc %u not supported", buffer->alloc);
buffer->buf = xrealloc(buffer->buf, buffer->alloc);
goto restart;
}
void *xrealloc(void *ptr, size_t new_size) {
void *new_ptr;
if (new_size == 0)
fatal("xrealloc: zero size");
if (ptr == NULL)
new_ptr = malloc(new_size);
else
new_ptr = realloc(ptr, new_size);
if (new_ptr == NULL)
fatal("xrealloc: out of memory (new_size %lu bytes)", (u_long) new_size);
return new_ptr;
}
// Invoked in `fatal`
void buffer_free(Buffer *buffer) {
memset(buffer->buf, 0, buffer->alloc);
xfree(buffer->buf);
}
We can see that xrealloc calls fatal upon failure. The fatal function cleans up several globals, including buffers used for handling data input and output with the buffer_free() routine. Therefore, if an allocation fails or the inbuilt size threshold is reached, and the buffer being resized is one of those global variables, the memset function in buffer_free writes a large amount of data past tge buffer bounds.
This example highlights how structure mismanagement bugs can occur.
Vairable Relationships Summary #
-
Determine what each variable in the definition means and how each variable relates to the others. After you understand the relationships, check the memeber functions or interface functions to determine wether inconsistencies could occur in indentified vairable relationships. To do this identify code-paths in which one variable is updated and the other one isn’t.
-
When variables are read, determine wether a code path exist in which the variable is not initialized with a value. Pay close attention to cleanup epilogues that are jumped from multiple locations in a function, as they are the most likely place where vulnerabilities such as UDA might occur.
-
Watch out for functions that assume variables are initialized elsewhere in the program. When you find this type of code, attempt to determine whether there’s a way to call functions making assumptions at points when those assuptions are incorrect.
Arithmetic Boundaries #
The following offer a methodological approach to spot arithmetic issues
- Discover operations that, if a boundary condition could be triggered (an integer overflow/underflow of some kind), would have security-related consequences–primary length-based calculations and comparisons
- Determine a set of values for each operand that trigger the relevant airthmetic boundary wrap
- Determine wether this code path can be reached within the set determined in the step above
- Identify the data type of the variable involved
- Determine the points at which the variable is assigned a value
- Determine the constraints on the variable from assignment until the vulnerable operation
- Determine supporting code path constraints – as other variable constraints to reach a desirable code path.
Union Type Confusion #
The union-derived data type is used to store multiple data elements at the same location in memory. The intented purpose for this type of storage is to denote that each of the data elements are mutually exclusive. Ocassionaly, these union types can be confused with one another as the Type-confusion examples covered in XNU. Most vulnerabilties of this nature stem from misunderstanding a variable used to define what kind of data the structure contains.
List and Tables #
Linked lists and hash tables are often used in applications to keep a collection of data elements in a form that’s easy to retrieve and manipulate. Linked list are used frequently for storing related data elements. Linked lists can be singly or doubly linked:
- Singly linked lista are those in which elements contain a pointer to the next element
- Double linekd lists are those in which elements contain pointers to both the next and previous elements in the list. In addition, linked lists can be circular, meaning the last element of the list can link back to the first element, and for doubly linked lists, the previous pointer of the first element of the list can point back to the last element.
When auditing code that makes use of linked lists, you should examine how well the algorithm implements the list and how it deals with boundary conditions when accessing elements. Its helpful when dealing with these to ask the following questions:
- Does the algorithm deal correctly with manipulating list elements when the list is empty?
- What are the implications of duplicate elements?
- Do previous and next pointers always get updated correctly?
- Are data-ranges accounted for correctly?
Hashing Algorithms #
Hash tables are another popular data structure typically used for speedy access to data elements. A hash table is typically implemented as an array of linked lists, which use the list element as an input to a hash function. The result of the hash function is an index to an array. Following are some useful questions to answer:
- Is the hashing algorithm susceptible to invalid results? Most hashing algorithms attempt to guarantee that the result of lies within a certain range, usually the array size. One potential attack vector is checking if the modulos operator can return negative results. In addition, hash collisions should be evaluated if they can occur.
- What are the implications of invalidating elements? elements could be unliked from the table incorrectly
Auditing Control Flow
This sections focus primarily on internal-control flow which can be resumed to looping constructs. Auditing functions will focus on external-control flow
Looping Constraints
#
A loop can be constructed incorrectly in a number of ways:
- The terminating condition don’t account for destination buffer sizes or don’t correctly account for destination sizes in some cases
- A loop fail to account for a buffers size
- A size check is made, but its incorrect
- The loop is posttest when it should be pretest
- posttest: the loop termination condition is at the end of each iteration
- pretest: the loop terminating condition is at the beginning of each iteration
- A break or continue statement is missing or its incorrectly placed
- Some misplaced punctuaction causes the loop to not do what its supposed to
Actionables
#
- Mark all the conditions for exiting a loop as well as all variables manipulated by the loop
- Determine wether any conditions exist in which variables are left in an inconsistent state
- Pay attention to places where the loop is terminated because of an unexpected error, at these points is more likely to leave variables in an unconsistent state
Auditing Functions
#
There are four main types of vulnerability patterns that can onccur when a function call is made:
- Return values are misinterpreted or ignored
- Arguments supplied are incorrectly formatted in some way
- Arguments get updated in an unexpected fashion
- Some unexpected global program state change occurs because of the function call
Function Audit Logs
#
The following is an example of an audit log for a function:
Value
Description
Function Prototype
int read_data(int sockfd, char **buffer, int *length)
Function Description
reads data from the supplied socket and allocates a buffer for storage
Location
src/net/read.c line 29
X-Refs
process_request, src/net/process.c,line 400
process_login, src/net/process.c, line 932
Returned Value
32-bit unsigned integer
Returned Value Meaning
Error Code. O for success, -1 for error
Error Conditions
calloc failure when allocating MAX_SIZE bytes
If read returns less than or equal to 0
Erroneous Return Values
When calloc fails, function returns NULL instead of -1
Mandatory Modifications
char **buffer: Updated with a data buffer that’s allocated within the function
int *length: Updated with how many bytes are read into **buffer for processing
Exceptions
Both arguments aren’t updated if the buffer allocation fails or the call to read() fails
Ignoring Return Values
#
Many functions indicate success or failure through a return value. Consequently, ignoring a return value could cause an error condition to go undetected. As an example:
int append_data(struct databuf *buf, char *src, size_t len) {
size_t new_size = buf->used + len + EXTRA;
if (new_size > buf->allocated_length) {
buf->data = (char *)realloc(buf->data, new_size);
buf->allocated_length = new_size;
}
memcpy(buf->data + buf->used, src, len);
buf->used += len;
return 0;
}
As observed above, buf->data element can be reallocated, but the realloc() return value is never checked for failure. When the subsequent memcpy() executes, if realloc() fails, buf->data will be null, and if an attacker could craft an arbitrary buf->used it could lead to an arbitrary-write primtive.
Misinterpreting Return Values
#
A return value may be misinterpreted in two ways:
- A programmer might simply misunderstand the meaning of the return value
- The return value might be involved in a type conversion that causes its intended meaning to change
An example:
#define SIZE(x, y) (sizeof(x) - ((y) - (x)))
char buf[1024], *ptr;
ptr += snprintf(ptr, SIZE(buf, ptr), "user: %s\n", username);
ptr += snprintf(ptr, SIZE(buf, ptr), "pass: %s\n", password);
On UNIX machines, the snprintf() function typically returns how many bytes it would have written to the destination, had there been enough room. Therefore, the first call to snprintf() might return a value larger than the sizeof(buf) if username variable is very large. The result is that the ptr variable is incremented outside the buffer’s bounds, and the second call to snprintf() could corrupt memory.
Function Side-effects
#
Side-effects can occur when a function alters the program state in addition to any values it reutrns. A function that does not generate any side-effects its considered referentially transparent, that is the function call can be replaced directly with the return value. On the other hadn, functions that causes side-effects are denominated referentially opaque.
When reviewing an application, code auditors should make note of security-relevant functions that maniputale pass-by-reference arguments, as well as the specific manner in which they perform this manipulation.
Here is a few things useful to conduct in these situations:
- Find all locations in a function where pass-by-reference arguments are modified, particularly structure arguments.
- Differentiate between mandatory modification and optional modification.
- Mandatory modification occurs every time the function is called
- Optional modifications occur when an abnormal situation arises
- Examine how calling functions use the modified argument after the function has returned
- Note when arguments aren’t updated when they should be
Argument Meaning
#
When auditing a function for vulnerabilities in relation to incorrect arguments, its important to do the following:
- List the type and intented meaning of each argument to a function
- Examine all the calling functions to determine whether the type conversions or incorrect arguments could be supplied.
- Example: signed size passed to memcpy :
int -> size_t
The following is an example of a function argument audit log:
Value
Description
Argument 1 Prototype
wchar_t *dest
Argument 1 Meaning
Destination buffer where data is copied into from the source buffer
Argument 2 Prototype
wchar_t *src
Argument 2 Meaning
Source buffer where wide characters are copied from
Argument 3 Prototype
size_t len
Argument 3 Meaning
Maximum size in wide characters of the destination buffer
Does not include NULL byte
Implications
NUL termination is guaranteed
The len parameter doesn’t include the null terminator character, so the null character can be written out of bounds if the supplied len is the exact size of the buffer divided by 2
the length parameter is in wide characters; callers may accidentaly use sizeof(buf), resulting in an overflow
if 0 is supplied as len, its decremented to -1, and an infinte copy will occur.
If -1 len is supplied, it’s set artificially to 256
The implications section summerizes how application programmers could use the function incorrectly and notes any situations in the function that may cause some exploitable condition.
The trick to finding vulnerabilities related to misnuderstanding function arguments is to be anle to conceptualize a chunk of code in isolation. When you are attempting to understand how a function operates, carefully examine each condition thats directly influenced by the arguments and keep thinking about what boundary conditions might cause the function to be called incorrectly.
#
Auditing Control Flow
This sections focus primarily on internal-control flow which can be resumed to looping constructs. Auditing functions will focus on external-control flow
Looping Constraints #
A loop can be constructed incorrectly in a number of ways:
- The terminating condition don’t account for destination buffer sizes or don’t correctly account for destination sizes in some cases
- A loop fail to account for a buffers size
- A size check is made, but its incorrect
- The loop is posttest when it should be pretest
- posttest: the loop termination condition is at the end of each iteration
- pretest: the loop terminating condition is at the beginning of each iteration
- A break or continue statement is missing or its incorrectly placed
- Some misplaced punctuaction causes the loop to not do what its supposed to
Actionables #
- Mark all the conditions for exiting a loop as well as all variables manipulated by the loop
- Determine wether any conditions exist in which variables are left in an inconsistent state
- Pay attention to places where the loop is terminated because of an unexpected error, at these points is more likely to leave variables in an unconsistent state
Auditing Functions #
There are four main types of vulnerability patterns that can onccur when a function call is made:
- Return values are misinterpreted or ignored
- Arguments supplied are incorrectly formatted in some way
- Arguments get updated in an unexpected fashion
- Some unexpected global program state change occurs because of the function call
Function Audit Logs #
The following is an example of an audit log for a function:
| Value | Description |
|---|---|
| Function Prototype | int read_data(int sockfd, char **buffer, int *length) |
| Function Description | reads data from the supplied socket and allocates a buffer for storage |
| Location | src/net/read.c line 29 |
| X-Refs | process_request, src/net/process.c,line 400 process_login, src/net/process.c, line 932 |
| Returned Value | 32-bit unsigned integer |
| Returned Value Meaning | Error Code. O for success, -1 for error |
| Error Conditions | calloc failure when allocating MAX_SIZE bytes If read returns less than or equal to 0 |
| Erroneous Return Values | When calloc fails, function returns NULL instead of -1 |
| Mandatory Modifications | char **buffer: Updated with a data buffer that’s allocated within the function int *length: Updated with how many bytes are read into **buffer for processing |
| Exceptions | Both arguments aren’t updated if the buffer allocation fails or the call to read() fails |
Ignoring Return Values #
Many functions indicate success or failure through a return value. Consequently, ignoring a return value could cause an error condition to go undetected. As an example:
int append_data(struct databuf *buf, char *src, size_t len) {
size_t new_size = buf->used + len + EXTRA;
if (new_size > buf->allocated_length) {
buf->data = (char *)realloc(buf->data, new_size);
buf->allocated_length = new_size;
}
memcpy(buf->data + buf->used, src, len);
buf->used += len;
return 0;
}
As observed above, buf->data element can be reallocated, but the realloc() return value is never checked for failure. When the subsequent memcpy() executes, if realloc() fails, buf->data will be null, and if an attacker could craft an arbitrary buf->used it could lead to an arbitrary-write primtive.
Misinterpreting Return Values #
A return value may be misinterpreted in two ways:
- A programmer might simply misunderstand the meaning of the return value
- The return value might be involved in a type conversion that causes its intended meaning to change
An example:
#define SIZE(x, y) (sizeof(x) - ((y) - (x)))
char buf[1024], *ptr;
ptr += snprintf(ptr, SIZE(buf, ptr), "user: %s\n", username);
ptr += snprintf(ptr, SIZE(buf, ptr), "pass: %s\n", password);
On UNIX machines, the snprintf() function typically returns how many bytes it would have written to the destination, had there been enough room. Therefore, the first call to snprintf() might return a value larger than the sizeof(buf) if username variable is very large. The result is that the ptr variable is incremented outside the buffer’s bounds, and the second call to snprintf() could corrupt memory.
Function Side-effects #
Side-effects can occur when a function alters the program state in addition to any values it reutrns. A function that does not generate any side-effects its considered referentially transparent, that is the function call can be replaced directly with the return value. On the other hadn, functions that causes side-effects are denominated referentially opaque.
When reviewing an application, code auditors should make note of security-relevant functions that maniputale pass-by-reference arguments, as well as the specific manner in which they perform this manipulation. Here is a few things useful to conduct in these situations:
- Find all locations in a function where pass-by-reference arguments are modified, particularly structure arguments.
- Differentiate between mandatory modification and optional modification.
- Mandatory modification occurs every time the function is called
- Optional modifications occur when an abnormal situation arises
- Examine how calling functions use the modified argument after the function has returned
- Note when arguments aren’t updated when they should be
Argument Meaning #
When auditing a function for vulnerabilities in relation to incorrect arguments, its important to do the following:
- List the type and intented meaning of each argument to a function
- Examine all the calling functions to determine whether the type conversions or incorrect arguments could be supplied.
- Example: signed size passed to memcpy :
int->size_t
- Example: signed size passed to memcpy :
The following is an example of a function argument audit log:
| Value | Description |
|---|---|
| Argument 1 Prototype | wchar_t *dest |
| Argument 1 Meaning | Destination buffer where data is copied into from the source buffer |
| Argument 2 Prototype | wchar_t *src |
| Argument 2 Meaning | Source buffer where wide characters are copied from |
| Argument 3 Prototype | size_t len |
| Argument 3 Meaning | Maximum size in wide characters of the destination buffer Does not include NULL byte |
| Implications | NUL termination is guaranteed The len parameter doesn’t include the null terminator character, so the null character can be written out of bounds if the supplied len is the exact size of the buffer divided by 2 the length parameter is in wide characters; callers may accidentaly use sizeof(buf), resulting in an overflow if 0 is supplied as len, its decremented to -1, and an infinte copy will occur. If -1 len is supplied, it’s set artificially to 256 |
The implications section summerizes how application programmers could use the function incorrectly and notes any situations in the function that may cause some exploitable condition.
The trick to finding vulnerabilities related to misnuderstanding function arguments is to be anle to conceptualize a chunk of code in isolation. When you are attempting to understand how a function operates, carefully examine each condition thats directly influenced by the arguments and keep thinking about what boundary conditions might cause the function to be called incorrectly.
Auditing Memory Management
In this section a code reviewer needs to examine the common issues in managingn memory. and the security relevant impact of mismanagement. For this, we will be covering a few tools to make this easier.
ACC Logs
#
Errors in memory management are almost always the result of length miscalculations; so one of the first steps in auditing memory management is to develop a good process for identifying length miscalculations. Some miscalculations stand out, while others are quite easy to miss. To help during the analaysis, we can use allocation-check-copy (ACC) logs.
An ACC logs its simply intended to record any variations in allocation sizes, length checks and data element copies that can occur on a memory block. An ACC log is divided into 3 columns for each memory allocation:
- The first column contains a formula for describing the size og the memory that’s allocated.
- The next column contains any length checks that data elements are subjected to before being copied into the allocation buffer
- The third column is used to list which data elements are copied into the buffer and the way in which they are copied. Separate copies are listed one after the other.
- Finally, you can have an optional fourth column, where you note any interesting discrepancies you determined from the information in the other three columns.
Lets look at an example:
int read_packet(int sockfd) {
unsigned int challenge_length, ciphers_count;
char challenge[64];
struct cipher *cipherlist;
int i;
challenge_length = read_integer(sockfd);
if (challenge_length > 64)
return -1;
if (read_bytes(sockfd, challenge, challenge_length) < 0)
return -1;
ciphers_count = read_integer(sockfd);
cipherlist = (struct cipher*)allocate(ciphers_count * sizeof(struct cipher));
if (cipherlist == NULL)
return -1;
for (int i = 0; i < ciphers_count; i++) {
if (read_bytes(sockfd, &cipherlist[i], sizeof(struct cipher)) < 0) {
free(cipherlist);
return -1;
}
}
}
A sample ACC log for the code above can be shown below:
Variable
Allocation
Check
Copy
Notes
challenge64
Supplied length is less than or equal to 64 (check is unsigned)
Copies length bytes
Seems like a safe copy; Checks are consistent
cipherlistciphers_count * sizeof(struct cipher)N/A
Reads individual ciphers one at a time
Integer Overflowif (ciphers_count > 0xffffffff) / sizeof(struct cipher)
In the ACC log you record the specifics of how a buffer is allocated, what length checks are performed, and how data is copied into the buffer. ACC logs are intended to help you identify length checks that could cause problems.
ALF Logs
#
ALF Logs, (Allocation-Lifetime-Free) serve to consolidate in one table the potential lifetime of a specific object instance across function boundaries. This in addition with Function Logs should be a fairly granular way of tracking an object lifetime. Lets look at this example of CVE-2020-2674:
1/** @copydoc VUSBIROOTHUBCONNECTOR::pfnFreeUrb */
2DECLINLINE(int) VUSBIRhFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
3{
4 return pInterface->pfnFreeUrb(pInterface, pUrb); //XENO: goto vusbRhConnFreeUrb() (assigned in vusbRhConstruct())
5}
6
7
8/** @copydoc VUSBIROOTHUBCONNECTOR::pfnSubmitUrb */
9DECLINLINE(int) VUSBIRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, struct PDMLED *pLed)
10{
11 return pInterface->pfnSubmitUrb(pInterface, pUrb, pLed); //XENO: goto vusbRhSubmitUrb() (assigned in vusbRhConstruct())
12}
13
14/**
15 * Releases the given VUSB device pointer.
16 *
17 * @returns New reference count.
18 * @retval 0 if no onw is holding a reference anymore causing the device to be destroyed.
19 */
20DECLINLINE(uint32_t) vusbDevRelease(PVUSBDEV pThis)
21{
22 AssertPtrReturn(pThis, UINT32_MAX);
23
24 uint32_t cRefs = ASMAtomicDecU32(&pThis->cRefs);
25 AssertMsg(cRefs < _1M, ("%#x %p\n", cRefs, pThis));
26 if (cRefs == 0)
27 vusbDevDestroy(pThis);
28 return cRefs;
29}
30
31
32/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnFreeUrb} */
33static DECLCALLBACK(int) vusbRhConnFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
34{
35 RT_NOREF(pInterface);
36 pUrb->pVUsb->pfnFree(pUrb); //XENO: goto vusbRhFreeUrb() (assigned in vusbRhNewUrb())
37 return VINF_SUCCESS;
38}
39
40/**
41 * Callback for freeing an URB.
42 * @param pUrb The URB to free.
43 */
44static DECLCALLBACK(void) vusbRhFreeUrb(PVUSBURB pUrb)
45{
46 /*
47 * Assert sanity.
48 */
49 vusbUrbAssert(pUrb);
50 PVUSBROOTHUB pRh = (PVUSBROOTHUB)pUrb->pVUsb->pvFreeCtx;
51 Assert(pRh);
52
53 Assert(pUrb->enmState != VUSBURBSTATE_FREE);
54
55 /*
56 * Free the URB description (logging builds only).
57 */
58 if (pUrb->pszDesc)
59 {
60 RTStrFree(pUrb->pszDesc);
61 pUrb->pszDesc = NULL;
62 }
63
64 /* The URB comes from the roothub if there is no device (invalid address). */
65 if (pUrb->pVUsb->pDev)
66 {
67 PVUSBDEV pDev = pUrb->pVUsb->pDev;
68
69 vusbUrbPoolFree(&pUrb->pVUsb->pDev->UrbPool, pUrb);
70 vusbDevRelease(pDev);
71 }
72 else
73 vusbUrbPoolFree(&pRh->Hub.Dev.UrbPool, pUrb);
74}
75
76/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnSubmitUrb} */
77static DECLCALLBACK(int) vusbRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, PPDMLED pLed)
78{
79 PVUSBROOTHUB pRh = VUSBIROOTHUBCONNECTOR_2_VUSBROOTHUB(pInterface);
80 STAM_PROFILE_START(&pRh->StatSubmitUrb, a);
81
82 /* If there is a sniffer on the roothub record the URB there. */
83 if (pRh->hSniffer != VUSBSNIFFER_NIL)
84 {
85 int rc = VUSBSnifferRecordEvent(pRh->hSniffer, pUrb, VUSBSNIFFEREVENT_SUBMIT);
86 if (RT_FAILURE(rc))
87 LogRel(("VUSB: Capturing URB submit event on the root hub failed with %Rrc\n", rc));
88 }
89
90 /*
91 * The device was resolved when we allocated the URB.
92 * Submit it to the device if we found it, if not fail with device-not-ready.
93 */
94 int rc;
95 if ( pUrb->pVUsb->pDev
96 && pUrb->pVUsb->pDev->pUsbIns)
97 {
98 switch (pUrb->enmDir)
99 {
100 case VUSBDIRECTION_IN:
101 pLed->Asserted.s.fReading = pLed->Actual.s.fReading = 1;
102 rc = vusbUrbSubmit(pUrb);
103 pLed->Actual.s.fReading = 0;
104 break;
105 case VUSBDIRECTION_OUT:
106 pLed->Asserted.s.fWriting = pLed->Actual.s.fWriting = 1;
107 rc = vusbUrbSubmit(pUrb);
108 pLed->Actual.s.fWriting = 0;
109 break;
110 default:
111 rc = vusbUrbSubmit(pUrb);
112 break;
113 }
114
115 if (RT_FAILURE(rc))
116 {
117 LogFlow(("vusbRhSubmitUrb: freeing pUrb=%p\n", pUrb));
118 pUrb->pVUsb->pfnFree(pUrb);
119 }
120 }
121 else
122 {
123 vusbDevRetain(&pRh->Hub.Dev);
124 pUrb->pVUsb->pDev = &pRh->Hub.Dev;
125 Log(("vusb: pRh=%p: SUBMIT: Address %i not found!!!\n", pRh, pUrb->DstAddress));
126
127 pUrb->enmState = VUSBURBSTATE_REAPED;
128 pUrb->enmStatus = VUSBSTATUS_DNR;
129 vusbUrbCompletionRh(pUrb);
130 rc = VINF_SUCCESS;
131 }
132
133 STAM_PROFILE_STOP(&pRh->StatSubmitUrb, a);
134 return rc;
135}
136
137//XENO: START HERE
138/**
139 * Service a general transport descriptor.
140 */
141static bool ohciR3ServiceTd(POHCI pThis, VUSBXFERTYPE enmType, PCOHCIED pEd, uint32_t EdAddr, uint32_t TdAddr,
142 uint32_t *pNextTdAddr, const char *pszListName)
143{
144 RT_NOREF(pszListName);
145
146 /*
147 * Read the TD and setup the buffer data.
148 */
149 OHCITD Td;
150 ohciR3ReadTd(pThis, TdAddr, &Td);
151 OHCIBUF Buf;
152 ohciR3BufInit(&Buf, Td.cbp, Td.be);
153
154 *pNextTdAddr = Td.NextTD & ED_PTR_MASK;
155
156 /*
157 * Determine the direction.
158 */
159 VUSBDIRECTION enmDir;
160 switch (pEd->hwinfo & ED_HWINFO_DIR)
161 {
162 case ED_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
163 case ED_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
164 default:
165 switch (Td.hwinfo & TD_HWINFO_DIR)
166 {
167 case TD_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
168 case TD_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
169 case 0: enmDir = VUSBDIRECTION_SETUP; break;
170 default:
171 Log(("ohciR3ServiceTd: Invalid direction!!!! Td.hwinfo=%#x Ed.hwdinfo=%#x\n", Td.hwinfo, pEd->hwinfo));
172 ohciR3RaiseUnrecoverableError(pThis, 2);
173 return false;
174 }
175 break;
176 }
177
178 pThis->fIdle = false; /* Mark as active */
179
180 /*
181 * Allocate and initialize a new URB.
182 */
183 PVUSBURB pUrb = VUSBIRhNewUrb(pThis->RootHub.pIRhConn, pEd->hwinfo & ED_HWINFO_FUNCTION, NULL,
184 enmType, enmDir, Buf.cbTotal, 1, NULL);
185 if (!pUrb)
186 return false; /* retry later... */
187
188 pUrb->EndPt = (pEd->hwinfo & ED_HWINFO_ENDPOINT) >> ED_HWINFO_ENDPOINT_SHIFT;
189 pUrb->fShortNotOk = !(Td.hwinfo & TD_HWINFO_ROUNDING);
190 pUrb->enmStatus = VUSBSTATUS_OK;
191 pUrb->pHci->EdAddr = EdAddr;
192 pUrb->pHci->fUnlinked = false;
193 pUrb->pHci->cTds = 1;
194 pUrb->paTds[0].TdAddr = TdAddr;
195 pUrb->pHci->u32FrameNo = pThis->HcFmNumber;
196 AssertCompile(sizeof(pUrb->paTds[0].TdCopy) >= sizeof(Td));
197 memcpy(pUrb->paTds[0].TdCopy, &Td, sizeof(Td));
198
199 /* copy data if out bound transfer. */
200 pUrb->cbData = Buf.cbTotal;
201 if ( Buf.cbTotal
202 && Buf.cVecs > 0
203 && enmDir != VUSBDIRECTION_IN)
204 {
205 /* Be paranoid. */ //XENO: That's what I like to hear! :D
206 if ( Buf.aVecs[0].cb > pUrb->cbData
207 || ( Buf.cVecs > 1
208 && Buf.aVecs[1].cb > (pUrb->cbData - Buf.aVecs[0].cb)))
209 {
210 ohciR3RaiseUnrecoverableError(pThis, 3);
211 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
212 return false;
213 }
214
215 ohciR3PhysRead(pThis, Buf.aVecs[0].Addr, pUrb->abData, Buf.aVecs[0].cb);
216 if (Buf.cVecs > 1)
217 ohciR3PhysRead(pThis, Buf.aVecs[1].Addr, &pUrb->abData[Buf.aVecs[0].cb], Buf.aVecs[1].cb);
218 }
219
220 /*
221 * Submit the URB.
222 */
223 ohciR3InFlightAdd(pThis, TdAddr, pUrb);
224 Log(("%s: ohciR3ServiceTd: submitting TdAddr=%#010x EdAddr=%#010x cbData=%#x\n",
225 pUrb->pszDesc, TdAddr, EdAddr, pUrb->cbData));
226
227 ohciR3Unlock(pThis);
228 int rc = VUSBIRhSubmitUrb(pThis->RootHub.pIRhConn, pUrb, &pThis->RootHub.Led);
229 ohciR3Lock(pThis);
230 if (RT_SUCCESS(rc))
231 return true;
232
233 /* Failure cleanup. Can happen if we're still resetting the device or out of resources. */
234 Log(("ohciR3ServiceTd: failed submitting TdAddr=%#010x EdAddr=%#010x pUrb=%p!!\n",
235 TdAddr, EdAddr, pUrb));
236 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
237 ohciR3InFlightRemove(pThis, TdAddr);
238 return false;
239}
ALF Log for object pUrb
#
Object
Event
Function
Line
Condition
Custody Path
Notes
pUrbALLOC
ohciR3ServiceTd183
Always
Allocated in ohciR3ServiceTd, custody owned locally
Created via VUSBIRhNewUrb(...)
pUrbPASS
ohciR3ServiceTd228
After allocation and setup
Passed to VUSBIRhSubmitUrb(pThis->RootHub.pIRhConn, pUrb, &pThis->RootHub.Led);
Explicit handoff to submission routine
pUrbPASS
VUSBIRhSubmitUrb11
Always
Passed to pInterface->pfnSubmitUrb(pInterface, pUrb, pLed); via connector callback. resolves to vusbRhSubmitUrb(pInterface, pUrb, pLed)
Proxy to backend submit routine
pUrbFREE
vusbRhSubmitUrb118
Submission fails (RT_FAILURE(rc))
Passed to pUrb->pVUsb->pfnFree(pUrb); function pointer
Start of cleanup chain
pUrbPASS
vusbRhConnFreeUrb36
Always
pUrb->pVUsb->pfnFree(pUrb); resolves to vusbRhConnFreeUrb(pUrb)Proxy to backend free routine
pUrbFREE
ohciR3ServiceTd236
Submission fails (!RT_SUCCESS(rc))
Freed by VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
Potential Double Free
With this methodology we can attempt to formalize the tracking of a given object lifetime across function boundaries, and locate potential multiple paths for free sites, that can lead to things like double-free, or use-after-free.
Allocation Functions
#
Problems can occur when allocation funcitons don’t act as the programmer expects. In relation to specific implementation of dynamic allocator functions one should ask the following questions:
- Is it legal to allocate 0 bytes?
- Does the allocation routine perform rounding on the request size? Some bugs can arise from this if a mask is applied to the size argument such as
size = (size + 15) & 0xfffffff0 but if size is 0, this will return a zero allocation.
- Are other arithmetic operations performed on the request size? this could lead to integer overflows
- Are the data types for request sizes consistent? This could lead to undersirable integer conversions
- Is there a maximum request size? If the requested size is bigger than the maximum request size, the allocation may fail, and this may cause size-effects if return value is not properly checked.
In order to track this information, its useful to write down allocator scorecard:
Allocator Scorecards
#
You should identify allocator routines early during the audit and perform a cursory examination on them. At a minimum, you should address each potential danger area by scoring allocation routines based on the associated vulnerability issues–creating sort of a scorecard. Following is an example:
Value
Description
Function Prototype
int my_malloc(unsigned long size)
0 bytes legal
yes
Rounds to
16 bytes
Additional operators
None
Maximum size
1000000 bytes
Exceptional circumstances
When a request is made larger than 1000000 bytes, the function rounds off the size to 1000000
Notes
The rounding is done after the maximum size check, so there is no integer wrap
Errors
None, only if malloc fails
This scorecard summerizes all potential allocator problem areas. There’s no column indicating wether values are signed or listing 16 bit issues because you can instantly can deduce this information from looking at the function prototype
Error Domains
#
An error domain is a set of values that, when supplied to the function, generate one of the exceptional conditions that could result in memory corruption. An example table for an Error Domain its shown below:
Value
Description
Function Prototype
int my_malloc(unsigned long size)
Error Domain
0xfffffff1 to 0xffffffff
Implication
integer wrap allocates a small chunk product of size rounding: size = (size + 15) & 0xfffffff0
#
Auditing Memory Management
In this section a code reviewer needs to examine the common issues in managingn memory. and the security relevant impact of mismanagement. For this, we will be covering a few tools to make this easier.
ACC Logs #
Errors in memory management are almost always the result of length miscalculations; so one of the first steps in auditing memory management is to develop a good process for identifying length miscalculations. Some miscalculations stand out, while others are quite easy to miss. To help during the analaysis, we can use allocation-check-copy (ACC) logs.
An ACC logs its simply intended to record any variations in allocation sizes, length checks and data element copies that can occur on a memory block. An ACC log is divided into 3 columns for each memory allocation:
- The first column contains a formula for describing the size og the memory that’s allocated.
- The next column contains any length checks that data elements are subjected to before being copied into the allocation buffer
- The third column is used to list which data elements are copied into the buffer and the way in which they are copied. Separate copies are listed one after the other.
- Finally, you can have an optional fourth column, where you note any interesting discrepancies you determined from the information in the other three columns.
Lets look at an example:
int read_packet(int sockfd) {
unsigned int challenge_length, ciphers_count;
char challenge[64];
struct cipher *cipherlist;
int i;
challenge_length = read_integer(sockfd);
if (challenge_length > 64)
return -1;
if (read_bytes(sockfd, challenge, challenge_length) < 0)
return -1;
ciphers_count = read_integer(sockfd);
cipherlist = (struct cipher*)allocate(ciphers_count * sizeof(struct cipher));
if (cipherlist == NULL)
return -1;
for (int i = 0; i < ciphers_count; i++) {
if (read_bytes(sockfd, &cipherlist[i], sizeof(struct cipher)) < 0) {
free(cipherlist);
return -1;
}
}
}
A sample ACC log for the code above can be shown below:
| Variable | Allocation | Check | Copy | Notes |
|---|---|---|---|---|
challenge |
64 | Supplied length is less than or equal to 64 (check is unsigned) | Copies length bytes | Seems like a safe copy; Checks are consistent |
cipherlist |
ciphers_count * sizeof(struct cipher) |
N/A | Reads individual ciphers one at a time | Integer Overflowif (ciphers_count > 0xffffffff) / sizeof(struct cipher) |
In the ACC log you record the specifics of how a buffer is allocated, what length checks are performed, and how data is copied into the buffer. ACC logs are intended to help you identify length checks that could cause problems.
ALF Logs #
ALF Logs, (Allocation-Lifetime-Free) serve to consolidate in one table the potential lifetime of a specific object instance across function boundaries. This in addition with Function Logs should be a fairly granular way of tracking an object lifetime. Lets look at this example of CVE-2020-2674:
1/** @copydoc VUSBIROOTHUBCONNECTOR::pfnFreeUrb */
2DECLINLINE(int) VUSBIRhFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
3{
4 return pInterface->pfnFreeUrb(pInterface, pUrb); //XENO: goto vusbRhConnFreeUrb() (assigned in vusbRhConstruct())
5}
6
7
8/** @copydoc VUSBIROOTHUBCONNECTOR::pfnSubmitUrb */
9DECLINLINE(int) VUSBIRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, struct PDMLED *pLed)
10{
11 return pInterface->pfnSubmitUrb(pInterface, pUrb, pLed); //XENO: goto vusbRhSubmitUrb() (assigned in vusbRhConstruct())
12}
13
14/**
15 * Releases the given VUSB device pointer.
16 *
17 * @returns New reference count.
18 * @retval 0 if no onw is holding a reference anymore causing the device to be destroyed.
19 */
20DECLINLINE(uint32_t) vusbDevRelease(PVUSBDEV pThis)
21{
22 AssertPtrReturn(pThis, UINT32_MAX);
23
24 uint32_t cRefs = ASMAtomicDecU32(&pThis->cRefs);
25 AssertMsg(cRefs < _1M, ("%#x %p\n", cRefs, pThis));
26 if (cRefs == 0)
27 vusbDevDestroy(pThis);
28 return cRefs;
29}
30
31
32/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnFreeUrb} */
33static DECLCALLBACK(int) vusbRhConnFreeUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb)
34{
35 RT_NOREF(pInterface);
36 pUrb->pVUsb->pfnFree(pUrb); //XENO: goto vusbRhFreeUrb() (assigned in vusbRhNewUrb())
37 return VINF_SUCCESS;
38}
39
40/**
41 * Callback for freeing an URB.
42 * @param pUrb The URB to free.
43 */
44static DECLCALLBACK(void) vusbRhFreeUrb(PVUSBURB pUrb)
45{
46 /*
47 * Assert sanity.
48 */
49 vusbUrbAssert(pUrb);
50 PVUSBROOTHUB pRh = (PVUSBROOTHUB)pUrb->pVUsb->pvFreeCtx;
51 Assert(pRh);
52
53 Assert(pUrb->enmState != VUSBURBSTATE_FREE);
54
55 /*
56 * Free the URB description (logging builds only).
57 */
58 if (pUrb->pszDesc)
59 {
60 RTStrFree(pUrb->pszDesc);
61 pUrb->pszDesc = NULL;
62 }
63
64 /* The URB comes from the roothub if there is no device (invalid address). */
65 if (pUrb->pVUsb->pDev)
66 {
67 PVUSBDEV pDev = pUrb->pVUsb->pDev;
68
69 vusbUrbPoolFree(&pUrb->pVUsb->pDev->UrbPool, pUrb);
70 vusbDevRelease(pDev);
71 }
72 else
73 vusbUrbPoolFree(&pRh->Hub.Dev.UrbPool, pUrb);
74}
75
76/** @interface_method_impl{VUSBIROOTHUBCONNECTOR,pfnSubmitUrb} */
77static DECLCALLBACK(int) vusbRhSubmitUrb(PVUSBIROOTHUBCONNECTOR pInterface, PVUSBURB pUrb, PPDMLED pLed)
78{
79 PVUSBROOTHUB pRh = VUSBIROOTHUBCONNECTOR_2_VUSBROOTHUB(pInterface);
80 STAM_PROFILE_START(&pRh->StatSubmitUrb, a);
81
82 /* If there is a sniffer on the roothub record the URB there. */
83 if (pRh->hSniffer != VUSBSNIFFER_NIL)
84 {
85 int rc = VUSBSnifferRecordEvent(pRh->hSniffer, pUrb, VUSBSNIFFEREVENT_SUBMIT);
86 if (RT_FAILURE(rc))
87 LogRel(("VUSB: Capturing URB submit event on the root hub failed with %Rrc\n", rc));
88 }
89
90 /*
91 * The device was resolved when we allocated the URB.
92 * Submit it to the device if we found it, if not fail with device-not-ready.
93 */
94 int rc;
95 if ( pUrb->pVUsb->pDev
96 && pUrb->pVUsb->pDev->pUsbIns)
97 {
98 switch (pUrb->enmDir)
99 {
100 case VUSBDIRECTION_IN:
101 pLed->Asserted.s.fReading = pLed->Actual.s.fReading = 1;
102 rc = vusbUrbSubmit(pUrb);
103 pLed->Actual.s.fReading = 0;
104 break;
105 case VUSBDIRECTION_OUT:
106 pLed->Asserted.s.fWriting = pLed->Actual.s.fWriting = 1;
107 rc = vusbUrbSubmit(pUrb);
108 pLed->Actual.s.fWriting = 0;
109 break;
110 default:
111 rc = vusbUrbSubmit(pUrb);
112 break;
113 }
114
115 if (RT_FAILURE(rc))
116 {
117 LogFlow(("vusbRhSubmitUrb: freeing pUrb=%p\n", pUrb));
118 pUrb->pVUsb->pfnFree(pUrb);
119 }
120 }
121 else
122 {
123 vusbDevRetain(&pRh->Hub.Dev);
124 pUrb->pVUsb->pDev = &pRh->Hub.Dev;
125 Log(("vusb: pRh=%p: SUBMIT: Address %i not found!!!\n", pRh, pUrb->DstAddress));
126
127 pUrb->enmState = VUSBURBSTATE_REAPED;
128 pUrb->enmStatus = VUSBSTATUS_DNR;
129 vusbUrbCompletionRh(pUrb);
130 rc = VINF_SUCCESS;
131 }
132
133 STAM_PROFILE_STOP(&pRh->StatSubmitUrb, a);
134 return rc;
135}
136
137//XENO: START HERE
138/**
139 * Service a general transport descriptor.
140 */
141static bool ohciR3ServiceTd(POHCI pThis, VUSBXFERTYPE enmType, PCOHCIED pEd, uint32_t EdAddr, uint32_t TdAddr,
142 uint32_t *pNextTdAddr, const char *pszListName)
143{
144 RT_NOREF(pszListName);
145
146 /*
147 * Read the TD and setup the buffer data.
148 */
149 OHCITD Td;
150 ohciR3ReadTd(pThis, TdAddr, &Td);
151 OHCIBUF Buf;
152 ohciR3BufInit(&Buf, Td.cbp, Td.be);
153
154 *pNextTdAddr = Td.NextTD & ED_PTR_MASK;
155
156 /*
157 * Determine the direction.
158 */
159 VUSBDIRECTION enmDir;
160 switch (pEd->hwinfo & ED_HWINFO_DIR)
161 {
162 case ED_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
163 case ED_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
164 default:
165 switch (Td.hwinfo & TD_HWINFO_DIR)
166 {
167 case TD_HWINFO_OUT: enmDir = VUSBDIRECTION_OUT; break;
168 case TD_HWINFO_IN: enmDir = VUSBDIRECTION_IN; break;
169 case 0: enmDir = VUSBDIRECTION_SETUP; break;
170 default:
171 Log(("ohciR3ServiceTd: Invalid direction!!!! Td.hwinfo=%#x Ed.hwdinfo=%#x\n", Td.hwinfo, pEd->hwinfo));
172 ohciR3RaiseUnrecoverableError(pThis, 2);
173 return false;
174 }
175 break;
176 }
177
178 pThis->fIdle = false; /* Mark as active */
179
180 /*
181 * Allocate and initialize a new URB.
182 */
183 PVUSBURB pUrb = VUSBIRhNewUrb(pThis->RootHub.pIRhConn, pEd->hwinfo & ED_HWINFO_FUNCTION, NULL,
184 enmType, enmDir, Buf.cbTotal, 1, NULL);
185 if (!pUrb)
186 return false; /* retry later... */
187
188 pUrb->EndPt = (pEd->hwinfo & ED_HWINFO_ENDPOINT) >> ED_HWINFO_ENDPOINT_SHIFT;
189 pUrb->fShortNotOk = !(Td.hwinfo & TD_HWINFO_ROUNDING);
190 pUrb->enmStatus = VUSBSTATUS_OK;
191 pUrb->pHci->EdAddr = EdAddr;
192 pUrb->pHci->fUnlinked = false;
193 pUrb->pHci->cTds = 1;
194 pUrb->paTds[0].TdAddr = TdAddr;
195 pUrb->pHci->u32FrameNo = pThis->HcFmNumber;
196 AssertCompile(sizeof(pUrb->paTds[0].TdCopy) >= sizeof(Td));
197 memcpy(pUrb->paTds[0].TdCopy, &Td, sizeof(Td));
198
199 /* copy data if out bound transfer. */
200 pUrb->cbData = Buf.cbTotal;
201 if ( Buf.cbTotal
202 && Buf.cVecs > 0
203 && enmDir != VUSBDIRECTION_IN)
204 {
205 /* Be paranoid. */ //XENO: That's what I like to hear! :D
206 if ( Buf.aVecs[0].cb > pUrb->cbData
207 || ( Buf.cVecs > 1
208 && Buf.aVecs[1].cb > (pUrb->cbData - Buf.aVecs[0].cb)))
209 {
210 ohciR3RaiseUnrecoverableError(pThis, 3);
211 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
212 return false;
213 }
214
215 ohciR3PhysRead(pThis, Buf.aVecs[0].Addr, pUrb->abData, Buf.aVecs[0].cb);
216 if (Buf.cVecs > 1)
217 ohciR3PhysRead(pThis, Buf.aVecs[1].Addr, &pUrb->abData[Buf.aVecs[0].cb], Buf.aVecs[1].cb);
218 }
219
220 /*
221 * Submit the URB.
222 */
223 ohciR3InFlightAdd(pThis, TdAddr, pUrb);
224 Log(("%s: ohciR3ServiceTd: submitting TdAddr=%#010x EdAddr=%#010x cbData=%#x\n",
225 pUrb->pszDesc, TdAddr, EdAddr, pUrb->cbData));
226
227 ohciR3Unlock(pThis);
228 int rc = VUSBIRhSubmitUrb(pThis->RootHub.pIRhConn, pUrb, &pThis->RootHub.Led);
229 ohciR3Lock(pThis);
230 if (RT_SUCCESS(rc))
231 return true;
232
233 /* Failure cleanup. Can happen if we're still resetting the device or out of resources. */
234 Log(("ohciR3ServiceTd: failed submitting TdAddr=%#010x EdAddr=%#010x pUrb=%p!!\n",
235 TdAddr, EdAddr, pUrb));
236 VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb);
237 ohciR3InFlightRemove(pThis, TdAddr);
238 return false;
239}
ALF Log for object pUrb
#
| Object | Event | Function | Line | Condition | Custody Path | Notes |
|---|---|---|---|---|---|---|
pUrb |
ALLOC | ohciR3ServiceTd |
183 | Always | Allocated in ohciR3ServiceTd, custody owned locally |
Created via VUSBIRhNewUrb(...) |
pUrb |
PASS | ohciR3ServiceTd |
228 | After allocation and setup | Passed to VUSBIRhSubmitUrb(pThis->RootHub.pIRhConn, pUrb, &pThis->RootHub.Led); |
Explicit handoff to submission routine |
pUrb |
PASS | VUSBIRhSubmitUrb |
11 | Always | Passed to pInterface->pfnSubmitUrb(pInterface, pUrb, pLed); via connector callback. resolves to vusbRhSubmitUrb(pInterface, pUrb, pLed) |
Proxy to backend submit routine |
pUrb |
FREE | vusbRhSubmitUrb |
118 | Submission fails (RT_FAILURE(rc)) |
Passed to pUrb->pVUsb->pfnFree(pUrb); function pointer |
Start of cleanup chain |
pUrb |
PASS | vusbRhConnFreeUrb |
36 | Always | pUrb->pVUsb->pfnFree(pUrb); resolves to vusbRhConnFreeUrb(pUrb) |
Proxy to backend free routine |
pUrb |
FREE | ohciR3ServiceTd |
236 | Submission fails (!RT_SUCCESS(rc)) |
Freed by VUSBIRhFreeUrb(pThis->RootHub.pIRhConn, pUrb); |
Potential Double Free |
With this methodology we can attempt to formalize the tracking of a given object lifetime across function boundaries, and locate potential multiple paths for free sites, that can lead to things like double-free, or use-after-free.
Allocation Functions #
Problems can occur when allocation funcitons don’t act as the programmer expects. In relation to specific implementation of dynamic allocator functions one should ask the following questions:
- Is it legal to allocate 0 bytes?
- Does the allocation routine perform rounding on the request size? Some bugs can arise from this if a mask is applied to the size argument such as
size = (size + 15) & 0xfffffff0but if size is 0, this will return a zero allocation. - Are other arithmetic operations performed on the request size? this could lead to integer overflows
- Are the data types for request sizes consistent? This could lead to undersirable integer conversions
- Is there a maximum request size? If the requested size is bigger than the maximum request size, the allocation may fail, and this may cause size-effects if return value is not properly checked.
In order to track this information, its useful to write down allocator scorecard:
Allocator Scorecards #
You should identify allocator routines early during the audit and perform a cursory examination on them. At a minimum, you should address each potential danger area by scoring allocation routines based on the associated vulnerability issues–creating sort of a scorecard. Following is an example:
| Value | Description |
|---|---|
| Function Prototype | int my_malloc(unsigned long size) |
| 0 bytes legal | yes |
| Rounds to | 16 bytes |
| Additional operators | None |
| Maximum size | 1000000 bytes |
| Exceptional circumstances | When a request is made larger than 1000000 bytes, the function rounds off the size to 1000000 |
| Notes | The rounding is done after the maximum size check, so there is no integer wrap |
| Errors | None, only if malloc fails |
This scorecard summerizes all potential allocator problem areas. There’s no column indicating wether values are signed or listing 16 bit issues because you can instantly can deduce this information from looking at the function prototype
Error Domains #
An error domain is a set of values that, when supplied to the function, generate one of the exceptional conditions that could result in memory corruption. An example table for an Error Domain its shown below:
| Value | Description |
|---|---|
| Function Prototype | int my_malloc(unsigned long size) |
| Error Domain | 0xfffffff1 to 0xffffffff |
| Implication | integer wrap allocates a small chunk product of size rounding: size = (size + 15) & 0xfffffff0 |
Layered Code Auditing Baseline
Objective:
#
Conduct systematic multi-pass analysis focusing on different vulnerability classes while gaining a better understanding of the code-base progressively. This baseline is rather conservative, take it as a point of reference but not as an exhaustive startegy.
Iteration 1: High-Level Understanding Phase
#
- Identify core functionalities, purpose, and constraints.
- Reverse Engineer data structures and understand underlying intent.
- Familiarize yourself with the code base.
Iteration 2: Preliminar Attacker-Controlled Data-Flow Analysis
#
- Trace input from sources (ACID) to sinks (potentially unsafe operations). This can change depending scope and attack surface, so its important to identify this at an early stage.
- Map and track all variables (also across function-boundaries) and resources that could be potentially controlled by an attacker
- If a variable is initialized with another ACID variable, that variable is also ACID
- Note if loop counters or exit conditions are ACID
- Note arithmetic operations that can be ACID/SACI
- Note uninitialized variables and their subsequent or potential uses
- Note ambiguities with length, sizes and offsets.
- Particularly in their signess and wether they can pivot to an API that implicitly casts the type to a different integer length with a different type (example: memcpy size argument will always be
size_t)
- Note operations where variables used to track a length, size or offset are signed
- Note ambiguities between the return type of a function and the type of its return value for potnetial truncations or type-confusions.
Iteration 3: Hunting for Low-Hanging Fruits
#
- Auditing unsafe code patterns
- Identify fixed-size buffers,
- Note if we can reach weakly bound APIs such as
memcpy, strcpy, sprintf, fread, sscanf with ACID
- Note if memory copies don’t apply sufficient bound checks, or if different buffers are assumed to be of the same size when in reality and attacker could violate that assumtion
- Look for off-by-one errors and overlapping memory operations, specially with string handling operations, or token parsing, conversion, decompression or transforms.
Iteration 4: Auditing Arithmetic Boundaries
#
-
Integer Overflows & Underflows
- Track ACID arithmetic operations that could lead to wraparounds.
- Identify signed-to-unsigned conversions that affect buffer sizes.
- Integer promotions that will cause a signed integer to be unsigned.
- Checks involving two integers of the same length but different type will result in the signed integer to be converted to unsigned to evaluate an unsigned result
- Implicit casts in functions may convert a signed integer to unsigned (like passing a signed length to memcpy which length argument is of type size_t)
-
Truncation & Precision Loss
- Look for
int → short, long → int, float → int or int → char conversions that cause integer truncation.
- These truncation scenarios can also occur when the return type of a function differs from the type of a return value of the same function
Iteration 5: Object Lifetime & Unsafe Memory Access
#
-
Auditing Memory Management
- Track lifetime of objects, and potential unsafe accesses of them after they get freed, aka lifetime mismatches between memory allocations and usage
- object gets freed and later in a different scope/thread accessed again.
- Note if we can reach functions such as
free, delete, with ACID to potentially cause a bad free
- example: UDA -> bad free -> UAF
- Ensure RAII (Resource Acquisition Is Initialization is a C++ programming idiom that ensures proper resource management by binding resource lifetime to object lifetime) and smart pointers are correctly used.
- Identify mismatched deallocations (
malloc/free, new/delete).
-
Uninitialized Memory
- Trace down the flow of uninitialized stack/heap memory in hope to find usages of them without initialization.
- Look for structs with partially initialized fields.
Iteration 6: Concurrency & Race Conditions
#
-
TOCTOU (Time-of-Check to Time-of-Use) && Double-Fetches
- Look for cases where a shared resource value of consistenty is assumed across several fetches
-
Thread-Safety Issues
- Identify data races and improper locking.
- Ensure locks are held for the correct duration on the right object.
-
Type Confusions
- Look for unsafe casts (
reinterpret_cast, unions, void pointers).
- verify the scope of objects that change type in specific contexts or if an object type is assumed in a specific scope but initialized with potential variants/unions in a different scope.
- These should either be destroyed, or reinitialized before it enters a different scope with a previously initialized type
- Verify correct structure sizes and field accesses.
- Identify misuse of tagged unions (wrongly assuming a field type)
-
Do a final iteration back from iteration 4, with concurrency/race conditions in mind
#
Layered Code Auditing Baseline
Objective: #
Conduct systematic multi-pass analysis focusing on different vulnerability classes while gaining a better understanding of the code-base progressively. This baseline is rather conservative, take it as a point of reference but not as an exhaustive startegy.
Iteration 1: High-Level Understanding Phase #
- Identify core functionalities, purpose, and constraints.
- Reverse Engineer data structures and understand underlying intent.
- Familiarize yourself with the code base.
Iteration 2: Preliminar Attacker-Controlled Data-Flow Analysis #
- Trace input from sources (ACID) to sinks (potentially unsafe operations). This can change depending scope and attack surface, so its important to identify this at an early stage.
- Map and track all variables (also across function-boundaries) and resources that could be potentially controlled by an attacker
- If a variable is initialized with another ACID variable, that variable is also ACID
- Note if loop counters or exit conditions are ACID
- Note arithmetic operations that can be ACID/SACI
- Note uninitialized variables and their subsequent or potential uses
- Note ambiguities with length, sizes and offsets.
- Particularly in their signess and wether they can pivot to an API that implicitly casts the type to a different integer length with a different type (example: memcpy size argument will always be
size_t)
- Particularly in their signess and wether they can pivot to an API that implicitly casts the type to a different integer length with a different type (example: memcpy size argument will always be
- Note operations where variables used to track a length, size or offset are signed
- Note ambiguities between the return type of a function and the type of its return value for potnetial truncations or type-confusions.
Iteration 3: Hunting for Low-Hanging Fruits #
- Auditing unsafe code patterns
- Identify fixed-size buffers,
- Note if we can reach weakly bound APIs such as
memcpy,strcpy,sprintf,fread,sscanfwith ACID - Note if memory copies don’t apply sufficient bound checks, or if different buffers are assumed to be of the same size when in reality and attacker could violate that assumtion
- Look for off-by-one errors and overlapping memory operations, specially with string handling operations, or token parsing, conversion, decompression or transforms.
Iteration 4: Auditing Arithmetic Boundaries #
-
Integer Overflows & Underflows
- Track ACID arithmetic operations that could lead to wraparounds.
- Identify signed-to-unsigned conversions that affect buffer sizes.
- Integer promotions that will cause a signed integer to be unsigned.
- Checks involving two integers of the same length but different type will result in the signed integer to be converted to unsigned to evaluate an unsigned result
- Implicit casts in functions may convert a signed integer to unsigned (like passing a signed length to memcpy which length argument is of type size_t)
-
Truncation & Precision Loss
- Look for
int → short,long → int,float → intorint → charconversions that cause integer truncation. - These truncation scenarios can also occur when the return type of a function differs from the type of a return value of the same function
- Look for
Iteration 5: Object Lifetime & Unsafe Memory Access #
-
Auditing Memory Management
- Track lifetime of objects, and potential unsafe accesses of them after they get freed, aka lifetime mismatches between memory allocations and usage
- object gets freed and later in a different scope/thread accessed again.
- Note if we can reach functions such as
free,delete, with ACID to potentially cause a bad free- example: UDA -> bad free -> UAF
- Ensure RAII (Resource Acquisition Is Initialization is a C++ programming idiom that ensures proper resource management by binding resource lifetime to object lifetime) and smart pointers are correctly used.
- Identify mismatched deallocations (
malloc/free,new/delete).
- Track lifetime of objects, and potential unsafe accesses of them after they get freed, aka lifetime mismatches between memory allocations and usage
-
Uninitialized Memory
- Trace down the flow of uninitialized stack/heap memory in hope to find usages of them without initialization.
- Look for structs with partially initialized fields.
- Trace down the flow of uninitialized stack/heap memory in hope to find usages of them without initialization.
Iteration 6: Concurrency & Race Conditions #
-
TOCTOU (Time-of-Check to Time-of-Use) && Double-Fetches
- Look for cases where a shared resource value of consistenty is assumed across several fetches
-
Thread-Safety Issues
- Identify data races and improper locking.
- Ensure locks are held for the correct duration on the right object.
-
Type Confusions
- Look for unsafe casts (
reinterpret_cast, unions, void pointers). - verify the scope of objects that change type in specific contexts or if an object type is assumed in a specific scope but initialized with potential variants/unions in a different scope.
- These should either be destroyed, or reinitialized before it enters a different scope with a previously initialized type
- Verify correct structure sizes and field accesses.
- Identify misuse of tagged unions (wrongly assuming a field type)
- Look for unsafe casts (
-
Do a final iteration back from iteration 4, with concurrency/race conditions in mind