An Autonomous Zone

So I think this a really cool blog entry by the Windows master Mark Russinovich: “The Case of the Insecure Security Software”.

In short it discusses a tool he wrote called AccessChk which helps identify weak permissions problems. Apparently he had received some requests from groups within Microsoft and elsewhere to extend its coverage of securable objects analyzed to include the Object Manager namespace (which stores named mutexes, semaphores and memory-mapped files), the Service Control Manager, and named pipes.

After he had revised AccessChk he ran the tool on his box to see what system-global objects the Everyone and Users groups can modify.

As he states: The ability to change those objects almost always indicates the ability for unprivileged users to compromise other accounts, elevate to system or administrative privilege, or prevent services or programs run by the system or other users from functioning. For example, if an unprivileged user can change an executable in the %programfiles% directory they might be able to cause another user to execute their code. Some applications include Windows services, so if a user could change the service executable they could obtain system privileges.

He also played with write access from the Authenticated Users and Users groups on different namespaces. According to the blog:

An output line, which looks like “RW C:\Program Files\Vendor”, reveals a probable security flaw.
To my surprise and dismay, I found security holes in several namespaces. The security settings on one application’s global synchronization and memory mapping objects, as well as on its installation directory, allow unprivileged users to effectively shut off the application, corrupt its configuration files, and replace its executables to elevate to Local System privileges. What application has such grossly insecure permissions? Ironically, that of a top-tier security vendor.
For instance, AccessChk showed output that indicated the Users group has write access to the application’s configuration directory (note that names have been changed):
RW C:\Program Files\SecurityVendor\Config\
RW C:\Program Files\ SecurityVendor\Config\scanmaster.db
RW C:\Program Files\ SecurityVendor\Config\realtimemaster.db
…
Because Malware would run in the Users group, it could modify the configuration data or create its own version and prevent the security software from changing it. It could also watch for dynamic updates to the files and reset their contents.
For the object namespace, it reported output lines like this:
RW [Section] \basenamedobjects\12345678-abcd-1234-cdef-123456789abc
RW [Mutant] \basenamedobjects\87654321-cdab-3124-efcd-6789abc12345
…
He also states:

In the wake of my discovery, I analyzed the rest of my systems, as well as trial versions of other popular security, game, ISP and consumer applications. A number of the most popular in each category had problems similar to those of the security software installed on my development system. I felt like I was shining a flashlight under a house and finding rotten beams where I had assumed there was a sturdy foundation.

Then he kind of hit the nail on the head:

The security research community has focused its efforts uncovering local elevations via buffer overflows and unverified parameters, but has completely overlooked these obvious problems – problems often caused by the software of security ISVs, or in some cases, their own.

Now, while I’m sure that the security research hasn’t “completely overlooked these obvious problems” I would bet that it’s an area that could garnish some nice results with a bit of looking into.

Through the process of reading “The Art of Software Security Assessment” I came across a few really cool problems in software similar to this. I had heard of some of these problems before, but I hadn’t gotten into too much detail concerning them.

There are chapters in the book that go into a bit of detail on issues like this that provide a really good fundamental understanding of similar problems:

Chapter 11: Windows I: Objects and the File System
Chapter 12: Windows II: Interprocess Communication

Another cool chapter / subject is Chapter 13: Synchronization and State. It talks about Reentrancy (Reentrancy refers to a function’s capacity to work correctly, even when it’s interrupted by another running thread that calls the same function), Asynchronous-Safe Code, Signals and other things.

Most pentesters know about buffer/heap overflows, integer overflows, off-by-ones, race conditions, and similar common exploitable vulnerabilities, but what about using Signals to escalate privilege or cause a double free() in code that is not asynchronous-safe?

Here is a great paper by Michael Zalewski “Delivering Signals for Fun and Profit” that talks about this:

From the paper:

Below is a sample ‘vulnerable program’ code:

— vuln.c —
#include <signal.h>
#include <syslog.h>
#include <string.h>
#include <stdlib.h>

void *global1, *global2;
char *what;

void sh(int dummy) {
syslog(LOG_NOTICE,”%s\n”,what);
free(global2);
free(global1);
sleep(10);
exit(0);
}

int main(int argc,char* argv[]) {
what=argv[1];
global1=strdup(argv[2]);
global2=malloc(340);
signal(SIGHUP,sh);
signal(SIGTERM,sh);
sleep(10);
exit(0);
}
—- EOF —-

You can exploit it, forcing free() to be called on a memory region filled with 0×41414141 (you can see this value in the registers at the time of crash – the bytes represented as 41 in hex are set by the ‘A’ input characters in the variable $LOG below). Sample command lines for a Bash shell are:

$ gcc vuln.c -o vuln
$ PAD=`perl -e ‘{print “x”x410}’`
$ LOG=`perl -e ‘{print “A”x100}’`
$ ./vuln $LOG $PAD & sleep 1; killall -HUP vuln; sleep 1; killall -TERM vuln

The result should be a segmentation fault followed by nice core dump (for Linux glibc 2.1.9x and 2.0.7).
(gdb) back

#0 chunk_free (ar_ptr=0×4013dce0, p=0×80499a0) at malloc.c:3069
#1 0×4009b334 in __libc_free (mem=0×80499a8) at malloc.c:3043
#2 0×80485b8 in sh ()
#4 0×400d5971 in __libc_nanosleep () from /lib/libc.so.6
#5 0×400d5801 in __sleep (seconds=10) at ../sysdeps/unix/sysv/linux/sleep.c:85
#6 0×80485d6 in sh ()

So, as you can see, failure was caused when signal handler was re-entered. __libf_free function was called with a parameter of 0×080499a8, which points somewhere in the middle of our AAAs:

(gdb) x/s 0×80499a8
0×80499a8: ‘A’ <repeats 94 times>, “\n”

You can find 0×41414141 in the registers, as well, showing this data is being processed. For more analysis, please refer to the paper mentioned above.

For the description, impact and fix information on Sendmail signal handling vulnerability, please refer to the RAZOR advisory at: adv_sm8120.

Obviously, that is just an example of this attack. Whenever signal handler execution is non-atomic, attacks of this kind are possible by re-entering the handler when it is in the middle of performing non-reentrant operations. Heap damage is the most obvious vector of attack, in this case, but not the only one.

Anyways, none of this stuff is new, but it’s food for thought for anyone who wasn’t really familiar with these type of vulnerabilities.

Cheers,

Chuck B.