Detecting vulnerabilities in software is a critical challenge in the development and deployment of applications. One of the most known and dangerous vulnerabilities is stack-based buffer overflows, which may allow potential attackers to execute malicious code. In this paper we consider the use of modern machine learning models, specifically recurrent neural networks, to detect stack-based buffer overflow vulnerabilities in the assembly code of a program. Since assembly code is a generic and common representation, focusing on this language allows us to potentially consider programs written in several different programming languages. Moreover, we subscribe to the hypothesis that code may be treated as natural language, and thus we process assembly code using standard architectures commonly employed in natural language processing. We perform a set of experiments aimed at confirming the validity of the natural language hypothesis and the feasibility of using recurrent neural networks for detecting vulnerabilities. Our results show that our architecture is able to capture subtle stack-based buffer overflow vulnerabilities that strongly depend on the context, thus suggesting that this approach may be extended to real-world setting, as well as to other forms of vulnerability detection.
We present a preliminary study of buffer overflow vulnerabilities in CUDA software running on GPUs. We show how an attacker can overrun a buffer to corrupt sensitive data or steer the execution flow by overwriting function pointers, e.g., manipulating the virtual table of a C++ object. In view of a potential mass market diffusion of GPU accelerated software this may be a major concern.
We present a novel approach to mitigate buffer overflow attack using Variable Record Table (VRT). Dedicated memory space is used to automatically record base and bound information of variables extracted during runtime. We instrument frame pointer and function(s) related registers to decode variable memory space in stack and heap. We have modified Simplescalar/PISA simulator to extract variables space of six (6) benchmark suites from MiBench. We have tested 290 small C programs (MIT corpus suite) having 22 different buffer overflow vulnerabilities in stack and heap. Experimental results show th…
A software vulnerability could be exploited without any visible symptoms. When no source code is available, although such silent program executions could cause very serious damage, the general problem of analyzing silent yet harmful executions is still an open problem. In this work, we propose a graph neural network (GNN) assisted data flow analysis method for spotting silent buffer overflows in execution traces. The new method combines a novel graph structure (denoted DFG+) beyond data-flow graphs, a tool to extract {\tt DFG+} from execution traces, and a modified Relational Graph Convolution…
In languages like C, buffer overflows are widespread. A common mitigation technique is to use tools that detect them during execution and abort the program to prevent the leakage of data or the diversion of control flow. However, for server applications, it would be desirable to prevent such errors while maintaining availability of the system. To this end, we present an approach to handle buffer overflows without aborting the program. This approach involves implementing a continuation logic in library functions based on an introspection function that allows querying the size of a buffer. We de…
Annex K of C11, bounds-checking interfaces, recently introduced a set of alternative functions to mitigate buffer overflows, primarily those caused by string/memory functions. However, poor compatibility limits their adoption. Failure oblivious computing can eliminate the possibility that an attacker can exploit memory errors to corrupt the address space and significantly increase the availability of systems. In this paper, we present S3Library (Saturation-Memory-Access Safer String Library), which is compatible with the standard C library in terms of function signature. Our technique automati…
Practical attacks that exploit speculative execution can leak confidential information via microarchitectural side channels. The recently-demonstrated Spectre attacks leverage speculative loads which circumvent access checks to read memory-resident secrets, transmitting them to an attacker using cache timing or other covert communication channels. We introduce Spectre1.1, a new Spectre-v1 variant that leverages speculative stores to create speculative buffer overflows. Much like classic buffer overflows, speculative out-of-bounds stores can modify data and code pointers. Data-value attacks can…
A stack overflow occurs when a program or process tries to store more data in a buffer (or stack) than it was intended to hold. If the affected program is running with special privileges or accepts data from untrusted network hosts (e.g. a web-server), then it is a potential security vulnerability. Overflowing a stack, an attacker can corrupt the stack in such a way as to inject executable code into the running program and take control of the process. This is one of the easiest and more reliable methods for attackers to gain unauthorized access to a computer. In this paper, we show that how st…
Online programming discussion platforms such as Stack Overflow serve as a rich source of information for software developers. Available information include vibrant discussions and oftentimes ready-to-use code snippets. Anecdotes report that software developers copy and paste code snippets from those information sources for convenience reasons. Such behavior results in a constant flow of community-provided code snippets into production software. To date, the impact of this behaviour on code security is unknown. We answer this highly important question by quantifying the proliferation of securit…
Since buffer overflow has long been a frequently occurring, high-risk vulnerability, various methods have been developed to support spatial memory safety and prevent buffer overflow. However, every proposed method, although effective in part, has its limitations. Due to expensive bound-checking or large memory in taking for metadata, the software-only support for spatial memory safety inherently entails runtime overhead. Contrastingly, hardware-assisted methods are not available without specific hardware assistants. To mitigate such limitations, Herein we propose L4 Pointer, which is a 128-bit…
Previous studies have shown that developers regularly seek advice on online forums to resolve their cryptography issues. We investigated whether users who are active in cryptography discussions also use cryptography in practice. We collected the top 1% of responders who have participated in crypto discussions on Stack Overflow, and we manually analyzed their crypto contributions to open source projects on GitHub. We could identify 319 GitHub profiles that belonged to such crypto responders and found that 189 of them used cryptography in their projects. Further investigation revealed that the m…
Stack Overflow (SO) is a popular platform among developers seeking advice on various software-related topics, including privacy and security. As for many knowledge-sharing websites, the value of SO depends largely on users' engagement, namely their willingness to answer, comment or post technical questions. Still, many of these questions (including cybersecurity-related ones) remain unanswered, putting the site's relevance and reputation into question. Hence, it is important to understand users' participation in privacy and security discussions to promote engagement and foster the exchange of …
WebAssembly is increasingly used as the compilation target for cross-platform applications. In this paper, we investigate whether one can rely on the security measures enforced by existing C compilers when compiling C programs to WebAssembly. We compiled 4,469 C programs with known buffer overflow vulnerabilities to x86 code and to WebAssembly, and observed the outcome of the execution of the generated code to differ for 1,088 programs. Through manual inspection, we identified that the root cause for these is the lack of security measures such as stack canaries in the generated WebAssembly: wh…
