In a talk at the Infiltrate conference in Miami Beach, Rosenberg said he found virtually nothing in the way of methods to mitigate exploit attempts on SLOB.
“There’s no sanity checks or exploit mitigations,” he said. “It’s a beautifully exploitable heap. They’ve done nothing to harden it to make it any harder.”
SLOB mainly goes in embedded systems, favored there because of its small footprint, Rosenberg said. Any given system will only have one allocator, and SLOB sees use in Linux systems on many routers and switches and also in some firmware systems.
“Linux completely dominates the embedded space. That’s part of its appeal,” he said. “You find SLOB in these embedded systems because it doesn’t tend to perform very well in other situations.”
There are several possible overflow scenarios that could be exploitable, ranging from the simple to the highly complex, Rosenberg said.
The scenarios he went through included a situation in which the attacker has control of some of the contents of one to two bytes of the overflowed chunk all the way up to a situation in which he faces an off-by-one null byte. His techniques resulted in gaining full control of the system.
He did not reveal any specific vulnerabilities in the Linux kernel, but rather was looking for techniques that he could use to exploit existing vulnerabilities in a variety of different situations.
“I was more interested in techniques that would work in progressively more constrained situations,” Rosenberg said. “If you understand how the heap works, you can get it done.”
Rosenberg said the lack of exploit mitigations could be due to just a lack of someone stepping up to take charge of the effort.
“There are never going to be exploit mitigations unless someone in the community writes them. Linux doesn’t have a Trustworthy Computing memo or anything,” he said. “It’s sort of an uphill battle when you’re dealing with so many platforms in so many high-performance environments.”