PUBLIC / CYHOEDDUS
Table of Contents
Contents
Table of Contents ....................................................................................................... 1
Table of Figures ......................................................................................................... 2
Glossary of Terms ...................................................................................................... 3
Introduction ................................................................................................................ 4
Overview of debugging tools ...................................................................................... 9
Technical Analysis of Spectre POC.......................................................................... 13
Victim Code (victim_function) ............................................................................... 14
Analysis Code (main and readMemoryByte): ....................................................... 14
Utilized Libraries: .................................................................................................. 15
Execution and Outcomes: ..................................................................................... 15
Conclusion ............................................................................................................... 16
References ............................................................................................................... 18
PUBLIC / CYHOEDDUS
Table of Figures
PUBLIC / CYHOEDDUS
Glossary of Terms
POC
Proof of Concept
PUBLIC / CYHOEDDUS
Introduction
Spectre is a security flaw that allows unauthorized access to sensitive data via modern
microprocessors' speculative execution. CPUs use the performance optimization
technique of speculative execution to execute instructions before it is certain that they
will be required. This enables the CPU to continue executing code and conceals
memory access latencies, resulting in significant performance gains.
In Spectre attacks, an attacker tricks the CPU into executing code that ordinarily would
not be executed. Using carefully crafted code, an adversary can cause the CPU to
access sensitive data and then measure the timing of these accesses. This temporal
information can be used to infer the sensitive data's contents, such as encryption keys
or passwords.
Speculative execution is a fundamental optimization technique used by modern
microprocessors to enhance the overall efficacy of a computer system. It enables the
CPU to execute instructions out of order, which means that the CPU does not wait for
a particular instruction to be certified as required before executing it. This can result in
increased CPU utilization and decreased program execution latency.
Vulnerability to Speculative Execution: Spectre exploits the side effects of speculative
execution. Modern processors use speculative execution to predict the probable
outcome of conditional code branches. Before it is determined whether the branch
PUBLIC / CYHOEDDUS
should be taken, the processor begins executing instructions from the predicted
branch path.
In a Spectre attack, an adversary creates code that exploits speculative execution.
The attacker inserts conditional branches into the code, with one branch (the "victim"
branch) able to access confidential data and the other branch (the "attacker" branch)
unable to do so. The perpetrator manipulates the processor's branch prediction so that
the victim branch is executed speculatively.
Since speculative execution does not commit changes to registers or memory until it
is confirmed that the speculative execution path is the correct one, the CPU's state
may undergo transient changes. These modifications may affect the CPU's cache
state. Spectre utilizes timing side channels to determine the time required to access
memory data.
When the CPU makes a speculative data access, it may place that data into its cache.
If the data is already in the cache, accessing it is significantly quicker than if it is not.
Spectre attacks involve measuring the timing of cache accesses during speculative
execution in order to infer the contents of specific memory locations that were
accessed.
By measuring the amount of time required to access memory, an adversary can infer
whether or not the speculative execution path accessed sensitive data. This
information can be used to disclose sensitive data, including cryptographic keys,
passwords, and other confidential information.
Because Spectre is fundamentally a hardware vulnerability, software alone cannot
completely address it. CPU manufacturers have implemented microcode and
hardware modifications to increase the security of speculative execution. In addition,
software engineers have employed techniques such as code reordering and compiler
optimizations to mitigate the risk of Spectre attacks. Operating systems and
hypervisors have also incorporated safeguards to effectively isolate distinct
processes.
PUBLIC / CYHOEDDUS
Spectre is an evolving and complex security risk. Significant research and
development efforts have been made in both the hardware and software industries to
better defend against these types of attacks and maintain the balance between
performance and security in modern processors. It serves as a reminder of the
ongoing game of cat-and-mouse between security researchers and assailants.
Importance of studying spectre attacks.
In response to the Spectre threat, CPU makers have been working hard to improve
the security of their microarchitectures. These efforts resulted in the inclusion of
features like "indirect branch prediction barriers." These restrictions are critical in
avoiding the speculative execution of indirect branches from being abused. They
effectively lower the likelihood of Spectre attacks by making manipulating the
processor's branch prediction systems substantially more difficult.
Balancing security and performance has been a major difficulty in the continuing battle
against Spectre. Many of the hardware and software changes aimed to improve
security come at the expense of diminished performance. Certain mitigating strategies,
for example, entail flushing the speculative execution pipeline, which can result in
increased execution times for certain workloads. This trade-off highlights the delicate
balance that must be maintained between security and performance, a consideration
that continues to define the approach to Spectre mitigation.
Software developers have been actively investigating various techniques to mitigate
the Spectre danger. Recompiling software using compiler optimizations, integrating
"retpoline" techniques to protect against return-oriented programming—an attack
vector widely exploited in Spectre—and installing runtime libraries that enable
protections against these vulnerabilities are among these strategies. These softwarelevel mitigations are an important component of the protection strategy since they help
to reduce the impact of Spectre attacks.
PUBLIC / CYHOEDDUS
The constant discovery of new variations of the Spectre threat demonstrates the
problem's persistence. Security researchers are still investigating new attack methods
and creating proofs of concept to uncover vulnerabilities. This ongoing monitoring and
research is critical for staying one step ahead of possible threats and refining
countermeasures as the threat landscape evolves.
As security defenses improve, so do the strategies used by attackers. Adversaries'
ways for exploiting Spectre and related vulnerabilities are constantly evolving. To
achieve their goals, they may combine Spectre attacks with additional approaches
such as privilege escalation or the injection of malicious code. This adaptability
emphasizes the need for broad and ever-evolving defenses to properly defeat these
threats.
Recognizing the collaborative nature of the threat, the tech industry has embraced
collaboration as a key tactic to defeat Spectre. This collaboration includes CPU
makers, software developers, and security experts. To keep up with the ever-changing
threat landscape, information sharing and coordinated efforts are deemed critical.
Mechanisms for responsible disclosure and the exchange of vulnerability information
have become essential components of the industry's response to Spectre.
In addition to microarchitectural improvements, some businesses are looking into
hardware-based solutions to solve Spectre vulnerabilities. These solutions may
include the use of specialized hardware components that separate critical functions,
making it far more difficult for attackers to exploit speculative execution. These
hardware-focused approaches provide an additional layer of Spectre protection.
Spectre attacks frequently rely on social engineering approaches, forcing users to
unintentionally run malicious code. User education and awareness are critical in
mitigating these threats. Educating users about the dangers of running untrusted code,
downloading email attachments, and clicking on strange links is an effective way to
mitigate the impact of Spectre and related attacks.
PUBLIC / CYHOEDDUS
In some countries, talks have erupted about enacting legislation and rules to hold
firms liable for security flaws like Spectre. These measures are intended to encourage
firms to emphasize security in their products and services, highlighting the significance
of strong security measures in the technology sector.
To find and address security vulnerabilities, particularly those connected to Spectre,
companies are increasingly turning to ethical hackers and bug bounty programs.
These programs incentivize security experts to uncover and report vulnerabilities
before hostile actors can exploit them, fostering an industry-wide proactive and
collaborative approach to security.
What we have discussed in this technical report .
We have provided a comprehensive analysis of the code's components and their
functions in the Spectre attack. The analysis code, which attempts to read sensitive
data through a timing side channel, will be thoroughly described.
The attack will discuss the use of speculative execution, cache behavior, and timing
side channels.
Due to the timing-dependent nature of the exploit, it can be difficult to debug Spectre
attacks. We have described the techniques for debugging that can be used to obtain
PUBLIC / CYHOEDDUS
insight into the attack. The report will discuss the use of conventional debugging
tools such as GDB (GNU Debugger) to investigate the execution of code. To
effectively analyze Spectre attacks, specialized timing analysis tools are required.
Overview of debugging tools
Visual Studio debugging is a vital and powerful component of software development.
Visual Studio includes a plethora of tools and capabilities to help developers detect
and resolve issues in their code. with this section, we will go over the many
components of debugging with Visual Studio in great detail.
Visual Studio contains a complete debugging environment that includes tools such as
breakpoints, watch windows, and call stacks. Breakpoints enable developers to pause
PUBLIC / CYHOEDDUS
code execution at specified lines, which is useful for analyzing variables and
understanding program flow. The watch windows allow developers to monitor the
values of variables and expressions during runtime, which aids in the identification of
problems. Call stacks give a complete history of function calls, which aids in tracing
the execution sequence.
Start Debugging: To begin debugging, developers can select the "Start Debugging"
option, which is frequently represented by a green play button. When you select this
option, Visual Studio compiles the code and starts the application in debug mode.
Debugging can be added to a variety of project types, including online applications,
desktop applications, and even mobile applications.
Setting Breakpoints: In debugging, breakpoints are a developer's best friend. You can
instruct Visual Studio to pause execution when it reaches specific lines of code by
creating breakpoints at those lines. This allows you to examine the status of variables
as well as the program's actions at the time. Conditional breakpoints in Visual Studio
allow you to specify a condition that must be met for the breakpoint to be triggered.
Inspecting Variables: Visual Studio includes several methods for inspecting variable
values. The Autos pane displays variables associated with the current line of code,
Locals displays variables particular to the current line of code, and Watch allows you
to watch individual variables or expressions. These windows provide real-time
information regarding variable values during program execution, which is useful for
finding and resolving problems.
When debugging, it is critical to understand the sequence of function calls. The call
stack window in Visual Studio displays the hierarchy of function calls, making it simple
to track the path your program has followed. This is very useful when dealing with
unexpected behavior or mistakes caused by the execution sequence.
Debugging Tools: In addition to breakpoints and variable analysis, Visual Studio
contains a range of debugging tools. The Immediate window, for example, allows you
to run ad hoc code during debugging sessions, which might be useful for testing
specific behaviors. The Diagnostic Tools window can display real-time performance
PUBLIC / CYHOEDDUS
metrics, memory use, and CPU utilization, which can help you uncover performance
issues.
Stepping through code is one of the advanced debugging techniques supported by
Visual Studio. To control the granularity of debugging, developers can step into, over,
or out of functions. When a certain variable changes, data breakpoints can be defined
to trigger. Just-In-Time debugging allows you to attach the debugger to a running
process, which is useful for troubleshooting production applications.
Exception Handling: Visual Studio provides an advanced exception handling
mechanism that allows you to define breakpoints on exceptions, gracefully handle
exceptions, and even configure how Visual Studio should behave when exceptions
are thrown. This is critical for detecting and correcting runtime issues.
Remote Debugging: Visual Studio provides remote debugging capabilities for
applications deployed to remote servers or devices. Developers can use the debugger
to attach to a remote process and diagnose problems as if they were working locally.
This is especially beneficial for developing web applications, cloud services, and
mobile apps.
The debugging tool supplied in the code enabled us to observe the victim_function's
execution and monitor memory access patterns within the specified program. This
section describes how this tool can be used to obtain insight into the Spectre attack
program's behavior.
PUBLIC / CYHOEDDUS

The printf statements contained within the victim_function and main functions
allow us to monitor memory accesses during program execution

When we invoke victim_function(x) in the main function, the tool will print a
message describing the memory location accessed. This can help us
determine which memory locations in array2 are accessed due to speculative
execution.

Additionally, the function permits us to observe when the victim_function is
utilized. It prints a message before and after the function call in the main
function, allowing us to visualize the order of events.

We can change the value of x when invoking victim_function in order to
examine various memory access scenarios. Changing the value of x will enable
us
to observe memory accesses for various indices, enabling you to
comprehend the program's behavior under various conditions.
By analyzing the printed messages, it is possible to acquire insight into the memory
access patterns used in the Spectre attack. During speculative execution, we can
observe how the application accesses memory locations in array2.
PUBLIC / CYHOEDDUS
Technical Analysis of Spectre POC
Analyse the Spectre POC in this section.
PUBLIC / CYHOEDDUS
You can include analysing individual functions of the Spectre POC, key elements of
the proof of concept, what libraries does the proof of concept import and use, result
of running/executing the proof of concept. You must demonstrate an understanding
of the source code. Please include screenshots in this section to demonstrate that
you have analysed the Spectre POC.
Victim Code (victim_function)
The portion of the Proof of Concept that is susceptible to a Spectre attack is the
victim code.

victim_function: This function tries to access array2 by using an index x as a
parameter, which results in a speculative memory access. This function's
ability to permit an out-of-bounds memory access is crucial, and the attacker
wants to take advantage of this behavior.

array1_size: An integer with a default value of 16 that indicates the size of
array1.

array1: A 160-byte array with values ranging from 1 to 16 initialized
sequentially. Array1 will be used by the attacker to manage the speculative
execution.

array2: The target of the speculative memory access is an array with
dimensions of 256*512 bytes. The attacker wants to extract sensitive data
from this array.

secret: A character pointer that leads to a string that is secret. The attacker
wants to get access to this confidential information by using speculative
execution.

The victim_function cannot be optimized out by the compiler by using the
temp variable, an uint8_t initialized to 0. This variable makes sure that during
optimization, the victim_function is not eliminated.
Analysis Code (main and readMemoryByte):
The Spectre attack is coordinated within the analysis code.

readMemoryByte: This function looks for the memory address that is being
accessed during speculative execution in an effort to take advantage of the
Spectre vulnerability. Key components consist of:

An array called results is used to hold the cache hits during speculative
execution.
a loop that repeatedly launches the attack while clearing the cache lines in
advance of the assault.
Timing measurements combined with speculative memory access to deduce
the location of the accessed memory.


PUBLIC / CYHOEDDUS



Using logic, one can determine the leaked data and select the best and
second-best results.
HIT_CACHE_THRESHOLD: a fixed threshold value that is applied to timingbased cache hit detection. In order to determine whether a cache hit
happened, this value is essential.
principal role: This is where the program starts. It sets up the parameters for
the assault and outputs the findings. Key components consist of:
initializing the malicious_x variable using array1 and the address of the secret.
setting up variables and arrays. allowing the assault to be customized with
command-line options.
Spectre attack is conducted for a predetermined amount of bytes, and the results are
reported.
Utilized Libraries:
Standard C programming functionality is provided by libraries like <stdint.h>,
<stdio.h>, and <stdlib.h>, which are included in the code.
Additionally, it verifies that the header files needed for low-level operations are
included by the compiler being used—Microsoft Visual Studio or another.
<intrin.h> or <x86intrin.h> are included in the code to provide hardware-specific
instructions such as clflush and rdtscp.
Execution and Outcomes:

The primary goal of the PoC is to showcase an assault in the vein of Spectre.
By taking advantage of the victim function's speculative execution, the
attacker hopes to extract confidential information from memory.

Timing measurements taken during code execution, given the right input, will
make the leaked data visible.

The attack's outcome, including whether or not the secret data was extracted,
is printed by the code.
PUBLIC / CYHOEDDUS
Conclusion
This examination concludes with the Spectre Proof of Concept (PoC), demonstrating
modern computer system vulnerabilities. This PoC shows how a bad actor can use
current microprocessors' performance optimization feature speculative execution to
steal sensitive data. Understanding such vulnerabilities is crucial to solving computer
security issues since their effects are far-reaching.
The victim code and analyst code were separated to analyze the Spectre PoC.
Spectre-vulnerable PoC code is the victim code. Using a control array, array1,
victim_function attempts to access array2 out of bounds. The Spectre attack relies on
out-of-bounds access to execute speculatively.
Spectre is orchestrated by analysis code. ReadMemoryByte is crucial to this operation.
It deduces sensitive array2 data from timing and cache access patterns. Flushing
PUBLIC / CYHOEDDUS
cache lines, timing measurements, and result analysis determine the memory location
accessed during speculative execution. This code runs the Spectre attack, showing
how dangerous such vulnerabilities may be.
Spectre relies on the CACHE_HIT_THRESHOLD constant to identify cache hits
depending on timing. This number determines whether a cache hit happened during
speculative execution, which is used to infer data.
The main function activates the PoC, configures attack parameters, and reports
results. It initializes variables, accepts command-line options to personalize the attack,
and runs Spectre for a defined number of bytes. The findings show if the attack
extracted the confidential data.
The investigation revealed Spectre attacks' complexity and sophistication. To attack
speculative execution and run malicious code, they use subtleties in current
microprocessor design. These attacks can leak passwords, encryption keys, and other
sensitive data, causing major damage.
To find and fix Spectre vulnerabilities, code analysis showed the need for specialized
techniques and expertise. Debugging Spectre-style attacks needs microarchitectural
knowledge, performance profiling, and cache monitoring. Understanding the attack's
behavior requires low-level processor control tools like rdtscp and clflush.
Spectre vulnerabilities threaten computer security in real life. Researchers and
specialists constantly create speculative execution vulnerability countermeasures.
Software and hardware solutions include code rearrangement, instruction reordering,
and hardware modifications.
Finally, the Spectre PoC analyzed here is a simplified version of a real-world assault.
Actual attacks can be more complex and targeted, making them harder to identify and
mitigate. Security specialists, hardware manufacturers, and software developers must
work together to protect computer systems from speculative execution attacks.
PUBLIC / CYHOEDDUS
References
Bloch, E. (1959). The engineering design of the Stretch computer. In Papers Presented at the
December 1-3, 1959, Eastern Joint IRE-AIEE-ACM Computer Conference.
Castro, M., Costa, M., Martin, J.-P., Peinado, M., Akritidis, P., Donnelly, A., Barham, P., and
Black, R. (2009). Fast byte-granularity software fault isolation. In Proceedings of the ACM
SIGOPS 22nd symposium on Operating systems principles, 45-58.
Chen, G., Chen, S., Xiao, Y., Zhang, Y., Lin, Z., and Lai, T. H. (2018). SGXPECTRE attacks:
Leaking enclave secrets via speculative execution. arXiv preprint arXiv:1802.09085.
Domnitsen, L., Jaleel, A., Loew, J., Abu-Ghazaleh, N., and Ponomarev, D. (2012). Nonmonopolizable caches: Low-complexity mitigation of cache side-channel attacks. In ACM
Transactions on Architecture and Code Optimization (TACO).
Page, D. (2005). Partitioned cache architecture as a side-channel defense mechanism. In
Crypt. ePrint Arch.
Evtyushkin, D., Ponomarev, D., and Abu-Ghazaleh, N. (2016). Jump over ASLR: Attacking
branch predictors to bypass ASLR. In Proc. IEEE International Symposium on
Microarchitecture (MICRO).
Evtyushkin, D., Riley, R., Abu-Ghazaleh, N., and Ponomarev, D. (2018). BranchScope: A new
side-channel attack on directional branch predictor. In Proceedings of the Twenty-Third
International Conference on Architectural Support for Programming Languages and
Operating Systems, 693-707.
Fog, A. (2016). The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for
assembly programmers and compiler makers. Retrieved from
http://www.agner.org/optimize/microarchitecture.pdf.
George, V., Piazza, T., and Jiang, H. (2011). Technology insight: Intel next-generation
microarchitecture codenamed Ivy Bridge. Retrieved from
http://www.intel.com/idf/library/pdf/sf_2011/SF11_SPCS005_101F.pdf.
Gregg, B. (2018). KPTI/KAISER meltdown initial performance regressions. Retrieved from
http://www.brendangregg.com/blog/2018-02-09/kpti-kaiser-meltdown-performance.html.
Gruss, D., Lipp, M., Schwarz, M., Fellner, R., Maurice, C., and Mangard, S. (2017). KASLR is
dead: long live KASLR. In International Symposium on Engineering Secure Software and
Systems, 161-176.
Gruss, D., Maurice, C., Fogh, A., Lipp, M., and Mangard, S. (2016). Prefetch side-channel
attacks: Bypassing SMAP and Kernel ASLR. In Proceedings of the ACM SIGSAC Conference on
Computer and Communications Security (CCS), 368-379.
PUBLIC / CYHOEDDUS
Horn, J. (2018). Reading privileged memory with a side-channel. Retrieved from
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-withside.html.
Intel. (2018). Intel analysis of speculative execution side channels. Retrieved from
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-ofSpeculative-Execution-Side-Channels.pdf.
Intel. (2018). Retpoline: A branch target injection mitigation. Retrieved from
https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-TargetInjection-Mitigation.pdf.
Intel. (2018). Speculative execution side channel mitigations. Retrieved from
https://software.intel.com/sites/default/files/managed/c5/63/336996-SpeculativeExecution-Side-Channel-Mitigations.pdf.
Intel Corp. (2018). Speculative store bypass bug cve, CVE 2018-3639. Retrieved from
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639.
Jimenez, D. A., and Lin, C. (2001). Dynamic branch prediction with perceptrons. In Proc.
International Symposium on High-Performance Computer Architecture (HPCA), 197-206.
Kayaalp, M., Khasawneh, K. N., Esfeden, H. A., Elwell, J., Abu-Ghazaleh, N., Ponomarev, D.,
and Jaleel, A. (2017). RIC: relaxed inclusion caches for mitigating LLC side-channel attacks. In
Design Automation Conference (DAC).