Security Watch

Grounding This Jet Engine

Buffer overflow again hits Microsoft's Jet Database Engine. Plus: Monster.com goes down; bad SMS causes big stink.

• By Russ Cooper
• 01/14/2008

There's nothing new about being fearful of .MDB files even though, historically, most of the past vulnerabilities have not been widely exploited. Microsoft refuses to consider a patch for the vulnerability; it believes everyone should be using good sense and blocking such attachments at gateways. But Web hosting companies don't have that same luxury. Their shared servers are likely going to allow an MDB as a data source, particularly if they charge their customers for SQL Server access.

So while MDBs have been able to execute commands for a long time, the nature of this parsing engine vulnerability affects shared servers more severely than is ever likely to be the case of users' desktops. If Client A can compromise the shared server, hackers can access all the other clients of that shared box. This could be done by simply coding up an Active Server Page that establishes a connection with the criminally crafted, and probably locally hosted, MDB.

It's no wonder, then, that the U.S. CERT say they are aware of active exploitation of the vulnerability. That notification, however, would seem to suggest they're seeing it as an e-mail-borne attack. While possibly true, it wouldn't be our fear given we've always had MDB on our e-mail attachment block list.

If you have boxes on hosted shared server environments, now might be a good time to ask your provider whether they allow other customers on your box to call MDB files from scripts.

Monster Taking Down
Monster.com somehow managed to get some of its pages criminally altered in such a way that it was serving up an IFRAME that redirected visitors to a site that installs the Neosploit criminal toolkit. Monster took the affected areas of the site down to purge the criminal content. (Read Infoworld's report here.)

Still no news as to how the hack was actually done, which is pretty disconcerting. If it were criminally crafted advertisements fed through some ad network, then we'd expect to have heard by now just who was involved in order to identify other sites which may also have been affected. Since that hasn't happened, the more likely assumption is that it was due to SQL injection into dynamically generated pages at Monster.

The issue of well-known and well-trusted sites compromised is becoming more of an issue. Historically, we have believed that the vast number of such sites do an adequate job of ensuring the integrity of their pages. This is best done by secure programming practices and determined oversight of changes to any dynamically generated code. However, ensuring that input is only that which is permitted still seems to be a significant problem for sites of all sizes. This must be a huge problem for Monster given all the input they must allow in order for the site to function well for its customers.

Microsoft's Internet Explorer model including "Trusted Sites" has long been a way to prevent active content from posing a problem when visiting sites other than those of companies you trust, but we may be entering a time when even that consideration must be called into question. The only way to maintain trust is to be forthright and honest about compromises, so your customers can determine whether their trust has been violated due to sloppiness or to an honest mistake.

City in Big Stink After SMS Downed
According to the mayor of Queanbeyan, Australia, Telstra altered or discontinued an SMS service that the city was using to monitor aspects of its sewage treatment facilities and to provide alerts to engineers in the event of problems. Sure enough, what followed was a power failure that led to pumps not being restarted and sewage accumulating in an area insufficient for the capacity. The power failure led to a million-gallon spill of sewage into Lake Burley. The lake was temporarily closed to human contact, but subsequently declared safe days later. Telstra, for its part, says it can see no reason that its change in its SMS service would have caused the problem.

One certainly has to wonder why the only procedure to prevent a four- or five-day backup of sewage in a holding facility not designed to store that much was to rely entirely on an SMS message. Do they not realize that SMS is an unreliable service, in the same way that SMTP is unreliable? There's no mechanism to ensure an SMS message has been delivered, nor to ensure the device it is delivered to actually received it in its original form. That type of alert is akin to sending up a flare and hoping that someone sees it.

Whether Telstra's service was altered or discontinued, the city must realize that using such services in a mission-critical applicaton is not only dangerous -- it's foolish. It may seem cool to some techno-dweeb sitting behind a desk to say, "Hey, we don't need no stinkin' periodic physical inspections; we've got an SMS alert system that will tell us when to go out there!" Meanwhile, there are probably a lot of people, fish and other wildlife who wished the city employees had double-checked their technology.

Don't get caught in the same trap. Technology is all well and good when used appropriate -- and most importantly -- backed up with a pair of human eyes, ears hands and feet!