Could DEP hall passes for scriptable apps increase system vulnerability?

Yesterday, my fellow ZDNet blogger George Ou provided a great series of screenshots of what happens when a widely used commerically available application (in this case Skype) triggers the Data Execution Prevention (DEP) feature (as it did) in Windows XP SP2.  This feature which depends on the newest breed of processors from Intel and AMD as well as corresponding support from your operating system (XP SP2 supports it as will all future versions of Windows), is designed to stop certain types of malware -- particularly the type that relies on the oft-maligned buffer overrun technique -- dead in its tracks.  Activation of DEP protection in Windows is optional but it is recommended in situations where most software will run while the feature is turned on. 

The problem, as George discovered, is that some legitimate software uses the aforementioned technique as well.  This could be by accident or on purpose.  I won't know until I hear back from Skype.  But, in terms of George's user experience (where he has DEP activated), Skype was not allowed to run until George gave it a hall pass.  Going back to the introduction of DEP, the OS and chip vendors knew its introduction would cause glitches to legitimate software and drivers. 

Microsoft was very smart when it did two things.  First, it made its Visual Studio software development tool more DEP-aware.  This way, developers of legitimate software could more easily develop applications that respected the DEP feature.  Second, it made it possible for end-users to issue a hall pass to legitimate software like Skype.  These two measures taken by Microsoft basically bought time during the transition period (the period we're in now, where software developers must update their software).  It gave developers a way to make sure there existing software was viable until they got updated software to market.  It gave end-users a way to take advantage of an important security feature without breaking all their applications.

But now comes another very important question.  Suppose an end user like George gives a legitimate application like Skype the hall pass it needs to run.  Now suppose that that third party application has application programming interfaces (APIs) that make it scriptable by third party developers (as Skype does).  By giving that application a hall pass, are end-users unknowingly giving third party developers access to that hall pass (and a system vulnerability) as well? 

Picture this.

Now, thanks to George's blog, it's common knowledge that some Skype users will have to issue a hall pass to their Skype installation in order to circumvent DEP protection.  Let's say you're one of those users and tomorrow, you get an e-mail that portends to be from Skype that notifies you of the problem and gives you some instructions to follow to repair your Skype installation.  Let's say that e-mail isn't from Skype and instead, it's from a phisher that's trolling his email lists looking for unsuspecting Skype users using a very legitimate looking e-mail (one that bears Skype's logos, appears to use email and Web addresses belonging to Skype, etc).  Is it possible for that phisher to social engineer Skype users into loading malicious code that takes advantage of the aforementioned hall pass?

To get the answer I contacted Skype, Microsoft, Intel, and several security analysts.  So far, the only one to get back to me has been Intel (a good company to check with since its chips support the DEP feature).  According to Intel spokesperson Bill Kircos, the situation is even worse than it originally seemed.   "The scripting thing is a red herring" said Kircos. "An application doesn't have to have APIs in order for it to be exploited.  So, this is a problem either way." Kircos did however agree that the availability of APIs might make exploitation easier.  I'm still waiting to hear back from the other companies.  Microsoft and Skype are checking into the issue.  None of the security or hardware analysts I've contacted have gotten back to me. If you know something, feel free to use the comments section below.  One thing though; while it's a problem for Microsoft anytime one of its customers is vulnerable or becomes the subject of an exploit or a hack, this is really a time where Microsoft has installed a very effective security measure and now it's up to software developers to comply and to end-users to proceed with extreme caution when allowing their applications to work around Microsoft's road block.