Stupid Unix Tricks - Escaping a Restricted Shell

Welcome to the first post of what may become a series - Stupid Unix Tricks.

I love stupid Unix tricks.  Even better if they can be used for something security-related.  This remains one of my favorite security advisories ever.  So it shouldn't be a surprise that I really enjoy security assessments that involve breaking out of a restricted shell.  They're a lot of fun, and restricted shells are extremely hard to get right in terms of security and prevention.  (I feel the same about kiosk escapes too, but that's a topic for another time.)

Years ago, I was doing a security assessment on a product.  The product details are unimportant, but it had a web interface and limited cli "administrator" access through ssh.  The server was racked in a remote datacenter -- not something that we could get easy physical access to -- so booting to single-user mode or other ways of examining the raw filesystem were out.  

In this instance, the restricted shell was used as guardrails on a controlled cli environment for customers.  I'm not sure if this was done to protect accidental customer error or to obscure the inner workings of the product.  The vendor did not provide root cli access to customers, so we were limited to a non-root service account.  The cli dropped the limited user into rbash and only had access to a handful of tools and scripts.  (No vi :!/bin/sh or tools with easy shell escapes, though.)  But some of scripts were setuid root -- which mean there was probably a way to exploit the environment.  After some testing, I was able to generate error messages that showed me the full names and paths of the commands I was running, and I got an understanding of the underlying filesystem.  

Poking around rbash some more, I realized I was able to read files by setting my HISTFILE environment variable to the target file, and then reviewing my history.  Combined with a knowledge of the filesystem, I could then grab the source for all of the setuid shell scripts. 

A quick code review later, and I had a command injection bug.  From there, it was easy work to create a uid 0 user with a standard shell, and get full access to the system.

I never did take the time to figure out if the HISTFILE/rbash technique was publicly known, but some quick searching today reveals at least some more recent discussions.