Session 05: OS and Application Security

Security: Security is the design of systems that achieve some property against an active adversary. The process consists of defining a system, defining security goals, and proving that the system provides these goals.

Assignment(s)

chroot Demo

• using Busybox and chroot, modify the apparent root to chroot_jail, preventing another user from accessing a confidential text file.

Deliverables & Submission Requirements

• Submit a brief lab report with answers to the following questions:

  • When you ran cd ../../.. inside the jail and checked your location, why couldn’t you exit? How does the kernel manipulate path resolution for a chroot-ed process?

  • What happens if you try to run commands like nano, python3, or grep inside your jail? Explain why they fail, even if they are installed on your host OS.

Deep-Dive Discussion — The Privilege Escape Paradox

• Add all of /bin and /lib; your user should be able to access a compiler and other tooling.

The Double-Chroot Escape Vulnerability

chroot Demo

My first question was “what is chroot?” After some light research, I learned that chroot, short for change root, is a command and system call in Unix and Linux operating systems that changes the apparent root directory for a running process. In other words, when the root directory for a program is changed, the program cannot access or see files outside of that designated directory tree; this action effectively makes the computer believe that the specified folder is the computer’s base directory.

Step 1: Create the Host Secret Flag & Set Up a Shell

In my VM terminal, I first built a “sensitive” file, named host_secret.txt, to simulate confidential information:

sudo echo "FLAG{CHROOT_IS_NOT_A_SECURE_SANDBOX_1206}"  > /host_secret.txt

However, to my surprise, I got this permissiondenied response:

After searching up why this happened, I learned that it is because this command was executed by my current shell, which does not have root privileges. To fix this, I ran it in a sudo shell:

sudo sh -c 'echo "FLAG{CHROOT_IS_NOT_A_SECURE_SANDBOX_1206}" > /host_secret.txt'

which worked fine.

According to the homework page, to avoid “dependency hell” and keep the focus on security concepts, this exercise uses the sandbox BusyBox Static. Sandboxes in cybersecurity can be particularly useful, as they act as isolated, virtual testing grounds where we can safely detonate, observe, and analyze suspicious files, code, or URLs. BusyBox specifically combines tiny versions of many common UNIX utilities into a single, statically compiled binary that does not require external library paths. To install BusyBox Static, I ran

sudo apt update && sudo apt install -y busybox-static

Then, I created a clean directory structure for my ‘jail’ (i.e.):

mkdir -p ~/chroot_jail/bin

This is the directory we will use the chroot command on and trick the computer. I copied the shell (defined as the program that takes commands from your keyboard and gives them to the operating system or OS to perform) I’m going to run into my jail. This step copies a special program into the earlier sandbox folder structure to act as the jail’s internal command-line interface:

cp /bin/busybox-static ~/chroot_jail/bin/sh

However, this also returned an error that there was no file or directory. Odd. I confirmed the existence of busybox static by running ls /bin, to which I found that the actual directory name is busybox, not busybox-static. Modifying the command, I ran this:

cp /bin/busybox ~/chroot_jail/bin/sh

which worked!

Step 2: Activate the Jail!

Using the chroot command, I executed my new shell; to break down how this works, Busybox recognizes the shell request and automatically boots up its internal ash shell interface.

sudo chroot ~/chroot_jail /bin/sh

Here is what the new CLI looked like:

The kernel now believes that ~/chroot_jail is the absolute root (/) of the entire machine.

Step 3: Test the Containment

To test the containment mechanism (aka whether the jail upholds its purpose of preventing a user from accessing confidential files), I executed the following command inside my jailed environment:

ls -la /

This command is used to display all the files and directories in the root. I could tell that this containment was successful, as the results merely displayed the sandbox folder (~/chroot_jail) as if it were the entire system root:

I also attempted a directory traversal:

cd ../../..
ls -la

Here, the cd ../../.. is an extended version of cd .., used to move up exactly three levels in the folder hierarchy in a single step. The idea here is that, no matter how much the user attempts to move up, they cannot access external (or in this case, confidential) files, remaining locked inside the bin folder tree:

Lastly, I checked whehter I could access the confidential file from the start, host_secret.txt:

 cat /host_secret.txt

which returned

indicating that the file is indeed protected from the snooping user!

To exit the sandbox, I ran exit.

Deliverables and Submission Requirements

When you ran cd ../../.. inside the jail and checked your location, why couldn’t you exit? How does the kernel manipulate path resolution for a chroot-ed process? When I ran cd ../../.. inside the jail and checked my locaation, I couldn’t exit because chroot had effectively convinced the kernel that the /bin was the base directory, meaning that it wouldn’t have a parent. For a normal process, root points to the true system root (/). However, because I ran the chroot system call, the kernel updates that specific process’s root pointer to point to the sandbox folder ~/chroot_jail. For a chroot-ed process, the kernel manipulates wthe path resolution in the following way: the command requests /bin/sh, the kernel receives the request, and it uses its Virtual File System to do a precise path lookup. For a chroot-ed process, it directly looks from its assigned root directory, which in this case is chroot_jail.

What happens if you try to run commands like nano, python3, or grep inside your jail? Explain why they fail, even if they are installed on your host OS. Although these commands work perfectlyt fine on the host OS, they fail inside the jail due to missing executable files and missing shared software libraries. When the chroot_jail directory is created, it is essentially empty besides any and all copied files an individual manually copies in.

Deep-Dive Discussion — The Privilege Escape Paradox

For this exercise, the homework page suggests using mount, which shares the host’s existing compiler and system directories directly into the jail in real-time without duplicating files on your disk. This is a far more efficient method than manually and individually copying the directories over.

To begin, I created the target ‘mounting points’ and manually copied over the , based on the assignments’ requirements (/bin and /lib):

sudo mkdir -p /chroot_jail/lib
sudo mkdir -p /chroot_jail/bin

To mount /lib and /bin (executables), I ran

sudo mount --bind /lib /chroot_jail/lib
sudo mount --bind /bin /chroot_jail/bin

I copied over the shell again because my initial attempt to open the shell resulted in a “No such file or directory” error:

cp /bin/busybox ~/chroot_jail/bin/sh

Note that using bind mounts grants the chroot environment direct access to the host files.

Then, I opened the shell:

sudo chroot ~/chroot_jail /bin/sh

Here is where the problem lies: chroot merely modifies path resolution but does not isolate processes, namespaces, or administrative permissions. So, when I run cat /host_secret.txt again, I get

Now various other commands are available to your sandboxed user, consider the below issue. You find out that your user was able to gain access to your secret file! How? Because the entire /bin directory is mounted to chroot_jail, the sandboxed user now has access to everything in /bin that was originally just on the host’s root. This is the prime example of how chroot doesn’t protect the file itself; rather, it only can hide the path to it, limiting visibility to what’s directly in the jail.

Demonstrate at least one method of escaping the sandbox on your student VM, and demonstrate in your writeup that this works.

The Double-Chroot Escape Vulnerability

Double-Chroot Escape If an untrusted process inside a chroot sandbox manages to maintain or upgrade its privileges to root (UID 0), it can easily bypass the filesystem barrier using a well-known exploit technique colloquially called a Double-Chroot Escape.

Here are the steps:

1. The attacker is running inside the jail, but retains full system admin capability (root).

2. The attacker calls open(“.”, …) to grab a direct hardware handle (file descriptor) pointing to the jail’s current root directory.

3. The attacker creates a temporary subfolder inside the jail (e.g., /breakout) and issues a new chroot command targeting that deeper folder.

4. The kernel updates the process’s internal root pointer to point to /breakout. Crucially, the old root folder handle from step 2 is now technically outside the process’s new active root boundary.

5. Because the attacker has a raw file descriptor to a directory outside its current root, they can call fchdir() onto that handle, and execute cd .. repeatedly. The kernel can no longer stop the traversal because the boundary calculation breaks down when navigating upwards from an external file handle.

6. The attacker arrives at the true host root, issues one final chroot(“.”), and breaks completely into the host filesystem with full administrative permissions intact.