RISC-V BUSINESS
Jonni Bidwell is back on the conference circuit, eating snacks and mingling with elite hackers like Christina Quast.
TIMING IS KEY “Imagine in 2010 someone coming along and saying all this supposedly secret data was in fact up for grabs by a careful timing attack.”
Christina Quast is an independent security researcher from Germany who speaks and programs in lots of languages. She’s been attending and presenting at all kinds of infosec conferences and various hacker challenges over the course of her studies. Currently she’s based in Nice, France, where she works as an embedded systems engineer and brings her expertise in security to that field.
She’s worked on Embedded Linux kernel drivers, as well as getting U-boot to play nice with embedded hardware. As part of her master’s project and previous studies, she wrote code for the Large Hadron Collider at CERN, in particular a Wireshark plugin for dissecting LHCB particle detection data, and later ported the LHCB RICH particle identification algorithm to the Xeon Phi platform.
Linux Format: So you’ve just gotten your masters degree? Well done!
Christina Quast: Haha, that bio is a little out of date. I got that one a year and a half ago. I started with Computer Science, and there was a placement involved – so we spent some of our studies working for a company. Once I’d done that I felt too young to go out into the real world, so like a good German I continued to study and did my master’s in Electrical Engineering.
I always knew I wanted to work with computers, though there wasn’t any one particular event. But when I watched movies growing up I never wanted to be the action hero, I wanted to be the nerdy one who knew how the system worked and how to manipulate it.
LXF: That is real power. So apart from the talk you’re presenting at this conference, Exploiting Buffer Overflows on RISC-V, you also gave one last year entitled Common Attacks on IOT Devices. I particularly liked the fatalist subtitle for this one – “and why you cannot win”. Can you tell us more about IOT threats?
CQ: The problem is there are so many different attack vectors. I think it’s harder to make a system really secure – actually I think you absolutely cannot do this nowadays. There’s always going to be someone that outsmarts whatever defences you put in place, or someone more creative than you who comes up with some entirely new and novel way of breaking in and attacking your devices.
Before, it was simple buffer overflows and stack overwriting. So we secured our stacks and put various other clever software barriers in place. But nowadays people just attack hardware, and we saw that with Spectre/meltdown last year, and again with Mds/zombieload and friends this year. Before Meltdown, hardly anyone thought about these kinds of attacks.
LXF: It was a crazy time, we all came back from holidays and it seemed like the world had caught fire. It’s quite strange, even with Heartbleed, it was just a question of applying a patch and hoping you hadn’t been unlucky enough to get caught before doing so.
With the hardware attacks, we can mitigate in software or through a BIOS update, we can disable Hyperthreading or SMT, but to actually fix the problem we need new hardware. And the icing on the cake is that CPUS from 20 years ago are vulnerable.
CQ: Yes, imagine in 2010 someone coming along and saying all this supposedly secret data was in fact up for grabs by a careful timing attack. But this is the current trend, attacking the hardware directly.
Software attacks were in a sense becoming too hard, so people started examining other directions. Currently that’s hardware, and maybe when chips are architected better people will start looking at exploiting crypto algorithms or some other, hitherto unthought of, mindblowing thing. The future of attacks is most probably hardware and logic bugs.
LXF: Let’s talk about some of these hardware attacks.
CQ: We had a good course on that topic at my university, I guess it was about five years ago. Researchers started decapping, opening up chips and photographing them layer by layer – sort of the inverse of how chips are fabricated [by photolithography], each layer being interconnected with the others. Once you have good-enough photos of each layer, then you can reverse engineer the schematics behind the chip. Maybe then you can find a hardware bug, or figure out how the crypto engine of that particular chip works.
LXF: Oh that’s cool. It reminds me of the only bit of Javascript I’ll ever speak positively about. The Visual 6502 project (see http://visual6502.org), where they took high-resolution photos of the 6502 (the CPU found in the BBC Micro, which would pave the way for the 6510 found in the C64). Using this they were able to construct a transistor-level simulation of the chip, faithfully recreating all the original hardware bugs.
Anyway, emulating 12,000 transistors is complicated, or it was in 2009, and I
remember a presentation where one of the hackers joked, “This is pretty slow, how can we make it slower?” and that’s where the idea to implement it all in Javascript came from.
I’m guessing a JS simulation of a chip might not be the best learning aid, but as an amateur it’s hard to imagine what kind of tools would help with this.
CQ: One thing that I find really fascinating is that it’s actually easier than ever to learn about these kinds of attacks because our tools have improved so much. It’s not just the sophistication of the attacks that’s improving, or that of the defences even, but the tooling itself is really powerful now. For example there’s this tool called the
Chipwhisperer (https://newae.com/ tools/chipwhisperer). It’s a combination of hardware and software that helps you do glitching attacks, which requires very precise timing.
LXF: Can you give a layperson’s overview of what’s involved in a timing attack? I know Spectre and Meltdown are examples, but those are complicated. Oh and I have a joke, but it’s not of the usual joke format, so I need you to ask, “What’s the most critical part of a good joke?” CQ: Uh, okay, what’s the most crit…
LXF: Timing!
CQ: That wasn’t very funny. I mean points for trying, but how about I just tell you about timing attacks and you just don’t tell anymore jokes? Good. What you want to do is identify a critical branch of code, maybe where a password is being checked. You look for a jump (JMP) instruction that corresponds to the ‘if’ statement that checks the given password.
If you can glitch the CPU, for example by reducing the voltage abruptly, at exactly the moment this instruction is being executed, there’s a chance the branch will pass instead of jumping to the ‘wrong password’ routine. So the program will continue down the code path and act exactly as if the correct password was inputted, giving you access to the system.
These kind of things can’t really be done in software, since we’re talking microsecond precision here. You can’t get that by hacking up Python scripts. Well, statistically speaking if you do it often enough I guess you’ll eventually get lucky. Even with hardware you need to do it a few times, because timing is critical.
Defending a system is in a sense harder than attacking, because you have to defend against this happening hundreds of times, for however many critical code paths there is. An attacker needs to get lucky only once.
LXF: A while ago [LXF194] I reviewed something quite interesting, a USB oscilloscope called the Bitscope Micro. But unlike conventional oscilloscopes that are big and expensive, this was a cheap and cheerful device that came with neat software and all the wires you need to probe all kinds of digital and analogue signals. I wanted to play with it more but didn’t get the time. It’s probably still kicking around the office under a pile of magazines. Do you think these kind of things can help people get into hardware hacking?
CQ: I mean, it depends what you want to do, but there’s a reason why most oscilloscopes are those clunky things and cost thousands of euros. If you just want to play around, then the cheap ones are great, but if you’re working in the gigahertz range and need to get the signal right, you need to invest pretty heavily.
But more generally Arduino and Raspberry Pi do make electronics much more accessible. I once had a roommate who was in product design, and one day I found her just casually hacking away at the Arduino interface, making LEDS blink for a wearable project.
LXF: We have an electronics feature coming up (you’re supposed to be writing it already – Ed) so hopefully I get to play with such things again soon. My ultrasonic radar display still needs some work. But the hardware is cheap and the software is free, unlike a copy of IDA Pro (a popular disassembler and debugger). What about open source hacking and fuzzing tools – do they compete with commercial offerings?
CQ: Lots of people still use IDA Pro, it was for a long time the de facto standard. There are alternatives, like Radare2 (https://radare.org, Open Source) and
Hopper on Linux and Mac, which is not open source, but still nice.
What’s quite interesting this year is the NSA [US National Security Agency] open sourced their Ghidra reverseengineering tool, and lots of people have been migrating to it. I’m not sure how I feel about that, whether that software can be trusted. But it’s definitely good that there’s a counterweight against IDA Pro, because for so long it was the de facto monopole.
People were asking for features, and developers weren’t implementing them because they didn’t have to and didn’t want to. With open source tools – even if they’re from the NSA – people can now work on those features themselves, so it’s a nice change.
LXF: Later on you’re going to be talking about RISC-V. We hear a lot of news about RISC-V but haven’t really done anything with it. Maybe if someone were to send us one of those Hifive Unleashed boards we would do more. To be honest, I don’t understand much about what, besides its openness, makes the architecture special. Can you help me? CQ: That’s actually pretty reasonable. All the previous conferences I’ve been to have had people talking about how they’ve added some functionality to RISC-V, but no one’s explained what the architecture itself looks like.
There’s been a need for open hardware for a long time, because currently people don’t really know what the inside of a CPU looks like. All you see is an interface to a piece of hardware, but you don’t really know what’s behind it. Other chips require you to pay license fees, so having something that’s open, where people can add their own IP cores to extend functionality, where they have documentation they can base their programs on, is a big step forward.
Basically universities, startups or individuals who want to play with CPUS now have a starting point. That starting point didn’t really exist, at least not with the level of trust and stability RISC-V provides, until now. The need has been present for a long time, but it’s taken a while for the right people with the right resources to address it.
LXF: What aspects of RISC-V are you going to be talking about later?
CQ: I spent a lot of time figuring out for myself what the instructions looked like and how to program with them. Then a colleague gave me a RISC-V board, and since I’m interested in security I thought I’d combine studying the architecture with exploiting it. I wanted to see how simple buffer overflows, writing shellcode and such like compared to Arm or x86. I’m basically doing My first Buffer Overflow [talk] for RISC-V.
LXF: That sounds cool (it was, I’d recommend everyone at least look at the slides at https://static.sched. com/hosted_files/osseu19/c1/ Oss_europe_2019_riscv_talk.pdf). So what are the differences between these different architectures?
CQ: It turns out that RISC-V and Arm are really similar actually, so that many techniques for exploiting Arm binaries will also work for RISC-V, even though they might differ in details. The former was very much inspired by the latter and similar RISC architectures, like MIPS.
RISC-V and x86 are very different
– they were designed with different philosophies. For example, many instructions can directly access memory on x86, but on RISC-V and Arm you have to load a value from memory into a register before you can operate on it, do additions or whatever, then you have to store it back to memory again. RISC-V and Arm both have 32 general-purpose registers, whereas x86 has only 16.
The instruction length on x86 is variable too, which makes it a little complicated to decode. Arm and RISC-V both have 4-byte instructions, or 2 bytes in special modes (Thumb mode and RVC).
LXF: Okay, so here comes the point where I reveal the level of my ignorance in this area. My understanding of buffer overflows, and actually all these kinds of attack, goes as far as this: you have a program, and that program is expecting some kind of input. Instead of giving that program, or function I guess, input that it can deal with, you give it something entirely the wrong shape, which causes said program to break, possibly in a way that escalates privileges, reveals secrets or something else undesirable. Is this a reasonable picture?
CQ: That’s not wrong. There’s a whole theory in computer security about so-called weird machines, which is all about crafting those kind of inputs outside of the expected input range. In my talk, in order to simplify things, I disabled stack protection and a couple of other things to make exploitation easier. But you can find programs nowadays that don’t have what are considered pretty standard barriers in place to stop these kinds of attacks.
It is getting harder though. There are some defensive measures in place, for example usually the stack is not executable, or we have stack canaries so you’d notice if something overwrote, for example the return address on the stack.
A new trend, which I haven’t looked into much, is kernel exploitation. It started to become more popular in security CTFS (capture-the-flag contests) probably a couple of years ago, and since then more and more of these challenges have been coming up. Linux is becoming increasingly relevant everywhere, so from a security point of view attacking (and defending) the kernel is becoming popular. Before, things were much more Windows-centric.
LXF: Yes, it’s good that Linux is relevant enough that people organise these conferences, fly me to them, and keep me in snacks for the duration. I don’t even understand most of what people are talking about here. And you know what else I don’t understand, but I hear a lot of from following infosec people on Twitter? Return-oriented programming (ROP). I gather it can circumvent lots of these protections that you mentioned earlier. Can you explain it to me?
CQ: It’s been around for a while, since 2007 I think, but it’s quite a fascinating technique. If you can’t put code you want executed into a buffer on the stack or heap, or the stack or heap is marked as not executable, you will instead have to find existing code snippets in the program you are attacking and make use of them.
On Linux, your program will be using libc, which provides all the basic functions. There’s a special class of ROP called ret2libc. If you know which version of libc is being used, you therefore know the offsets where the assembler instruction is located, and then you can search around in the libc for code snippets that take a value from the stack (which you control), put it into a register, then do a return. Then you put the addresses of those code snippets
THE OPENNESS OF RISC-V “Universities, startups or individuals who want to play with CPUS now have a starting point.”
on the stack as the return address from your function.
By chaining these so-called gadgets together you can write arbitrary programs. If you’re lucky and find a magic gadget, then that’s all you need to start a shell. There are tools available that can help you find those gadgets.
LXF: Well, I sense the end of the page coming up, so let’s finish up with your thoughts on the future of RISC-V.
CQ: It’s hard to say for sure, but in ten years maybe that’ll be what’s powering your mobile phone. It might be in servers too, but I think it’s more targeted towards embedded systems or IOT devices. Hardware is already available, so you no longer have to program an FPGA to simulate RISC-V. It might displace and will at least threaten the dominance of the present players.