# SS HW 9?
# 1
Consider the following function for string comparison:
```
def compare(string1, string2):
if len(string2) != len(string1):
return False
for i in range(len(string2)):
if string2[i] != string1[i]:
return False
return True
```
In this function, the length of two passwords is compared. Each character of the two passwords is compared and the function returns False when there is a difference. Therefore, a timing attack can be implemented by an adversary by measuring and comparing the computation times of each input. If the adversary gets “False” immediately, it will mean that the length of the user’s input is incorrect. The adversary can proceed to guess the length of the password if the response time is longer/shorter than the previous attempts. Finally, the adversary can guess can first, second, third, or N-th character of the password one by one by comparing the response time, or by brute-forcing the password directly if the length of the password is short.
- The problem with this system is that the program gives out too much information to the user through the
1) The program checks for the length of the password, which if failing, would instantly return a False. Using the time taken to return False, the attacker can measure the time taken to check whether it passes the first length conditional or not. If it still returns False but takes slightly longer then the length of the input can be recorded.
(Although this might be very hard to do given the simplicity of the program)
2) Once the length is ascertained, the False returned would be coming from the for loop checking the string. Measuring the time taken would be making checks to see whether the element on index i is equal to the password.
Example of what is being done:

Learning the real password can be done by interacting the 2 conditionals in the function.
Pseudo code to learning the real password
```
func crack_password(real_passwd):
while password not found:
initialise length
randomise (guessed_passwd)
if compare(real_passwd, guessed_passwd) returns False:
check time
--> If the time is really fast then increase the length
and repeat until time taken increases significantly to
find the length of the password
--> if the length has been ascertained
(by checking that the time taken has basically stagnated) then
start randomising checking for each element of the string index.
If the time taken increases, save the element,
craft the password character by character.
Repeat until password is found.
else:
password is found
```
The propsoed fix is to hash the password using SHA-256 to create unique hashes. It is virtually almost undoable with current technology to brute force crack to find the hash, it is also not possible to find the original password since hashing is a one way method since the goal is to learn the original string of the password.
Proof-of-concept for the Proposed fix:
```
hash the real password using SHA-256
run the hashed_password through the crack_passwd function
func crack_password(real_passwd):
while password not found:
initialise length
randomise (guessed_passwd)
if compare(real_passwd, guessed_passwd) returns False:
check time
--> If the time is really fast then increase the length
and repeat until time taken increases significantly to
find the length of the password
--> if the length has been ascertained
(by checking that the time taken has basically stagnated) then
start randomising checking for each element of the string index.
If the time taken increases, save the element,
craft the password character by character.
Repeat until password is found.
else:
password is found
This won't work because the
```
Due to the sheer length and number of combinations made by the hashing, it is pretty much impossible to brute force it since it will take at least 3.5 * 10 ^ 63 seconds = 1.1 * 10 ^ 57 years to crack.
# 2
Meltdown is a type of side-channel attack that exploits a flaw in modern microprocessors to steal sensitive data such as passwords, encryption keys, and other private information. The main steps an attacker needs to carry out for the Meltdown attack are:
1. Gain access to the victim's system: The attacker needs to gain access to the target system, either physically or remotely, to execute the Meltdown attack.
2. Identify the target data: The attacker needs to identify the specific data that they want to steal, such as passwords, encryption keys, or other sensitive information.
3. Execute the Meltdown attack: The attacker uses the Meltdown exploit to leak the target data from the victim's system. The Meltdown exploit takes advantage of a vulnerability in modern microprocessors, which allows an attacker to access sensitive data from the victim's system memory.
4. Steal the data: Once the data has been leaked, the attacker can steal it and use it for their own purposes.

#### Defense MEchanism
##### Preventing Access to Secret Data.
(1) A web browser can execute each web site in a separate process. If spectre is exploited on any web site (say, using Javascript), the attack will not be able to access data from the processes assigned to other web sites. (2) Index masking can replace bounds check to avoid branch jumping. This is not fool proof, as a mask (~ powers of 2) may result in an access outside the required bound. However, it limits the distance of the bounds violation, preventing the attacker from accessing arbitrary memory. (3) Access to pointers could be protected by XOR-ing with a pseudo-random poison value. Not only could the pseudorandom value make it harder for an attacker to find its value, but more significantly, it ensures that mispredictions on the branch instructions used for type checks will result in pointers associated with type being used for another type.
These approaches are most useful for JIT compilers, interpreters and other language-based protections, where the runtime environment has control over the executed code and wishes to restrict the data that a program may access.
##### Preventing Data from Entering Covert Channels
Potentially, processors could track whether data was fetched as a result of speculative operation. If so, data should be prevented from being used in subsequent operations.
However, the effectiveness remains an uncertainty until such processors are developed. At that point in time, depending on the implementation, an attacker could potentially "race" (or adopt another side- or covert-channel) to use the cached data before the prevention mechanism kicks in.
##### Limiting data extraction from covert channels
In Javascript, sharedArrayBuffers could be used to create a timing source in conjunction with performance.now(). Resolution of timers (and potentially adding jitters) could make it harder to carry out timing attacks. Also, browsers by default disabled this shared memory and high-resolution timers in light of Spectre attacks.
While this approach is easy to roll out as a patch, the errors in data exfiltration (due to a low-resolution timer) could be “smoothened” by averaging, though with a reduction in throughput. So, this approach does not guarantee attacks are not possible.
##### Preventing Branch PoisoningPreventing Branch Poisoning
Variant 2 could be mitigated by preventing indirect branch poisoning.
Mechanism by Intel & AMD:
1) Indirect Branch Restricted Speculation (IBRS)
o Restriction based on code privilege levels.
o Prevents indirect branches in privileged code from being affected by branches in less privileged code.
2) Single Thread Indirect Branch Prediction (STIBP)
o Restricts branch prediction sharing between software executing on the hyperthreads of the same core.
3) Indirect Branch Predictor Barrier (IBPB)
o Prevents software running before setting the barrier (i.e. by flushing the BTB state).
These mechanisms require OS/BIOS support for use. Depending on the number and combination of mechanisms used, performance degradation could be factor of 4 of more.
###### Mechanism by Google:
1) Retpoline
o Replaces indirect branches with return instructions.
o Ensures the return instruction is predicted to a benign endless loop.
o The actual target destination is reached by pushing it on the stack (expensive instruction) and returning to it.
If return instructions could be predicted by other means, retpoline may be impractical. Hence, Intel issued microcode updates for processors to disable fall-back to BTB for such predictions.
##### Detecting vulnerable endpoints.
1) Spectroscope by Google.
o A prototype extension to web browsers to search for endpoints potentially vulnerable to Spectre.
o Meant to help security engineers and web developers to track application resources that are not protected from being embedded by other websites (which could then be used for Spectre attack).
Spectroscope is meant as a convenience tool, rather than an official security testing product.