78%
18%
98%
fpregs_state_valid in arch/x86/include/asm/fpu/internal.h in the Linux kernel before 5.4.2, when GCC 9 is used, allows context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact because of incorrect fpu_fpregs_owner_ctx caching, as demonstrated by mishandling of signal-based non-cooperative preemption in Go 1.14 prereleases on amd64, aka CID-59c4bd853abc.
fpregs_state_valid in arch/x86/include/asm/fpu/internal.h in the Linux kernel before 5.4.2, when GCC 9 is used, allows context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact because of incorrect fpu_fpregs_owner_ctx caching, as demonstrated by mishandling of signal-based non-cooperative preemption in Go 1.14 prereleases on amd64, aka CID-59c4bd853abc.
CVSS 3.1 Base Score 7.8. CVSS Attack Vector: local. CVSS Attack Complexity: low. CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
CVSS 2.0 Base Score 6.9. CVSS Attack Vector: local. CVSS Attack Complexity: medium. CVSS Vector: (AV:L/AC:M/Au:N/C:C/I:C/A:C).
CVSS 3.1 Base Score 6.1. CVSS Attack Vector: local. CVSS Attack Complexity: low. CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L).
CVSS 2.0 Base Score 5.4. CVSS Attack Vector: local. CVSS Attack Complexity: medium. CVSS Vector: (AV:L/AC:M/Au:N/C:C/I:N/A:P).
The following code sets the umask of the process to 0 before creating a file and writing "Hello world" into the file.
}/* Ignore CWE-59 (link following) for brevity */fclose(out);After running this program on a UNIX system, running the "ls -l" command might return the following output:
-rw-rw-rw- 1 username 13 Nov 24 17:58 hello.outThe "rw-rw-rw-" string indicates that the owner, group, and world (all users) can read the file and write to it.
This code creates a home directory for a new user, and makes that user the owner of the directory. If the new directory cannot be owned by the user, the directory is deleted.
}return true;return false;return false;Because the optional "mode" argument is omitted from the call to mkdir(), the directory is created with the default permissions 0777. Simply setting the new user as the owner of the directory does not explicitly change the permissions of the directory, leaving it with the default. This default allows any user to read and write to the directory, allowing an attack on the user's files. The code also fails to change the owner group of the directory, which may result in access by unexpected groups.
This code may also be vulnerable to Path Traversal (CWE-22) attacks if an attacker supplies a non alphanumeric username.
The following code snippet might be used as a monitor to periodically record whether a web site is alive. To ensure that the file can always be modified, the code uses chmod() to make the file world-writable.
close($outFH);chmod 0777, $fileName;ExitError("Couldn't append to $fileName: $!");The first time the program runs, it might create a new file that inherits the permissions from its environment. A file listing might look like:
-rw-r--r-- 1 username 13 Nov 24 17:58 secretFile.outThis listing might occur when the user has a default umask of 022, which is a common setting. Depending on the nature of the file, the user might not have intended to make it readable by everyone on the system.
The next time the program runs, however - and all subsequent executions - the chmod will set the file's permissions so that the owner, group, and world (all users) can read the file and write to it:
-rw-rw-rw- 1 username 13 Nov 24 17:58 secretFile.outPerhaps the programmer tried to do this because a different process uses different permissions that might prevent the file from being updated.
The following command recursively sets world-readable permissions for a directory and all of its children:
chmod -R ugo+r DIRNAMEIf this command is run from a program, the person calling the program might not expect that all the files under the directory will be world-readable. If the directory is expected to contain private data, this could become a security problem.
The following code shows a simple example of a use after free error:
}free(ptr);logError("operation aborted before commit", ptr);When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.
In the following C/C++ example the method processMessage is used to process a message received in the input array of char arrays. The input message array contains two char arrays: the first is the length of the message and the second is the body of the message. The length of the message is retrieved and used to allocate enough memory for a local char array, messageBody, to be created for the message body. The messageBody is processed in the method processMessageBody that will return an error if an error occurs while processing. If an error occurs then the return result variable is set to indicate an error and the messageBody char array memory is released using the method free and an error message is sent to the logError method.
}
return result;
}free(messageBody);result = FAIL;logError("Error processing message", messageBody);However, the call to the method logError includes the messageBody after the memory for messageBody has been released using the free method. This can cause unexpected results and may lead to system crashes. A variable should never be used after its memory resources have been released.
...free(messageBody);ExploitPedia is constantly evolving. Sign up to receive a notification when we release additional functionality.
If you'd like to report a bug or have any suggestions for improvements then please do get in touch with us using this form. We will get back to you as soon as we can.