Security Watch

UCP Lets 'Em In

Plus, tracking sand out of JRE apps; greeting card hacks; RealPlayer BOV

• By Russ Cooper
• 04/23/2008

UCP is not enabled by default on the Cisco Secure ACS, but may be employed to provide a Web interface for password changes. The CGI scripts provided with the service do not properly validate the parameters passed to it. As with all such Web services, administrators should always ensure that parameters being processed are within expected bounds. That is, you may have to place the CGI calls within a page that verifies the input prior to passing the parameter along. Expecting Web services to do this for them, without testing, can lead to all sorts of problems.

Further, a site that permits user authentication is a site that is highly attractive to criminals. Therefore, that site, ideally, should not be exposed to untrusted individuals or should be monitored for brute force and other attacks. If UCP is being used, then ensure it resides on a server other than the Cisco Secure ACS.

Tracking Sand Out Of This Sandbox
Numerous vulnerabilities in the Java Runtime Environment have been patched in this Update. Criminally crafted applets could read or write local files or execute applications accessible to the user. The Java browser plug-in can bypass the same origin policy that should prevent it from escaping the sandbox and, in doing so, could execute arbitrary applications. Further, XSLT transformations could be leveraged to execute code outside of the Java sandbox in the context of the victim user. Finally, vulnerabilities in the Java image parsing library can be leveraged to execute code of the criminal’s choice if a potential victim were to render a criminally crafted image file.
http://sunsolve.sun.com/search/document.do?assetkey=1-26-233321-1
http://sunsolve.sun.com/search/printfriendly.do?assetkey=1-66-233322-1
http://sunsolve.sun.com/search/document.do?assetkey=1-26-233323-1
http://sunsolve.sun.com/search/document.do?assetkey=1-26-233324-1
http://sunsolve.sun.com/search/document.do?assetkey=1-26-233325-1

It is certainly interesting to see how the media, and most everyone else for that matter, ignores such vulnerabilities in Java. All of these vulnerabilities are similar to ActiveX vulnerabilities that have happened in the past, but what's worse with the Java vulnerabilities is the fact that Java purports to maintain a sandbox.

People may not remember the huge debates against ActiveX when it was first announced, but the big cry then was the fact that there was no sandbox. People decried its ability to interact with the system without restriction, and pointed at the Java sandbox as the ideal applet processing agent. If, however, the sandbox is so porous, then where is the benefit?

This is similar to the way people are thinking about Virtual Machines today. Far too many are putting their trust in the idea that the boundaries between multiple virtual machines can't be crossed easily, and so they might mistake VMs as having security boundaries. As with Java's sandbox, it is not a security boundary but instead a construct that may -- or may not -- function properly and limit what processes can do.

So no matter whether you think the JRE or ActiveX is better, remember always that flaws exist and neither may provide any security benefit. So, ensure that other adequate security measures are in place as well.

Greeting Cards with Ominous Messages
Criminals may have decided to start using ports other then HTTP for delivering their malware or infecting systems. F-Secure said it noticed a new Hallmark greeting card message from criminals who supplied it with an FTP URL rather than the traditional HTTP URL.
http://www.darkreading.com/document.asp?doc_id=148143&WT.svl=news1_2

The idea is to move away from transport protocols that are monitored for malware, such as SMTP and HTTP, in the hopes that their criminal transfers won't be blocked. Of course, for enterprises who have implemented reasonable security best practices, FTP should not be an available option except to those who absolutely must have it. As the protocol requires that the FTP server be able to reconnect to the FTP client on any port above 1023, it leaves a huge gaping hole in any reasonable ACL attempts. If it's allowed via a proxy, something which emulates the protocol for the client, then it can be better controlled such that the client's connection to an FTP server is compared against the attempted reconnection of the server back to the client. This means that the port the server requires can be dynamically opened on demand. So this new technique is not likely to catch many corporations, but home users may well fall prey.

RealPlayer Has A RealProblem
The "Console" COM component within RealNetworks RealPlayer can be made to trigger a buffer overflow, which could lead to code of a criminal's choice running in the context of the victim user. At the time of publication of the vulnerability, there was no patch. Worse, the vulnerability was published with proof-of-concept exploit code to instruct criminals how to perform the exploit.

As expected, this vulnerability was attacked within a couple of weeks, appearing on social networking sites and Web forums. Such sites are ripe for these types of attacks because they allow user-created content to be posted for others to see, often without victims having to do anything other than visit their own profiles.

This is the "Web 2.0" issue that many refer to. The problem is easy enough to describe: Let's build a subdivision where anyone can build any type of home they want! The site owners delineate the lots, and you can go crazy inside your lot.

Imagine if we allowed such uncontrolled, unregulated and uninspected building in the real world. Houses would likely collapse in on each other, a power surge from one home could take out the electronics in 50 others and nobody would be safe to walk the streets for fear of explosions from improper natural gas piping.

HTML was intended to allow everyone to create content and to link their content to that of others. It's a wonderful concept, no doubt, and reasonable that it led to the many forms of content that we can now individually create and distribute such as videos and interactive applets.

Unfortunately, when a subdivision is built that streamlines the distribution of individually created content but then isn't sufficiently overseen, all sorts of problems arise. With little active policing, it comes down to the community itself to first be hurt by something, and then report it. In Web terms, this is an extremely slow method of removing harmful content.

The ideal solution is to have a content submission mechanism that parses the content to verify it can't do anything it isn't supposed to do. As we have seen over the past few years, however, we know that parsing tools are incredibly insecure and open to all sorts of attacks. Further, they have an extremely excellent track record at failing gracefully. This opens the operators of the community to attack should they try to automate a content submission process. No doubt they also have a raft of lawyers who warn against such efforts for fear of being sued if they refuse to accept something.

So, we should focus on the content creation tools and try to ensure they did a better job of preventing criminally crafted content to be included -- but these tools are rarely to blame. You can craft most of the content by hand if you want to, or at least via an include statement that looks benign to content creation tools.

In the end we have to understand just what these communities are. They're fun, interesting, informative and they let you have a new crowd of friends -- but they're also potentially dangerous, unsupervised (for the most part) and self-policed.

The best advice to offer at this point is: If you don't already have a content filtering system in place, then it's time to get one. Things are going to get a whole lot worse before they get much better.