Fuzzy legal logic calls connecting to open wireless access points “theft.” Slashdot points out that a wireless access point is like asking someone to come in: http://hardware.slashdot.org/article.pl?sid=08/06/19/1411204&from=rss.

As I’ve been getting myself up to speed in learning about application security, a few resources have been extremely helpful.

A good general background on application security issues, unsurprisingly, is contained in The Art of Software Security Testing, co-authored by Veracode cofounder Chris Wysopal. The book goes beyond the basic description of classes of application security vulnerabilities into specific recommendations for testing strategies and ways to improve the software development lifecycle to avoid introducing vulnerabilities.

There have been a few pivotal written works about how certain classes of software vulnerability work. The canonical one is the Cult of the Dead Cow’s “The Tao of Windows Buffer Overflow,” written by veteran hacker Dildog. Written in a clear and easy to read (if profane) style, this work should scare the living bejeezus out of you.

There are some more business friendly summaries of other vulnerability classes available. One source for this information is Veracode’s own web site, which features clear explanations of SQL injection and cross-site scripting (XSS).

The mitigation is that it requires execution as the currently logged in user from the UI session, and apparently can’t be initiated over an SSH or other remote connection unless the attacker can log in as an account that is currently physically logged in on the machine. However, at a minimum it allows brute-forcing root access on any kiosk or other restricted machine that can be physically accessed. And one intelligent poster points out that all it takes is a phishing exploit that gets the user to execute the code on their own machine to open things wide up for a remote assailant–or a buffer overflow in (Safari, QuickTime, Flash, Firefox) that allows starting a shell.

Incidentally, simply disabling remote access is insufficient to prevent the attack. The ARDAgent.app must physically be removed from the machine. (For those interested, it’s usually found in /System/Library/CoreServices/RemoteManagement/.)