Security Watch

RSS Feeds That Leave You Open?

Maybe not, but trust only what you know. Also: beware the danger inside virtual machines.

• By Russ Cooper
• 03/26/2007

The more obvious conclusion is that sites that are set up to offer blogging services are simply less secure, with more vulnerabilities that allow criminals to take them over and use them to distribute their malware. Criminals are not likely placing their malware in the feeds, but simply on the sites that host the feeds -- there’s a big difference. Blogging software is still in its infancy, and much of it is a kludge to make the service work (think “shopping carts” from several years ago).

The article goes to great lengths to get several individuals to agree that malware submitted to RSS feeds would be a great way to increase delivery of that malware. While there’s no doubt that this is true, there’s equally no evidence that it's happening. Consider the difference between a site offering a Web page, and it offering the same content via RSS. Either way, the victim has to want to accept the content from that site. If the site’s RSS feed could be compromised to include malware, then it’s likely its Web site could also be compromised -- there’s little difference between them.

Finally, there’s the question of how the RSS feeds are being read. Typically, an RSS reader uses existing browsers, or browser components, to render the content in its feed. This usually means that whatever protections are available for the browser would be equally available to protect the user from criminal RSS content.

In the end, it boils down to a very simple reminder: You should only accept RSS feeds from sites you trust.

Another Week, Another Cisco Hole
Three vulnerabilities exist in Cisco’s IP phone devices. The first is in its Unified IP Conference Station devices, which contain a critical error in the authentication mechanism used by the HTTP Administrative Interface. They completely ignore authentication after an administrator has logged in. Before they can look for authentication to grant administrative privileges again, the system has to be cold-booted -- simply reloading will not reset the authenticated state. Patches are available.

The next involves Cisco's IP phones. These devices have been shipped with a default userID and password embedded in the system, which can allow anyone to remotely connect to the device as an authenticated user.

The last also involves the IP phones. This vulnerability allows any authenticated user the ability to elevate their privilege to that of administrator, and make any changes to the system such privileges provide.

One really has to wonder how devices can be released with such obvious security flaws. Buffer overflows are typically the most common security errors, and are at least somewhat understandable. The obvious lack of security testing of these devices by Cisco prior to release, however, makes one wonder whether the company had even thought of security with the devices. Of course, these devices should not be exposed to untrusted networks, so any attack will likely come from your own users.

Despite these glaring vulnerabilities, VoIP hacking is still more the stuff of legend than reality.

VMs Create Potential Risks
This is an interesting, albeit meat-free, article on the potential risks of using virtual machines. It suggests different risks that may be possible, and ideas that are being tossed around over how VM attacks might come about. It also suggests there will be a headlong rush into VM adoption, which is more a marketing wish than reality, at this point.

Like any application, Hypervisors, or the VM controller software that allows different VMs to reside on the same machine, can be securely or insecurely deployed. Furthermore, the VMs they spawn can either be deployed securely or not -- it depends on the installer.

Perhaps the only thing that rings true in the article is the fact that some will likely believe that their VM environments are as secure as the host environment. This will not likely be true by default; VMs will require careful consideration for security, each on their own. Equally true is the fact that keeping VMs up-to-date will be a complicated task. For example, ensuring that the host environment receives its appropriate Windows Update patches will be far easier than ensuring the same is true for the various VMs that are running.

Finally, if VMs are used to run out-of-date OSes to support applications with no forward migration path, an otherwise secure machine may be left with a gaping vulnerability via the application/OS running in a VM on the same box.