The goal of this challenge is to find unsafe uses of alloca
in the GNU C Library (glibc
). alloca
is used to allocate a buffer on the stack. It is usually implemented by simply subtracting the size
parameter from the stack pointer and returning the new value of the stack pointer. This means that it has two important benefits:
- The memory allocated by
alloca
is automatically freed when the current function returns. - It is extremely fast.
But alloca
can also be unsafe because it does not check whether there is enough stack space left for the buffer. If the requested buffer size is too big, then alloca
might return an invalid pointer. This can cause the application to crash with a SIGSEGV
when it attempts to read or write the buffer. Therefore alloca
is only intended to be used to allocate small buffers. It is the programmer's responsibility to check that the size isn't too big.
The GNU C Library contains hundreds of calls to alloca
. In this challenge, you will use Semmle QL to find those calls. Of course many of those calls are safe, so the main goal of the challenge is to refine your query to reduce the number of false positives. If you follow the challenge all the way to the end then you might even find a bug in glibc that is reproducible from a standard command-line application.
The quickest way to get started with QL is to use LGTM's query console. However, if you prefer, you can also install QL and write your queries offline. Instructions for installing QL are included at the end of this document.
If you are attending FCRC 2019, then please visit us at our booth (Table 14, North Building - 200 Level). We can give you a quick QL demo to get you started and, if you are interested, we can also help you with the offline setup instructions. If you solve (at least) Step 3 below, visit our booth by Wednesday (26 June) afternoon and show us your solution for a chance to win a prize!
If you get stuck, try searching our documentation and blog posts for help and ideas. Below are a few links to help you get started:
- Writing a basic QL query for C/C++
- help.semmle.com
- Using QL to find kernel stack buffer overflows in Qualcomm MSM-4.4
- Kernel RCE caused by buffer overflows in macOS NFS client
The challenge is split into several steps, each of which contains multiple questions. But you do not need to submit separate answers to each individual question. One query per step is sufficient.
- Question 00:
alloca
is a macro. Find the definition of this macro and the name of the function that it expands to.
- Question 10: Find all the calls to
alloca
(using the function name that you found in step 0). - Question 11: Use the
upperBound
andlowerBound
predicates from the SimpleRangeAnalysis library to filter out results which are safe because the allocation size is small. You can classify the allocation size as small if it is less than 65536. But don't forget that negative sizes are very dangerous.
The correct way to use alloca
in glibc
is to first check that the allocation is safe by calling __libc_use_alloca
. You can see a good example of this at getopt.c:252. That code uses __libc_use_alloca
to check if it is safe to use alloca
. If not, it uses malloc
instead. In this step, you will identify calls to alloca
that are safe because they are guarded by a call to __libc_use_alloca
.
- Question 20: Find all calls to
__libc_use_alloca
. - Question 21: Find all guard conditions where the condition is a call to
__libc_use_alloca
. - Question 22: Sometimes the result of
__libc_use_alloca
is assigned to a variable, which is then used as the guard condition. For example, this happens at setsourcefilter.c:38-41. Enhance your query, using local dataflow, so that it also finds this guard condition. - Question 23: Sometimes the call to
__libc_use_alloca
is wrapped in a call to__builtin_expect
. For example, this happens at setenv.c:185. Enhance your query so that it also finds this guard condition. - Question 24: Sometimes the result of
__libc_use_alloca
is negated with the!
operator. For example, this happens at getaddrinfo.c:2291-2293. Enhance your query so that it can also handle negations. - Question 25: Find calls to
alloca
that are safe because they are guarded by a call to__libc_use_alloca
.
- Question 30: use your answer from step 2 to enhance your query from step 1 by filtering out calls to
alloca
that are safe because they are guarded by a call to__libc_use_alloca
.
In this step, you'll use a taint tracking query to find an unsafe call to alloca
where the allocation size is controlled by a value read from a file.
- Question 40: Find calls to
fopen
. (Be aware thatfopen
is another macro.) - Question 41: Write a taint tracking query. The source should be a call to
fopen
and the sink should be the size argument of an unsafe call toalloca
. To help you get started, here is the boilerplate for the query:
/**
* @name 41_fopen_to_alloca_taint
* @description Track taint from fopen to alloca.
* @kind path-problem
* @problem.severity warning
*/
import cpp
import semmle.code.cpp.rangeanalysis.SimpleRangeAnalysis
import semmle.code.cpp.dataflow.TaintTracking
import semmle.code.cpp.models.interfaces.DataFlow
import semmle.code.cpp.controlflow.Guards
import DataFlow::PathGraph
// Track taint through `__strnlen`.
class StrlenFunction extends DataFlowFunction {
StrlenFunction() { this.getName().matches("%str%len%") }
override predicate hasDataFlow(FunctionInput i, FunctionOutput o) {
i.isInParameter(0) and o.isOutReturnValue()
}
}
// Track taint through `__getdelim`.
class GetDelimFunction extends DataFlowFunction {
GetDelimFunction() { this.getName().matches("%get%delim%") }
override predicate hasDataFlow(FunctionInput i, FunctionOutput o) {
i.isInParameter(3) and o.isOutParameterPointer(0)
}
}
class Config extends TaintTracking::Configuration {
Config() { this = "fopen_to_alloca_taint" }
override predicate isSource(DataFlow::Node source) {
// TODO
}
override predicate isSink(DataFlow::Node sink) {
// TODO
}
}
from Config cfg, DataFlow::PathNode source, DataFlow::PathNode sink
where cfg.hasFlowPath(source, sink)
select sink, source, sink, "fopen flows to alloca"
- Question 50: The GNU C Library includes several command-line applications. (It contains 24
main
functions.) Demonstrate that the bug is real by showing that you can trigger a SIGSEGV in one of these command-line applications.
We hope you enjoyed this challenge! If you are interested in continuing to use QL for security research, then we recommend installing QL on your own computer. This will enable you to run queries offline. We have also provided these offline instructions for posterity, because the query results on LGTM will change over time as the source code evolves. But the instructions below use a snapshot corresponding to revision 3332218
, which is the revision for which we designed this challenge.
To run QL queries offline, follow these steps:
- Install the Eclipse IDE.
- Download QL for Eclipse. Installation instructions can be found here.
- Download this snapshot, which corresponds to revision
3332218
. - Import the
glibc
snapshot.
You can download other snapshots for offline use from LGTM. For example, you can download a snapshot for the latest revision of glibc here. Every project on LGTM has a download link for downloading the latest snapshot.