55%
11%
66%
The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line. This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects.
CVSS 3.1 Base Score 5.6. CVSS Attack Vector: local. CVSS Attack Complexity: high. CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N).
The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.
}}print "Login Successful";print "Login Failed - incorrect password";print "Login Failed - unknown username";
In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.
While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:
"Login Failed - incorrect username or password"
Non-uniform processing time causes timing channel.
Suppose a hardware IP for implementing an encryption routine works fine per se, but the time taken to output the result of the encryption routine depends on a certain relationship between the input plaintext and the key (e.g., suppose, if the plaintext is similar to the key, it would run very fast).
In the example above, an attacker can vary the inputs and, depending on the seen differences between processing times (different plaintexts take different time), can infer certain information about the key.
If the actual processing time was different for different plaintexts, artificial delays can be introduced to ensured all plaintexts take equal time to execute, even though the timing was internally different.
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.