Attack Surface

Is Linux Security as Bad as Microsoft Windows “Security?”

Linux proponents often gloat over the seeming lack of security vulnerabilities in the Linux kernel when compared to Microsoft Windows; Windows proponents counter saying that Linux is just enjoying “security through obscurity.” Seems the Windows people may be justified to some degree as reports of a Linux vulnerability puts most versions of the Linux kernel built in the last eight years at risk of complete takeover.

According to The Register, “The bug involves the way kernel-level routines such as sock_sendpage react when they are left unimplemented. Instead of linking to a corresponding placeholder, (for example, sock_no_accept), the function pointer is left uninitialized. Sock_sendpage doesn’t always validate the pointer before dereferencing it, leaving the OS open to local privilege escalation that can completely compromise the underlying machine.” This means that it’s trivial for an attacker to put code in the first page and that code will get executed with kernel privileges. You can read a full rundown of the vulnerability at the CR0 Blog.

All Linux kernel 2.4 and 2.6 versions since May 2001 are affected. The vulnerability has been patched, but “this is the second time in less than a month that a serious security vulnerability has been reported in the Linux kernel. In mid July, a researcher alerted Linux developers to a separate "NULL pointer dereference" bug that put newer versions at risk of complete compromise,” according to The Register.

There’s no question that Microsoft has ongoing security issues; it’s no surprise that Linux is beginning to show the same. The only difference lies in the attack surface; Microsoft is still the biggest target. As Linux continues to gain market share, however, we’ll be seeing more researchers focusing their attention on the Open Source OS; as they do, they’ll find more and more vulnerabilities there, too.

There’s a technology called “secure coding” that still hasn’t been fully developed, much less implemented on a grand scale; until programmers fully get this concept, we’re saddled with insecure OS’s and applications.

Twitter Attack: Whodunit and How? Whonose?

Speculation abounds over who was responsible for the DDoS attacks that affected Twitter–and to a lesser degree, Facebook and LiveJournal–this past Thursday.

Various sources, including CNN and CNet, suggest that a Georgian blogger with accounts under the name “Cyxymu” (a town in the Republic of Georgia) on the services was targeted. The date of the attack coincides with the one year anniversary of the Russia-Georgia conflict.

Other sources, including The Register suggest that a JoeJob was the main source of the attack.  Joejobs are spam messages designed to induce someone to click on a link in the hopes that enough people will do so, thereby harming the site being linked to.

Still others blame a conventional DDoS attack using botnets, but Arbor Networks‘ analysis actually shows a drop in traffic volume hitting Twitter during the alleged DDoS attack, leaving doubt that this method was used.

I’ve also seen reports blaming hackers angry at Twitter for becoming more popular than IRC, a vigilante trying to point up the danger of botnets, and cyber-terrorists.

Seems no one really knows for sure at this point.

Shrink Your Attack Surface

I’ve heard this phrase bandied about in Linux forums and in the occasional blog post, but it’s something I never considered relative to the security of Windows boxes.  There’s an awful lot of research on the subject and it boils down to this: The larger the attack surface, the more insecure the system. Makes sense, but just what is an attack surface? Thanks to a research paper, Measuring a System’s Attack Surface, Pratusya Manadhata and Jeannette M. Wing, CMU Technical Report CMU-CS-04-102, January 2004, we have a concise definition:

A system’s attack surface is the set of ways in which an adversary can enter the system and potentially cause damage.

This means that any applet, any built-in feature, any module, any application, probably contains multiple attack vectors. Moreover, certain applications like Internet Explorer are attack vectors in and of themselves. When I started to look into this, I found that some folks over at the Microsoft Developer Network had put together a discussion along with a handy list of Windows attack vectors:

• Open sockets
• Open RPC endpoints
• Open named pipes
• Services
• Services running by default
• Services running as SYSTEM
• Active Web handlers (ASP files, HTR files, and so on)
• Active ISAPI Filters
• Dynamic Web pages (ASP and such)
• Executable virtual directories
• Enabled Accounts
• Enabled Accounts in admin group
• Null Sessions to pipes and shares
• Guest account enabled
• Weak ACLs in the file system
• Weak ACLs in Registry
• Weak ACLs on shares

Bear in mind that any of these can be subject to multiple vulnerabilities and many of them have been connected with specific vulnerabilities. However, the attack vector itself does not necessarily indicate a system vulnerability, per se. Think of  these as things an attacker would try to compromise; for example, attempting to logon to a system as Guest. If the Guest account is enabled, that’s a vulnerability; if the Guest account is disabled, it’s merely a vector for attack.

So, how can we use this information in our workaday world? First, realize that the OS itself is the basis of all of the above items. Next, realize that any program, web application, widget, gadget, what have you, is going to utilize one or more of them.  Finally, get the concept of “default unnecessary.”  Windows comes with many built-in (read default) features, services and applications—many of them completely unnecessary in the enterprise.

We shrink the desktop attack surface by building our desktop image in three stages:

• We clean up the OS by removing ALL unnecessary features, tools, and applications. A good place to start is all the stuff in the Accessories folder. And who ever uses Microsoft Backup, or Character Map, or Tour Windows XP? You get the idea.
• Given a stripped-down image, we next install ONLY those applications and tools that are absolutely necessary for the user to perform her job. Ideally, we avoid mainstream applications and utilities as much as possible and go with those that are not as widely used (security through obscurity) and therefore not as subject to attack. For example, if PDF isn’t used in the enterprise for purposes other than reading manuals, why use Adobe Reader? Foxit Reader or any of the Open Source apps will work.
• Finally, disable all services and uninstall all protocols that aren’t required by the OS or necessary applications. The first things that come to mind here are UPnP and the SSDP Discovery Service and the Net.tcp Port Sharing service.

That will give us a clean desktop setup with a significantly lower attack surface; come to think of it, you should probably go check the servers, too.

If I’ve missed anything, let me know.