Bader AlBassam: "I’m surrounded by some of the brightest people in the field."
Bader AlBassam, winner of the Graduate Student Board's TA of the Year Award, 2020 is a PhD student whose research is in the area of software and systems security. "We strive to ensure that our impact is transparent."
Area of study if not CS and what degrees are you pursuing?
I’m pursuing a PhD in CS.
What is your favorite thing about your Purdue experience?
Definitely the student body. I’m surrounded by some of the brightest people in the field and there is a wealth of knowledge in each discussion I have with my peers here. Usually over a cup of coffee at the local coffee shops where we can have endless discussions.
What has been your favorite accomplishment at Purdue?
The b01lers CTF team which I have led for a few years. Having now seen the team I led grow to be one of the top ranked competitive security teams globally is a testament to the type of students that we have here at Purdue.
If you are not familiar with CTFs, they are global security-oriented competitions where professionals, academics, and hobbyists compete against each other by solving security-oriented challenges: programs that need to be exploited, reverse engineered, or tricked into giving up a flag. Of course, I have to place an obligatory plug to https://b01lers.net for people who want to join us!
What topics do you study in your research/coursework?
My research is in the area of software and systems security. My focus is on vulnerability discovery and the analysis of the exploitability of software through various binary analysis techniques. I hope that my research will aid software developers in automatically discovering potential issues in their code before they get released. My research is also intended to improve the development lifecycle by pointing out potential vulnerabilities before bad actors exploit them in the wild.
What do you wish others knew about your research or computer science and how it impacts their lives?
A system is secure when “nothing bad can happen”. Unfortunately, software often has bugs that could allow an attacker to steal information or take over the computer. Our goal as security researchers is to protect the user’s data and their systems against such attacks. Most users are not security experts, it is therefore important that our techniques work “out of the box”, i.e., don’t require sophisticated deep security knowledge. We strive to ensure that our impact is transparent. It's a challenge that we take upon ourselves to make sure that your computer, and everything you run on it, is safe from attackers while keeping your user experience as smooth as possible. After all, nobody would want to run a defense that makes a computer slower as that would annoy anyone, myself included.
Block Oriented Programming: Automating Data-Only Attacks
Kyriakos K. Ispoglou, Bader AlBassam, Trent Jaeger, Mathias Payer
With the widespread deployment of Control-Flow Integrity (CFI), control-flow hijacking attacks, and consequently code reuse attacks, are significantly more difficult. CFI limits control flow to well-known locations, severely restricting arbitrary code execution. Assessing the remaining attack surface of an application under advanced control-flow hijack defenses such as CFI and shadow stacks remains an open problem. We introduce BOPC, a mechanism to automatically assess whether an attacker can execute arbitrary code on a binary hardened with CFI/shadow stack defenses. BOPC computes exploits for a target program from payload specifications written in a Turing-complete, high-level language called SPL that abstracts away architecture and program-specific details. SPL payloads are compiled into a program trace that executes the desired behavior on top of the target binary. The input for BOPC is an SPL payload, a starting point (e.g., from a fuzzer crash) and an arbitrary memory write primitive that allows application state corruption. To map SPL payloads to a program trace, BOPC introduces Block Oriented Programming (BOP), a new code reuse technique that utilizes entire basic blocks as gadgets along valid execution paths in the program, i.e., without violating CFI or shadow stack policies. We find that the problem of mapping payloads to program traces is NP-hard, so BOPC first reduces the search space by pruning infeasible paths and then uses heuristics to guide the search to probable paths. BOPC encodes the BOP payload as a set of memory writes. We execute 13 SPL payloads applied to 10 popular applications. BOPC successfully finds payloads and complex execution traces -- which would likely not have been found through manual analysis -- while following the target's Control-Flow Graph under an ideal CFI policy in 81% of the cases.