codesecurely.org : Microsoft

Securing ActiveX Controls

rudolph — Wed, 17 Oct 2007 04:20:03 GMT

I was reading my buddy Alex Smolen's post the other day on Java Applet Security and figured I would see his post and raise it with a post on ActiveX control security. Actually, as you can probably see I have been slacking on the posting front so figured it is about time and this specific issue – ActiveX control security has been something I have been seeing a lot of in assessments but it doesn't seem to be covered enough in both the testing literature out there or indeed in secure development guides.

As it turns out, ActiveX controls are at the end of the day C++ or C# or (pick your favorite language) code so much of the guidance on secure application development continue to apply as you would expect. However, ActiveX controls obviously add another interesting dimension – they are mobile code and execute not on the server like typical web applications do but on the client machine. That means any vulnerabilities in this control place each and every one of your customers at risk. In fact with some popular ActiveX controls this is such a rampant problem given that they are installed on hundreds of thousands if not millions of computers across the globe. What perhaps exacerbates the risk even more is these ActiveX controls typically provide very powerful functionality by leveraging deep access into the client computer. This in turn can mean you are putting your users at risk even if you have no stereotypical vulnerabilities in your control code. Let me explain, why just not having buffer overflows and the like is not enough to protect your customers.

Well it all really comes down to the trust model and the sandbox built for ActiveX controls in the browser – Internet Explorer for the most part. Enter the notion as being "safe for initialization and / or scripting". The relevant MSDN documentation on this is shown here:

Initialization Security

When a control is initialized, it can receive data from an arbitrary IPersist* interface (from either a local or a remote URL) for initializing its state. This is a potential security hazard because the data could come from an untrusted source. Controls that guarantee no security breach regardless of the data source are considered safe for initialization.

There are two methods for indicating that your control is safe for initialization. The first method uses the Component Categories Manager to create the appropriate entries in the system registry. Internet Explorer examines the registry prior to loading your control to determine whether these entries appear. The second method implements an interface named IObjectSafety on your control. If Internet Explorer determines that your control supports IObjectSafety, it calls the IObjectSafety::SetInterfaceSafetyOptions method prior to loading your control in order to determine whether your control is safe for initialization.

Scripting Security

Code signing can guarantee a user that code is trusted. However, allowing ActiveX Controls to be accessed from scripts raises several new security issues. Even if a control is known to be safe in the hands of a user, it is not necessarily safe when automated by an untrusted script. For example, Microsoft Word is a trusted tool from a reputable source, but a malicious script can use its automation model to delete files on the user's computer, install macro viruses, and worse.

There are two methods for indicating that your control is safe for scripting. The first method uses the Component Categories Manager to create the appropriate entries in the system registry (when your control is loaded). Internet Explorer examines the registry prior to loading your control to determine whether these entries appear. The second method implements the IObjectSafety interface on your control. If Internet Explorer determines that your control supports IObjectSafety, it calls the IObjectSafety::SetInterfaceSafetyOptions method prior to loading your control in order to determine whether your control is safe for scripting.

When it comes to ActiveX controls designed for the browser, it is more likely than not that these are marked as safe for scripting.

The problem is this approach is very binary – or in other words you can either mark an ActiveX control as never safe for scripting or always safe. Like we just said most developers will mark the object safe for scripting and all seems well. This is where it begins to get really interesting from a security perspective. A control marked as safe for scripting can be loaded by any and every web page developer whether they work for your organization or are the teenage, blackhat hackers down the street or in some dark basement half way across the globe.

Consider, now a familiar use case for an ActiveX controls – a control that lets you browse your local file system and add or delete files from / to the server. Developing this control just gave your company the award for most usable site on the entire World Wide Web and as they say business is good. Joe Hacker down the street is an avid user of your site and hence your ActiveX control realizes he might have a way to create a nice little botnet for himself through your ActiveX control. So here is what he does:

Creates a phishing site that looks perhaps just like yours or indeed anything else.
Within this site he loads your ActiveX control using the object tag he noticed in the HTML source of your website
Uses the interfaces, methods, events exposed by your ActiveX control within his fake website
You see where this is going, the more powerful your control the more power Joe Hacker has in his evil, evil hands …. Sigh L

So what is the solution you ask? As tempted as I am to leave that for another day and build on the suspense … I shall not J.

This is where the SiteLock template comes in. From the download page:

"The SiteLock ATL template enables an ActiveX developer to restrict access so that a control is only deemed safe when used in a predetermined list of domains. This limits the ability of Web page authors to reuse the control for malicious purposes."

Essentially SiteLock allows the developer to define a set of website domains (or Internet Explorer Zones) that are allowed to load this control. This information is built into the control itself and each time the control is loaded, it checks the site that is loading it to make sure it is part of the white list defined by the original developer. If not it will refuse to load. In fact SiteLock can also support "expiring" an ActiveX control after a certain time period. The idea being here is that functionality present in the ActiveX control can be disabled after a certain date. Both of these measures provide risk mitigation both against malicious (innocent as well actually) repurposing of your control as well as possibly lowers risk if the control were to have an unpatched vulnerability such as a buffer overflow. It is thus an excellent example of defense in depth and risk mitigation which is easy enough to code into the system and thus there is little reason for not doing so.

For the technically inclined the SiteLock template functions by providing its own custom implementation for the aforementioned IObjectSafety – IobjectSafetySiteLockImpl. This implementation provides the magic security sauce which does all the checking described in the previous paragraph.

References:

Designing Secure ActiveX Controls

Best Practices for ActiveX Control Updates

New Version of SiteLock Template

P.S. It is important to note that what has been discussed here bears no relation to whether the control is signed or unsigned which is what Alex's post talked about. Instead it focuses on the properties of a legitimate ActiveX control. The browser will still show the regular warnings whether the control is signed or unsigned depending on how your browsing security policy is defined. It will however NOT let you know if the site attempting to use an ActiveX control is legitimate or malicious – it really has no way of doing that. So as a developer your action item is to make sure all your controls that will be hosted in a browser are protected using SiteLock. If your controls are never intended to run in a browser do not mark them as safe for scripting. Internet Explorer does not load such controls so problem solved!

If you are a end user then make sure the controls you use have this protection or hound the developers if you can until they provide this protection. In the meantime, refuse to load ActiveX controls whether signed or unsigned from untrusted websites!

OT: Passes for the Halo 3 Launch Party

rudolph — Fri, 14 Sep 2007 23:18:02 GMT

TechEd 2007

rudolph — Wed, 11 Jul 2007 20:42:00 GMT

My Virtual TechEd conversation with Mike Howard just went up on the Virtual TechEd site. Come watch a couple of software security practitioners chat about the state of the industry and where we go from here.

Some of the key things we talk about include how to sell security internally in your organization, what to expect in terms of overheads when you do integrate security into the SDLC. All in all pretty interesting IMHO.


	Silverlight Beta Installation and Setup

This is my first dabble in Silverlight too - embedding this video was pretty cool using Expression Media Encoder and the instructions here. If you dont have Sliverlight installed you probably just get a dummy screenshot above so follow the Silverlight links above to get to the video.

Marketing Security

rudolph — Sun, 01 Apr 2007 18:27:57 GMT

Well it's been a while since I last posted – no excuses but it has been a few stressful weeks – end of quarters, travel across the world and all. In any case I wanted to follow up with the general theme of security evolved that I got started last time. One of the interesting things that has happened in the last year or so is that security for some has changed from something to be ashamed of and a pain point to an advantage of sorts. Case in point is Apple which through its Mac-PC commercials appears to trump its security (among other attributes) over the competition. This is interesting for a couple of reasons in my mind. Firstly, it shows that security has stepped out of the technical echelons and made its way all the way to the marketing department (which if you believe the stereotypes is meant to be one of the clueless departments competing hard for the most clueless with the sales guys ;)). This in turn leads to the second reason. One thing a good marketing department (and whether you like them or not or whether you believe the commercials or not, you have to agree Apple has one of the best) is good at is at coming up with important reasons why customers should buy their product. This in turn implies that whatever this competitive advantage is, it is only an advantage if it makes a difference to the consumer. Now in my little mind what that means is in Apple's wisdom security is something that end users care about – and remember they are talking about primarily consumers not enterprises. From my perspective this is pretty big and it would be interesting to see or hear about the research that went into coming up with this marketing strategy i.e. how much do users care about security as an attribute, how does it compare to performance or usability etc. I would think someone at Apple has these answers and these could help answer the ever pertinent "What's the ROI for security?" or even the more basic "Why security?".

The other kind of related phenomenon is what has happened at the security conferences over the last few years. Almost every security conference that I attended or was interested in or that someone I knew attended or was interested was dominated by pretty much company – Microsoft. Microsoft was not only a major sponsor but also had employees presenting and not just one or two presentations – heck at Blackhat 2006 they had an entire track. In my humble opinion a lot of this was marketing around the release of Vista and the security advances that it brings to the table as compared to prior versions of Windows. The interesting I learned is that the Security Technology Business Unit (or whatever it is called now – given all the reorganizations) which is responsible for Windows security actually has a Marketing person. I would guess this person is tasked to a large extent with PR associated with the Patch Tuesday releases, but it wouldn't surprise me if part of the focus is also on marketing security as a competitive advantage for the Windows platform and the other Microsoft products.

Anyways just theories obviously since I have no insider information but I do think it is a interesting transition from defensive security to offensive security if I may call it that. On the other hand maybe I am reading too much into this trend…

Security Evolved

rudolph — Sat, 03 Mar 2007 22:50:12 GMT

It is interesting to see how security has transformed over the years. Back in the 80s it was pretty much that no one cared about it. Or more appropriately the only people that cared about it were the true technologists and the geeks – case in point being the Morris Worm which was primarily intended not to be a security attack but an experiment (gone horribly wrong) to measure the size of the Internet but more specifically the academic networks of the time. Then came the late 80s and 90s and suddenly security was on everyone's mind but in a weird kind of way – essentially we got caught with our pants down and this led to significant amounts of innovation (if you can call it that) and productizing that saw the birth of CERT, the first network based vulnerability assessment tool, the first anti virus software and the first network security devices. Essentially though this was as an era of a lack of knowledge i.e. there were very few "good" guys available who knew what it took to secure computer systems. It was also an era of increasing reliance on computer systems in general from health care to online banking, ecommerce, egovernment and so on… The primary reason for this lack of knowledge in my humble opinion was that it is generally regarded as a bad thing to talk about "bad" stuff. So the knowledge was thus left only in the hands of the "bad" guys!

The next era of security in my mind started with researchers and attackers alike beginning to look for vulnerabilities in released software. From buffer overflows in the 90s to SQL injection and Cross Site * today, this trend has continued. In the late 90s when people had begun to get their act together with regards to securing their networks with firewalls and intrusion detection systems, people starting exploiting vulnerabilities in accessible systems – primarily your web or FTP servers. This in turn gave birth to another slew of products – patch management! We saw first vendors arbitrarily releasing patches in response to exploits released or sometimes if you were lucky enough the exploit was released after the patch. Thus was born the entire paradigm of full disclosure – over the years this in my opinion has kept everyone honest and we have improved as community to a better system where we now see monthly patch schedules and such. This was also most likely the era when an entire career path of "information security" was created. Knowledge was now beginning to spread and in through Art of War style, it became important to understand the ways of the enemy if you were going to defend yourself. Hacking Exposed (the series but in many ways the original book) in many ways changed a lot of minds (created an entire genre I might add!) and it is probably one the biggest reasons for us at Foundstone to feel proud of the company and the people that are and have been there in the past.

At about this point vulnerability disclosures were going through the roof and vendors were truly being troubled with the lack of security in their products and applications. Releasing patches had a number of costs:

Reengineering and redoing work that was not done right the first time
Reputational costs of looking bad in public – being made fun of by your competitors etc.

This was probably one of the earliest points when simply going out and buying a piece of technology or tools (no matter what the marketing department tells you!) would not solve or eliminate the problem. It needed genuine commitment and effort from the inside in. We needed a concentrated on the people, process and technology of systems development. It took a while but companies such as Microsoft among others began investing in security throughout their SDLC processes and again if you put your biases aside for a few minutes you can see that this investment is paying off with fewer vulnerabilities and better security features in their products. Unfortunately however, this attitude was not universal and part of the reason in my opinion is that you often don't think you need something until it comes to bite you in the rear. A number of large software and hardware makers chose to completely ignore security and paid the price as focus shifted to them. Most importantly it was the companies developing line of business software and custom software that were perhaps the most lacking. But if you think about it these are also the makers of the your online backing software, your payroll system and your credit card processing systems.

Enter legislation such as GLBA and California SB 1386 and now suddenly companies had to invest into security or people got thrown into jail – important high ranking people at that! Again the tendency was to look for quick fixes – cheap and dirty. Unfortunately, such solutions rarely work for the specific purpose they are intended for but perhaps most importantly they treat the symptom and not the root cause of the disease. No effort was made to go after the systemic problems – in fact I would even venture to say people didn't see this as a systemic problem. Its only after paying the price of failing audits time and again or worse still being hacked time and again did organizations begin to turn around and see the light so to speak. However, the sad thing is many people are still looking for the quick and dirty fix – hoping a series of band-aids will cure the disease!

Fast forward to today and what are the security issues – identity theft, phishing, social engineering. Back in the 90s when you were hacked, I the attacker wanted you (and indeed the world) to know – I wanted my 15 minutes or 2 days or month of fame. Damn it! I had earned it by using my packet flooding skills! Web defacements were the ultimate rush. Today, in all my experience, attackers no longer want you to know, they want to quietly sit there and steal information, personal information, corporate secrets and national secrets – redirecting these to their databases.

What's the one common trend through all of this? We have always been reactive – following the attackers and their techniques. What are we doing to defend ourselves against this next wave of attacks? Are we truly anticipating and getting prepared? Do we even know what the next type of security issues are going to be? Are we building securable systems? Or are we waiting to evolve and innovate? Someone once said those that don't learn from history are doomed to repeat it – perhaps we in the security community should learn something from our pasts and security in general (outside of information systems) so that we are one step ahead next time instead of hundreds of steps behind.

Mirror, mirror on the wall which is the securest of them all?

rudolph — Wed, 07 Feb 2007 06:50:30 GMT

All too often I get asked questions such as:

Which is more secure Microsoft Windows <Put your version of choice here> or Apple Mac OS <Pick your version here>?
Which is more secure Internet Explorer or Firefox?
Are two tier architectures – where my database is accessible from my web server in the DMZ less secure than a three tier architecture where all database access goes through a middle tier?
…

Much debate along these lines has been seen recently with the public consumer release of Microsoft's latest OS offering in the form of Vista. The Microsoft bashers will point to the fact that Vista already has unpatched vulnerabilities and it has barely been released. On the other side of the spectrum, a lot of Microsoft marketing and a number of security experts will tell you that security was the number one feature in this release and that is precisely why you should upgrade. I would almost be willing to bet that for all the experts you will find that would be willing to put themselves on a life support system hooked up to a public wireless network and running on Windows Vista, you would just as many that would refuse to do so unless the operating system is Apple Mac OS X.

So what is the correct answer? Which "experts" does one as a consumer believe? Well I decided to look at some of the statistics that people like to throw around as backing data for their arguments. Secunia.com is a wonderful site at times like these – and if I assume (and perhaps wrongly so – but I think we can for argument's sake) that they are the one and only definitive source of vulnerability tracking on the planet, then the numbers below can be trested as absolute. Before I go further though, I want to extract a promise from you the reader, irrespective of what side of the fence you sit on – don't assume I am on one side or the other at least until you get to the end of this blog post (I promise there is a method to my madness and the wait will be worth it J).

Ok let's talk about pure numbers since numbers don't lie some would say. Consider this:

or perhaps this

From the looks of these statistics it would appear that Microsoft has had 43% more vulnerabilities in their Windows XP Professional offering as compared to Apple Mac OS X. And you can take that number and write article after article and post after post claiming Microsoft is a lot less secure than Apple. But then someone will turn around and say Microsoft has got their act together in recent times and have invested a ton of money into security (which they have) and offer something like the following as evidence:

vs. this

But I wonder if the Month of Apple Bugs had something to do with this?

And then off course you have those that say well this isn't even an argument worth getting in to because I run on IBM OS/400 which is by far the most secure operating system on the planet while offering something like this as evidence.

Well, try telling to that to the one administrator of an AS/400 machine that fell victim to the one vulnerability that was patched in November of 2006.

Hopefully you see my point now, numbers by themselves are meaningless as are how many patches are released on Patch Tuesday. The reason this is so because each vendor (Microsoft and Apple in this case) has their own risk assessment methodology and patch release process. While Microsoft tends to fix single issues per patch / advisory, Apple on the other hand will tend to bunch up a number of fixes into a single "patch". While one can argue for a more standardized approach, at a high level I don't have too much of a problem with either approach. What I care about is that patches get issued, and vulnerabilities get fixed.

So that really brings me to the main point of this post which is whether it even makes sense to talk about numbers like these and get into heated debates about whether X is more Y? In my opinion the main problem with numbers is that unless they are taken in context they can be made to say whatever the presenter wants them to say. Hopefully the examples above have provided some evidence of this.

I think the question we should be really arguing about is which of X or Y is more securable. There is a huge difference in my opinion about someone saying their operating system or application or browser is more secure and saying it is more securable. If you look at the most common types of attacks these days that go after end-consumers if it is things like phishing and identity theft. In light of this what I as a consumer care about is what operating system / application / browser makes it the easiest for me to protect myself and the hardest for me to shoot myself in the foot which I will inevitably do. That is my definition of securability.

So with that said let's talk about securability – I think Mac OS X and now Vista both have capabilities and features that make them far easier to secure than their predecessors – an example being not running everything as an administrator or user account control (UAC). I think by itself will help alleviate the "I shot myself in the foot" problem to a large extent. Off course I think there will be vulnerabilities and I absolutely do not think that a year from now the graphs for either operating system on Secunia will be empty. The reason for that is it is not an easy task to get rid of every buffer overflow or every format string vulnerability. What you can do is mitigate the risk – compile your code with stack protection, run with least privilege, use default deny and so on. I think to a large extent the major software vendors and certainly from what I can see – both Microsoft and Apple have seen the value in doing this and will continue to do this. But in code bases with that many lines of code (50 -60 million from what I hear but who's counting J) there are bound to be mistakes that have been made, oversights and just things done which at the time they were done were completely correct but security research has evolved and will evolve to prove those very things to be huge vulnerabilities.

So are we all done then – we cannot get any better? Well not really, I think the next thing to get right is to chop privileges down even further. Sure we have made it harder for malware to install a kernel mode key stroke logger on our machines but how about that phishing site or that JavaScript which runs in the background or that email client which receives an email containing a malicious script that reads my confidential files. I think that is where the next evolution of software security should be going. How can we create true application sandboxes (and I know this word has been used and misused multiple times) which restrict what an application can and cannot do based on only what they need to do. We have attempted to solve the security problem of an attacker damaging the underlying machine and the infrastructure (operating system, applications etc) but how about preventing an attacker from hurting the user him / herself. How about preventing my email client or my browser (even if these are running min my context or heck in the context of the administrator himself) from accessing my Microsoft Money or Quicken files unless I the user explicitly allow that access?

Well for my thoughts on a more concrete basis – stay tuned. To be continued ….

Full disclosure: I am a Microsoft Developer Security MVP and receive a number of benefits from Microsoft as a consequence. However, this post has nothing to do with that relationship or the benefits. I would like to think I was and am completely unbiased. I should also mention that I also am an owner of both a Mac and a PC laptop on personal level but do use primarily Windows for work.