The flip side of adding security: Reducing attack surface

[Tom T.]

We generally think of security as something that's added on, either afterward (firewall, AV, NoScript, etc.) or baked in during design. (string- and bounds-checking, etc.)

I'd like to toss up another side of security: Not only can we *add* defense-in-depth, we can also *reduce the attack surface*.
Mistakes and omissions will be made by humans at the rate of X per every thousand lines of code. Ergo, the less code, the fewer places for vulns to exist. Right?
Think of trying to secure a fifty-room mansion with a hundred windows and twenty doors, vs. a one-room concrete house with a single door and one window.

We can start reducing attack surface by using the "smaller is better" principle when comparing competing apps that meet our needs, rather than succumb to "bullet-point marketing", which lists tons of (mostly useless) bells and whistles, designed to convince us that we're getting more for our money.

Example:
Adobe Reader 9.3 = about 350 MB hard drive space. Function: opens .pdf so you can read them.
Foxit Reader (http://www.oldversion.com) older version 2.0, with no native JavaScript support, another security bonus = 3.7 MB. Function: opens .pdf so you can read them.

So mathematically, Adobe has about 100 times the attack surface of Foxit. The actual number of vulns may not be strictly proportional, or, on the other hand, could be exponentially greater. In any event, it logically must have more potential places for exploits to be found.

I've carried this principle to the operating system itself, doing some rather drastic pruning to Windows XP. Typical size of WINDOWS folder = about 4 GB, with anywhere from 10,000 to 30,000 files or more. My windows folder, on the machine on which this is being written and posted:




Consider MS Update 980182. Twenty-three files are replaced for IE 6 on 32-bit XP. Of those twenty-three, only seven were still on this machine. One of the most critical files to the exploits, iepeers.dll, had been deleted a year or more ago. So this user was essentially immune to these exploits long before they were discovered, much less patched. *That* is the point I'm trying to make here. The less, the merrier.

This is not some bare-bones system. Fully-functional laptop, with two space-eaters not found on desktops: Wireless connectivity with WPA2 encryption, and touchpad with enhanced features. Also has direct connectivity to the modem via both Ethernet and USB cables.

Third-party firewall and AV. Supports a printer-scanner wirelessly, plus a stand-alone printer through USB. Open Office suite (trimmed to my needs). And everything else used for most home purposes. Online gamers, though, would miss seeing their bazooka splatter someone's guts all over their living room in 3-D Surround Sound. (Have to settle for basic graphics and stereo sound - gee!)

I'm not suggesting that everyone could, would, or should go this far. Only that we should consider bloat as an enemy of security, and that we can be proactive in choosing smaller, lighter products, and, for the technically-inclined, pruning that which we don't need.

And that reducing attack surface is as important, if not more, as adding defenses.

Hope this provokes some thought and comments.

DISCLAIMER: Many of the changes involved in such trimming are undocumented and unsupported. For advanced users only, at your own risk. Make frequent full-disk-image backups as well as data backups, so any fatal error will not be costly and can be restored easily without loss of data or applications.

p. s.: This trimming project, including doing research and recovering from mistakes (ouch!!! -- they happen ) has occupied a good deal of my spare time for quite a while, another reason for my being MIA here for a number of months. I think it's about as far as it can go now.

[luntrus]

Hi Tom T,

Very interesting thought pattern you follow here, and thanks for the insight into this.
But where do we start as the general flow is into the reverse direction - more and more driven on by the vendors. patch, upgrade, patch cycles, more apps, etc. etc.
Some do things this way read: http://forum.avast.com/index.php?topic= ... #msg514923
Yes we could minimalize, take off services we have no need for (java for instance, why use it if you have no need for it) or use services only on a on-demand basis...
Then there is the young generation that rather do a total recall and take their HD to granny's computer, then to use resident av combined with optional non-resident anti-malware.
And the group not using firewalls or in-the cloud scanning is an ever growing one.
Or there is a third way even, that we minimalize and have all our proggies/tools/data "in the cloud" somewhere and leave the protection to a third party (firms may have some problems with this, I am Dutch of origin , so here outside the European economic realm, well that means the Isle of Man is OK for storing data, but Cayman Islands may be creating judicial problems, so we have not grown into thiese new thinking patterns yet and while Google is leading the way there slowly but surely (browser without plug-ins needed, OS in the cloud etc. etc.), MS is sure to handle a couple of brakes to prevent monopoly loss for them and for users to go there any sooner as when there is enough critical mass they can no longer prevent it or reach a common denominator to profit from. But again thanks for your refreshing thoughts on these problems, there are more contemplating this: http://www.nliteos.com/download.html

luntrus

[dhouwn]

The idea of reducing attack surface is the main security feature of NoScript.
And in terms of operating systems, that's how it's properly done for servers.

leave the protection to a third party

What about protection against social engineering?

[Tom T.]

@ luntrus: Thanks as always for your insightful reply. I was able to simplify your instruction set greatly: I can just click Start > Run, type firefox (enter), or firefox -chrome (enter) and Fx opens up immediately, without having to open a command prompt window. However, I didn't see any difference when the -chrome was added. Now, I have very minimal toolbars, etc., so if this strips off only additional toolbars and such, I wouldn't see it. And we *need* the back, edit, view, bookmards, tools, and NS menus, no?

So I tried it from a command window -- same results. Can start Fx (without any directory changes, although I tried that as well), but with or without -chrome doesn't seem to make a difference. Is this possibly only a F3+ feature? (Yes, I still run Fx 2.0.0.20. Don't ask me why. ) Also, in no case (Run menu, cmd.exe, directory changing vs. direct command) was I able to browse to a URL using that command. The browser just opens to my "home page", which is blank. Also possibly F3+ only?

It's also possible that some of the files I've deleted might be involved, but I doubt it, because Fx (2, anyway) isn't that bloated to begin with (bloat was one of my objections to v3), and also is much more self-contained than IE, which relies heavily on Win OS files. In any case, I'm not sure that running the browser without "chrome baggage" quite falls into my train of thought. I was thinking more of actually deleting files from the HD, on the grounds that a file that isn't there can't be exploited due to a buffer overrun or other flaw in the file.

As for how we buck the trend: As mentioned, we include footprint in our criteria when comparing competing apps; we prune our systems of unneeded services *and their support files*, and of everything else in the OS that we're sure we'll never use. Like, for example, the setup .inf for Windows 3.1 from 1991. (Yes, that is still in XP, and is one of the files I deleted.)

I am very much convinced that the cloud is a dangerous place and a bad idea. The minute you give your data to someone else, you lose all control over it. I don't know how secure the cloud provider is, and I can't do anything about it. The machine and data that are under my physical control, I can take steps to secure. We don't have to follow a trend just because it's there, or because everyone else is. Regardless of what Google or MS does, we can choose to keep our own data and keep our apps under our own control, rather than trust either giant.

I am familiar with nlite and a couple of other pre-trimmed systems. One problem is that it doesn't know what hardware you have, hence, what drivers you need and which you don't need; what apps you have -- same issue. Another issue that has been raised is that apparently, it is safe to *delete* certain OS files, so long as you do not *unregister* them. If they are never installed in the first place, you would not have those needed registry entries. The source for that statement is here. Plus, you might later install things that require the missing files. By starting from a full install, and of course, making backup copies of it before starting trimming, you have those available if needed later. Same thing if you have the full-sized Win retail install disk. However, my system came OEM-preloaded, as most do. I could reformat the drive and use one of the "lite" install disks, but only if I made the full copy first --- my OEM "recovery" disk will not let you extract one file, as a Win CD will.

So I have all of the needed files and drivers for my particular system, but not the others; yet, the others are quickly available should the need arise.

Thanks for sharing your thoughts on this idea.

The idea of reducing attack surface is the main security feature of NoScript.

I'm sorry, I haven't expressed myself clearly enough. NoScript is about preventing Web-based code from running, which of course is crucial to good security. By "attack surface" I meant the sheer size and complexity of our operating systems and apps, which increases the opportunities for exploitation. Reducing the number of files and lines of code should reduce the number of possible "holes". This is an entirely different concept from that of NoScript, which is why I thought it might be worth a separate topic. If anything else in my OP isn't clear, please let me know, and I will try to explain myself better.

And in terms of operating systems, that's how it's properly done for servers.

I'm not familiar with Microsoft's server systems (or Apache's or any others, for that matter), but judging by how they create their user-side operating systems, I find it very hard to believe that they take an efficient, minimalist approach on their server systems. Of course, I could be mistaken, but they've never shown any regard for the type of concept I'm suggesting, AFAIK. Else, why would my perfectly-good 150-MB Windows folder be shipped as 4 GB?

What about protection against social engineering?

Absolutely crucial to security. But again, O/T to this post, which deals with reducing physical size (footprint) and amount of code at which an attacker can aim.

Again, I'm sorry if I didn't express my main concept adequately. Thanks for your comments.

[dhouwn]

Like, for example, the setup .inf for Windows 3.1 from 1991. (Yes, that is still in XP, and is one of the files I deleted.)

On a funny side note, you can even find these files in 64-bit Windows versions even though there is no 16-bit support.

NoScript is about preventing Web-based code from running, which of course is crucial to good security. By "attack surface" I meant the sheer size and complexity of our operating systems and apps, which increases the opportunities for exploitation. Reducing the number of files and lines of code should reduce the number of possible "holes". This is an entirely different concept from that of NoScript, which is why I thought it might be worth a separate topic. If anything else in my OP isn't clear, please let me know, and I will try to explain myself better.

Files per se are no attack surface, executable code is. NoScript is reducing attack surface by constraining the code a web site can run, you are reducing attack surface by removing executables (esp. those that can be loaded as plugins), I fail to see there that much of a difference.

I'm not familiar with Microsoft's server systems (or Apache's or any others, for that matter), but judging by how they create their user-side operating systems, I find it very hard to believe that they take an efficient, minimalist approach on their server systems.

http://en.wikipedia.org/wiki/Windows_Se ... erver_Core
Though, I wasn't thinking about Microsoft's Server OSes in particular.

[Tom T.]

Like, for example, the setup .inf for Windows 3.1 from 1991. (Yes, that is still in XP, and is one of the files I deleted.)

On a funny side note, you can even find these files in 64-bit Windows versions even though there is no 16-bit support.

ROFLMAO!!!! ... On the other hand, it's not surprising. MS doesn't pay anyone to go through their new systems and remove obsolete files, because there's no profit in it, and that person could be working on the profit-making aspect of shoving the system out the door. The user's resources are also of no concern --witness the class-action lawsuit in the UK, IIRC, or possibly EU also, over claims that "Vista would run on 95% of existing desktops" -- not!

NoScript is about preventing Web-based code from running, which of course is crucial to good security. By "attack surface" I meant the sheer size and complexity of our operating systems and apps, which increases the opportunities for exploitation. Reducing the number of files and lines of code should reduce the number of possible "holes". This is an entirely different concept from that of NoScript, which is why I thought it might be worth a separate topic. If anything else in my OP isn't clear, please let me know, and I will try to explain myself better.

Files per se are no attack surface, executable code is. NoScript is reducing attack surface by constraining the code a web site can run, you are reducing attack surface by removing executables (esp. those that can be loaded as plugins), I fail to see there that much of a difference.

You have thousands of .dll files in your Windows machine, many of which can be run as apps using the rundll or rundll32 (or, I guess, 64) command. MS critical vulns frequently involve many .dlls, as well as the Swiss-cheese ActiveX that Fx wisely doesn't natively support. These files may be essential to running code that you allow, at a trusted site, or to the ordinary operation of Windows, esp. to IE. If one has a critical flaw, you can be exploited. NoScript watches browser processes and Internet traffic; it doesn't monitor everything going on inside Windows. Please see the example in my OP, which happened to be aimed at IE. OK, I never use IE, but the point was that if I did, most of the files needed for that exploit had been deleted already.

MS has plenty of vulns unrelated to IE. Image-rendering, where you might download and save a photo from what you believe to be a trusted source. It doesn't matter which browser you use to d/l it, or whether NS was running at the time. You gave permission to d/l it. Yet, if you don't have the updates to GDI+ (look them up in MS Support) or the other image-rendering vulns, opening a malicious photo could run the attacker's code on your machine. Who knows what undiscovered flaws lurk in which of those 30,000 files (or 638 files, in my case)?

There are many other examples. Adobe Reader has indeed produced far more patches than Foxit Reader, as per OP. Every dll, exe, vbs, reg, .ocx, etc. file is a potential point of attack, and my feeling was that the fewer you have on your machine, the better. If you don't agree with this approach, no problem. I tossed up the idea to stimulate thought and comment, and I appreciate yours. Me, I like the side benefits anyway -- faster performance, faster defrags, faster boots, and faster and *smaller* backups. (I can put two full backups of my entire HDD on one 700-MB CD.)

Cheers.

[dhouwn]

MS doesn't pay anyone to go through their new systems and remove obsolete files, because there's no profit in it,

Well, someone would need to analyze which files are really useless and what consequensed their removal would have (it's quite possible there are some bizzare apps that need those files because they [the apps] are badly written or were meant for Win 3.1[1] with the 32-bit subsystem add-on) and write a design document, tests, etc.

You have thousands of .dll files in your Windows machine, …

I well understand how this works and that NoScript is just limited to the browser. What I meant is that NoScript is also a tool for reducing attack surface by reducing the possibilities for code to run without user interaction.

… many of which can be run as apps using the rundll or rundll32 (or, I guess, 64) command.

And another fun fact: The 64-bit version of the tool is also called "rundll32" and it resides in a folder with all the other 64-bit DLLs and system tools called "System32", while the 32-bit versions of these files are in "SysWOW64".

[Tom T.]

… And another fun fact: The 64-bit version of the tool is also called "rundll32" and it resides in a folder with all the other 64-bit DLLs and system tools called "System32", while the 32-bit versions of these files are in "SysWOW64".

MS works in mysterious ways, its wonders to perform!

Given that when they changed from 16-bit to 32-bit systems, they added the folder system32 for the new versions and left the old \system for the 16-bit back-compat, I guess I foolishly assumed that they would add a folder called \system64 for the new files, leaving \system32 as the back-compat for 32-bit files and apps. Silly me!

Even sillier of me to expect the 64-bit version to be called rundll64. I wonder how many third-party programming errors *that* will lead to? ... or does the same file, in its updated version, successfully launch both 32-bit and 64-bit dlls? ... that would be above MS's normal level of thought and performance. ... but if that were the case, there might not be such a need for WOW.