Embedded Randomized Security

Despite its age, Smashing the Stack for Fun and Profit is still one of the best security papers ever written. Penned in 1996 by Elias Levy under the pseudonym of AlephOne, the narrative explains perfectly how software can be written to maliciously exploit memory by overflowing buffers. To this day, I make graduate students read this report, as I’ve never seen a better explanation of any cyber attack. If you haven’t read it, then please do so. Now.

Amazingly, memory manipulation remains an overwhelmingly successful strategy for hackers. Efforts to reduce this risk, including educational initiatives for programmers, have helped somewhat – but malicious actors continue to find success in this area. Even standards such as Address Space Layout Randomization (ASLR) from 2001 have not sufficiently reduced this risk. Hackers seem to easily sidestep ASLR in memory-based attacks.

I spent time last week with the founders of McLean, Virginia-based RunSafe Security. Joe Saunders, serves as CEO of the company, and Doug Britton serves as its CTO. They were kind enough to share with me the specifics of how their methods for randomizing memory for embedded devices really work, as well sharing their extensive experiences providing this technology to an impressive assortment of military and commercial customers.

“Our Alkemist platform hardens the underlying memory-base for operational technology-based systems,” explained Saunders. “This allows us to significantly reduce the attack surface for critical embedded systems such as weapons, vehicles, power plants, and the like. An attacker trying to corrupt memory to run privileged code, will find that their efforts do not work if Alkemist has been used.”

The RunSafe Alkemist solution is designed to stop buffer overflow and other memory-based attacks by a combination of technical methods, which are often referred to collectively as Runtime Application Self- Protection (RASP) and Moving Target Defense (MTD). Specifically, these security methods use randomization techniques on open source, in-house software, and third-party delivered software binaries.

The first method involves load-time function randomization, which is a fancy term for just shuffling around the locations of functions every time binary executables load. The second method involves block-level binary randomization, which reorders memory, block functions, and third party library access. Finally, the third method is stack frame randomization which inserts a randomized offset whenever functions utilize a temporary stack.

“A major advantage of our combined approach is that it works just as well on source code during the DevOps build process as it does for binary executables after they’ve been deployed,” explained Saunders. “This helps explain why we use so many different security methods in our platform. Customers can select and align the best available protection to whatever phase of the software lifecycle applies.”

During our discussion, I couldn’t help but notice how well the company is doing with the military and defense sector. Around the time of our meeting, Lockheed Martin Ventures had just announced a major investment in the company – and Saunders shared the names of several other major DoD customers who are enthusiastic users of the Alkemist platform to protect their embedded devices.

“The great success we’ve been seeing in the military sector matches up with the advanced cyber threats they see to their embedded devices,” explained Saunders. “Our solution complements other cyber security controls by making the most obvious malware attacks targeting memory – and also some other subtle ones that are usually designed by nation-state actors – no longer workable.”

Readers who manage critical environments with embedded devices would be well-served to pay attention here. I understand that memory-based attacks might seem somewhat passé, if only because they have been around in our industry for so long. But at TAG Cyber, our analyst team sees these attacks continue to nag enterprise and government applications – even in the presence of underlying ASLR support.

So please give the RunSafe team a call, and share your experience with us afterward. I look forward to hearing from you.