The other day, Karl Levinson added a comment to my previous entry about the Outlook OM. He raises some interesting points, so I thought I’d reply here. (Karl, please don’t take any of this personally; I hear the same arguments from people all the time, and it’s something I believe very strongly in — we’re not going to make the world a better place until we start focusing on the right problems to solve).
A quick opening comment: I am in full agreement that (in an absolute sense) a computer without VBA on it is “more secure” than a computer with VBA on it; the same can be said for almost any piece of software. The question is whether or not VBA should be singled out as the “bad guy” and special-cased for removal when you take a look at it from a value proposition / risk assessment perspective.
So here it goes (Jeff, I promise this will be a short entry! Honest! Ha ha ha):
I don’t see how you can argue that technologies like VBA and WSH don’t present a very compelling attack surface, given the billions of dollars and system availability that have been lost combating Office macro and .VBS viruses over the years.
Certainly VBA and WSH have been unwilling participants in a large number of viruses over the years; nobody can deny that. But ask yourself “Would the world be virus-free if WSH and VBA were never invented?” and of course the answer is “No.”
Those viruses were not caused by the presence any particular tool; they were caused by someone with malicious intent taking advantage of weaknesses in the perimeter defences of the user’s system (historically, the combination of e-mail clients not blocking potentially dangerous attachments, and users’ willingness to execute dangerous attachments after being socially-engineered into doing so).
On a technical note, nobody really attacks VBA or WSH; there have been very few security problems with each of those technologies, and none of them have been abused to the best of my knowledge. They are not an “attack surface” per se any more than the GNU C++ compiler is an “attack surface” — they are just tools that can be used by evil miscreants to help do their deplorable deeds.
Returning to the burglar analogy again, the rack of knives in your kitchen does not present an attack surface; it is the wide-open front door and your soft, fleshy exterior that are the attack surfaces. You can remove the knives to help mitigate any damage that an attacker might do if they break into your house, but:
1) They’ve still broken into your house and can use any other kind of weapon to attack you (including ones they brought with them!); and
2) Now you no longer have the utility of the knives at your ready disposal (maybe that’s a price you’re willing to pay)
Have any of the recent virus outbreaks (Slammer, Blaster, MyDoom, NetSky, Beagle, Witty, Klez, etc.), actually taken advantage of WSH or VBA or the Outlook object model? No; that proves that neither is necessary for the propagation of viruses. And have any of my machines (which have WSH and VBA on them) ever been infected with a virus? No; that proves that neither is sufficient for the propagation of viruses. It takes something else (a naive, curious, or malicious user; a buggy, poorly-designed, or out-of-date product; physical access to the machine; etc.) to propagate a virus, and the part played by VBA or WSH is more or less replaceable by any other technology.
And now MSH is coming down the pipe.
We’ve had batch files since the DOS days; should we rip out the batch processor from Windows? On an ironically related note, many people complain about the lack of a good scripting solution on Windows; they point to the (ultra-secure, of course) *nix variants with bash and ksh and perl and so on. How come nobody asks those guys to remove the features from the respective OSes? It’s because the people running those platforms tend to know what they are doing and would not execute arbitrary code from unknown locations. (At this point, someone will no doubt pipe up: “But you have to chmod +x a file before it will run on *nix!” to which I reply: “Yes, and you have to chmod +x <insert favourite application here> to install it, too!” — if I have the skill and authority to download, install, and execute CoolApp then I also have the skill and authority to download, install, and execute NastyVirus. But I’ve been over that argument before).
XP SP 2 does *not* fix the problems with VBA and WSH viruses… precisely because it does not disable the technologies in question.
You are correct, but you are correct because (brace yourself for even more controversy) there are no problems with VBA and WSH viruses to “fix!” There are only problems with users (unwittingly) downloading and executing malicious code. And SP2 tries to address that by locking down Internet Explorer (LONG overdue; you have no disagreement from me there) and by providing better blocking of attachments for applications that request it (see below).
But seriously, how would you “fix” VBA? Disable it? Great! No more VBA!
Now ask yourself, “What did that buy me?” All things being equal, you’re still just as susceptible as you ever were to all the viruses and worms I listed above, plus plenty more. All you’ve done is removed your ability to record macros or run other useful software applications on your system.
As I understand it, SP2 adds the
to block attachments and integrates this with OE and Windows Explorer. Unless I’m mistaken, some of the features of
may not protect users of other non-Microsoft software, email clients, P2P file sharing clients, etc.
Correct; applications have to know to call into the new API to take advantage of it, but that’s nothing new. Any time Windows adds a new API, applications have to be modified and re-released to take advantage of them. I seriously doubt that any file sharing client would ever use AES though — how would you download your warez from KaZaA if it blocked EXEs? (Yes I know there are legitimate uses of P2P software… I’m just being facetious 🙂 ).
Also you can’t expect Windows to blanket deny access to all EXEs or other file types; Windows doesn’t know why an application requests access to a specific file; it just checks “Is this user allowed to have access to the file?” and if so, grants it. This gets better with partial trust in the CLR because applications can have fewer rights than the user running them… but I don’t want to get into that right now. Hackers aren’t going to write managed apps (which are subject to stringent security checks) while they can still write native apps (which are not).
You don’t explain why it’s a good security practice [dare I use billg’s words, “secure by default”] to (1) leave these technologies enabled on, say, home computers, and (2) give the user absolutely no way to disable unwanted technology such as VBA despite numerous user requests.
That’s a good question, and I can’t really give you an “absolute” answer because security is about risk management, not risk avoidance, and since there are a lot of unknown variables involved it is not an exact science. “Secure by Default” is part of the SD3+C campaign and revolves around disabling (or not even installing) features if they present a high risk to the safety of the user’s PC or data. For example, a service that runs as SYSTEM and accepts unauthenticated packets from the network clearly represents a high risk and should be disabled unless it is absolutely critical for the health of the system. But what about the “Letter Wizard” in Microsoft Word? (I just picked a random feature I’ve never used) It’s not critical to the health of the system, and I bet most users never need it, but it doesn’t represent a high risk because it is not remotely accessible and a bug in it wouldn’t allow for elevation of privileges (it runs in the context of the user accessing it). So it is left on by default.
VBA and WSH clearly fall somewhere between these two extremes, but IMHO they are much closer to the Letter Wizard than they are to the SYSTEM service. Neither of them is remotely accessible or would allow an elevation of privilege if it were buggy. It requires explicit user action to invoke either of them (opening a file) and, in the case of VBA, it is already shipped in a pretty locked-down mode (no unsigned code will run from documents). You could argue that double-clicking on a JScript or VBScript file should open it in Notepad by default… but then what about EXE files — should they open in Notepad too? And screen savers? And Control Panel applets? And let’s say that we did this, and everyone learns that to execute a file you no longer have to double-click it, but instead you have to right-click and choose the “Run” command. What’s going to happen when the CelebrityNaked.exe virus comes around? People will right-click it and choose “Run!”
This is a phenomenon that I have witnessed many times over — the idea that script files and executables are somehow inherently different and should therefore be treated differently. It’s OK to execute an EXE if I double-click on it, but it’s not OK to execute a VBS file if I double-click on it. Hmmmm, why is that so? They’re both essentially the same thing. They can both do equivalent amounts of damage. In fact from the recipient’s perspective there is no discernable difference between them (and that is, funnily enough, by design)!
One thing that we do hear though is that “customers know EXEs are dangerous” and so they are less likely to double-click on an EXE than they are to double-click on a “known to be safe” (ha!) file type such as .TXT or .DOC, or on an unfamiliar file type like .VBS or .PIF. That may be true, but those users are fooling themselves. Even a text file can contain a virus! The basic idea is to trust no-one, especially not Prince Whatsumacallit from Nigeria who wants your help in liberating $10,000,000 and will give you a healthy cut of the deal if only you’ll give him your bank account details and pay hundreds of thousands of dollars in expenses. (My apologies to any non-419-scamming Nigerians who may be reading this blog). And don’t assume that just because you’ve never seen a .FOO file before that it will magically be safe! 🙂
I’m not asking for Microsoft to get rid of VBA or WSH or MSH… just recognize that these are proven virus platforms, and that we should have an easy way to disable them if we want, or even consider the security benefits of making them disabled by default.
As I have tried to present, VBA and WSH are not “virus platforms;” they are computer languages / runtimes.
But here I present three easy ways you can disable WSH if you so wish (ha ha, pun intended 🙂 ):
· On NTFS-based systems, ACL cscript.exe, wscript.exe, or any other files of your choice so that they are not accessible to the user. Lots of legitimate things may break if you do this though 😉
· Modify the registry keys in HKLM to map the “Open” verb for the various script extensions to run Notepad
· On Windows XP or Windows Server 2003, use Software Restriction Policies to block the execution of unsigned scripts
VBA is disabled for most scenarios out of the box anyway; just leave it at “High” mode (or the new “Very High” in Office 2003), uncheck the “Trust installed templates and add-ins” setting, and remove all the “Trusted Publishers.”
You state that disabling WSH and VBA would just “make you less vulnerable to the more “popular” attacks.” To me, that’s like saying “you shouldn’t run a firewall, because you’ll still be vulnerable to viruses.” Yes, the virus authors would probably start using other attack vectors… at which point we would want to take steps to reduce the risk from THAT new vector.
I would never recommend anyone not run a firewall 🙂 And I now realise I was actually a few years out of date by referring to VBA and WSH viruses as “popular,” but eh — I’ve never claimed to be up with the latest fashions 😉
Firewalls perform a very legitimate task by reducing your attack surface and providing a first layer of defence against malicious code attacks. They are the fortified castle walls that protect your soft fleshy body from the daemons of the night. But, as you note, they are not a panacea. Nothing is a panacea. Not firewalls, not partial trust, not digital signatures, not limited user accounts — nothing. It comes back to risk management again — you could disable WSH and VBA and bask in the (small) additional protection you got by not being vulnerable to viruses that party like it’s 1999, but you’d still be vulnerable to all the others and you would have lost the functionality that those features provide. Enabling a firewall, on the other hand, gives a significant amount of additional protection that (for many users) imposes no undesirable restrictions on their computer usage.
Also, making a truly secure by default computer does not mean secure yourself just from the most popular viruses. Even if few people are writing Word macro viruses nowadays, you’re still at risk from a teenager from Iraq writing one up to get into your nation’s infrastructure.
Yes, you are at risk from anyone from any country in the world sending you malicious code. I return to my point above — why focus on script (or VBA) as being different from any other kind of code? In an age where we have point-and-click virus creation tools and exploit testing tools, the argument that “it’s too easy to write script” doesn’t seem to matter much anymore.
Blaming the user here doesn’t increase security much, not when it’s a sure bet that at least 1 in every 100 users will execute an attachment, and you only need 1.
I don’t want to blame users; I want to educate them 🙂
That one user will click on the attachment whether it is a VBS, an XLS, or an EXE. Heck, they’ll even open up a ZIP file, type in some blurry password from an attached image file, and then open the EXE inside. And if they were running on MacOS or *nix, they’d do whatever was necessary to get the file to run on that platform, too.
Many of the people that run these latest viruses WANT TO RUN THE CODE — they just don’t know (or don’t care) that the code they are about to run is malicious. Maybe they think it’s a pornographic picture, or a cool joke, or a cracking tool for some hot new game. Maybe they’ve been told their internet connection or their bank account or some other valued resource will be cut off if they don’t run it. I don’t know. But the newer viruses get executed not because of any flaws in the system, but because there is a person at the other end who has been tricked into doing something they probably shouldn’t have done.
Nobody argued for disabling RPC in Windows because Microsoft programmed RPC into many other products that Microsoft Windows customers are also running. Besides, there’s already a way to disable RPC/
if you wish.
WSH and VBA are also used by many products that customers want and need; in fact many companies run their business on solutions built on top of VBA or script.
There’s no way to disable VBA. I’ve asked.
Surprise! I have an early Christmas present for you 🙂 VBA has been an optional component of Office for (at least) the last two releases!
· Select Start -> Run -> %comspec%
runas /user:Administrator “control appwiz.cpl”
· Select “Microsoft Office Professional Edition 2003” and click “Change”
· Select “Add or Remove Features” and click “Next”
· Select “Choose advanced features” and click “Next”
· Expand “Microsoft Office Shared Features” and de-select “Visual Basic for Applications”
· Click “Update”
So you can completely un-install VBA if you don’t trust the “High” or “Very High” modes with all the other settings cranked way up… but things will break. For instance, you will probably be unable to install or use any 3rd party add-ins, formula libraries, etc. and of course you won’t be able to record and run macros.
We wouldn’t have had an ILOVEYOU virus if Microsoft had simply changed the default action on .VBS and other files from Execute to Edit.
See comment above — this would NOT have stopped ILoveYou-like viruses at all. The author would just have picked a different route, or a different author with more skill would have come along instead. MyDoom and the other recent viruses have done HUGE amounts of damage and do not rely on VBS. The fix to all these problems was to stop users from accessing unsafe attachments (which of course annoyed those of us that knew what we we’re doing and actually had legitimate reasons for receiving JS or VBS attachments… like say the Program Manager for JScript or the main dev for VBScript 😉 ). And possibly forcing the display of the real extension so that it says .TXT.VBS instead of just .TXT. (Yes Mr. Word Grammar Checker Sir, I know that’s a sentence fragment, but I like it that way!!!)
Can you give me a good reason why this still hasn’t been done on the “secure by default” XP SP 2 and Windows Server 2003? Will you trudge out the old excuse that this would somehow “break functionality?”
Yes, it’s probably for backwards compatibility, and they probably did a risk assessment and decided it wasn’t worth the effort. But I don’t have anything to do with the groups that produce those products; you should ask Michael Howard. Nevertheless, whilst the OS teams probably could make some changes to the way WSH worked if they wanted to, the OS team isn’t in the business of making changes to VBA, which is a feature of the Office System and a bunch of other 3rd party applications (I can imagine the uproar from our ISV partners if Windows XP SP 2 broke all the 3rd party applications out there that relied on VBA because of an “Outlook virus problem”).
Here’s another side to the equation: Let’s say the Windows team decided to disable WSH in the next version of Windows. That’s probably a 1-line change to some metadata file that goes into the Windows build process (to flip the reg key from cscript.exe “%1” to notepad.exe “%1”) but as Eric Lippert has pointed out, that’s not the end of the story! It would probably take — no kidding — a month or more to run all the necessary tests on this to make sure it was an “OK” fix. Hundreds or even thousands of 3rd party applications would be tested, and many of them would break in weird and wonderful ways. We’d have to co-ordinate with them, and where applicable we might make special shims for specific applications. And then when we did ship the product, PSS would be busy answering calls from customers asking how to turn it back on (and then there would be K