Tuesday, May 10, 2005

The missing glue in the fight against malware

by ZDNet's David Berlind --
“ …Three years from now, the spyware problem will be worse than it is today and I’ll be writing about one of the reasons that there has been no improvement: the failure of the industry to recognize where technological consensus is needed, and then to build solutions on top of that consensus technology.

So, in the case of spyware, what would that technology be? I’m directing that question rhetorically at the new executive team at Tenebril because it’s simply an extension of the same conversation that I was having with them about personal firewalls while they were at Zone Labs. Personal Firewalls and anti-spyware have quite a bit in common. In some ways, personal firewalls help to solve the spyware problem because they can block spyware from "phoning home" — what happens when malware reports back to its creators or distributors with its findings (eg: logged keystrokes).

But, one reason personal firewalls aren’t always successful in this endeavour is that they often require user inputs. When a personal firewall detects a first time attempt by some process to reach the outside world, it notifies the user that something new is trying to get out and it asks the user if the attempted communication should be permitted. But, as I’ve written before, this allow/disallow inquiry is all too often noticably deficient in the kind of information a user needs to make an informed decision. This is particularly troubling since, regardless of whether it’s trapping malware or legitimate software, the wrong answer might render your software inoperable. "LSASS.EXE is trying to reach 177.24.202.16. Allow Always? Allow this once? Deny?" it asks me. What the heck is LSASS.EXE? What or where is 177.24.202.16? And finally, why isn’t the software answering these questions for me?

The answer to that last question is easy. The software doesn’t know. Nor, considering the number of software components out there (legitimate and not), can it know. For a while, with many personal firewalls, this meant that answering the allow/deny question was guesswork (or, a lot of Googlework). Fortunately, guessing couldn’t get you into too much trouble. Sooner or later, every networked computer loses its connection to its network anyway. When, through a personal firewall, a user denies network access to a particular software component, the net result for that software component is pretty much the same as what happens when the system suddenly loses its network connection for some other reason (the cable get pulled out, the Wi-Fi signal disappears, etc.). If a user mistakenly denies network access to a legitimate software component that needs it, and the system or the software hangs, fixing the problem requires little more than a reboot and a correction to the firewall’s ruleset.

But that’s not how software should work. And when I started dinging Zone Labs and other firewall makers for having this problem, I also recognized that no single firewall developer — not even Symantec — was big enough to develop and maintain the database they’d need in order to provide users with the information required to make an informed decision. How do I know this? Some of them tried. But the information was invariably incomplete. To really do that database right would require the participation of all the software vendors, and for them to participate, it would have to be easy and it would have to be centralized. ”

http://blogs.zdnet.com/BTL/?p=1353

Mac malware door creaks open

"The average user, who can't find their Library folder with two mice and a spotlight, is stuck. It would take all of 30 seconds for me to pick out a nice porn image, make it the icon of a widget, drop it in your dashboard and you're stuck with it. It doesn't even need any Javascript," Stephan added.

by Jo Best ,
“Apple seems to have unwittingly opened a door in its Tiger OS--seen by some as a safer haven from viruses--to malware authors.

Apple has been encouraging developers to create new widgets for Tiger's Dashboard-—a semi-transparent layer of everyday, often-used applications such as a calculator or currency converter that appears over the user's desktop—-but within days of its public release, one developer claims to have already found a way to turn widgets into potential malware. Developer Stephan, who has posted the widgets to his blog, has created two mini-apps which he describes as "slightly evil."

One widget, he says, will automatically install itself on users' desktops when his "Zaptastic" Web site is visited using Apple's Safari browser. This, according to Stephan, is a golden opportunity for porn scammers, enabling them to auto-install widgets that can hijack browsers.

According to Stephan's blog: "I happen to like (auto-install). I think it's a great thing. But, as I have demonstrated here, it has the side effect of setting up a situation where a user can be given an application without their knowledge.

"That's not such a big deal; by default, widgets can't do much damage, and they can't run unless you drop them into your dashboard. The funny thing is that once that widget is there, according to Apple, you CANNOT remove it."

Widgets cannot be removed directly from the toolbar, but they can however be deleted from the Library folder.


http://techrepublic.com.com/2100-10595_11-5700982.html

Google Outage Dims OS X Tiger Debut

Before we get too excited, though, it's important to look at Dashboard's capabilities through the lens of the network's imperfections. When Sun trumpets its long use of the mantra, "The Network is the Computer," I bite back the temptation to retort that I'd never pay for a computer that behaves as badly as a network: one where any given memory address, for example, might or might not respond to a read or write operation at any given time, or where devices might come and go without warning.
By Peter Coffee

“You couldn't choreograph a more ironic pas de deux than the debut of Apple's OS X 10.4, with its Web-intensive Dashboard of data-tracking "widgets," followed just nine days later by a multihour outage of several Google services.

The first event illustrated, not just with a developer-conference demo but in an actual shipping product, the difference that results when always-on connections are designed in rather than added on to an end-user environment.

The second event was a rude reminder that "always-on connection" borders on an oxymoron, or at any rate tempts the Fates to rub our noses in technology's fallibility.

What makes Dashboard much more interesting than I expected is the combination of Web services on the back end, at least for the widgets that I find actually useful, and Web standards-based authoring on the front end. With a user interface defined by HTML and Cascading Style Sheets, and dynamic behavior defined in JavaScript, a widget is relatively straightforward to develop--and robust in operation thanks to the fact that it runs on a real Unixoid operating system. Very cool.

Before we get too excited, though, it's important to look at Dashboard's capabilities through the lens of the network's imperfections. When Sun trumpets its long use of the mantra, "The Network is the Computer," I bite back the temptation to retort that I'd never pay for a computer that behaves as badly as a network: one where any given memory address, for example, might or might not respond to a read or write operation at any given time, or where devices might come and go without warning.

My concerns about network inconsistency and volatility are substantial even in benign environments: Things get much worse when someone actually is out to get you with, for example, a man-in-the middle attack that obtains valuable information just from knowing what questions you're asking.

http://www.eweek.com/article2/0,1759,1813991,00.asp