Could DEP hall passes for scriptable apps increase system vulnerability?

Could DEP hall passes for scriptable apps increase system vulnerability?

Summary: 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.


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.

Topic: Apps

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Solaris, BSD, and Linux support it too

    Solaris 10, Linux, and BSD supports the NX or XD bit as well. It was interesting that Solaris' method of dealing with DEP compatibility issues in any application is to turn off DEP protection entirely.
  • "No APIs until software works" is the only solution

    Mr. Berlind makes some great points here. Even the most secure software is at risk when developers are not coding properly. This is why I propose "No APIs until software works".

    The sad fact of the matter is, many, if not most, of the security risks out there are directly related to what happens when you expose part of your application to other applications. Look at Outlook and Internet Explorer; most of their security problems stem from ActiveX, which is an API that leads directly to the OS. The problem isn't with the OS, it is with the API, the middle layer joining the two.

    It is pretty easy to write an application that verifies input from itself; writing APIs that account for whatever mistakes or problems that another piece of software passes to it is an entirely different subject. For example, it is easy to write a web page with a piece of code on the server, and have the web page (via JavaScript or whatever) verify that the input meets certain requirements. However, the moment someone directly passes data into that server via an HTTP GET or POST, your server-side processing is going to go haywire, because you assumed that the validation was being done on the client side.

    This is (yet another) reason why I am so down on AJAX and Web 2.0. It is altogether too easy to use cool tools like Visual Studio that do 90% of the work for you, and forget to write quality code. In addition, you are exposing so much more of your program's functionality to the outside world like this. There is a demonstrated lack of good programmers in this world as it is, the last thing we need is a trend that multiplies the dangers of poor programming.

    Justin James
  • DEP and VirtualAllocEx / VirtualProtectEx

    DEP prevents normal memory from being executable on processors that support this feature. Older x86 processors can only mark memory read-only or read-write, while newer processors have an extra bit to flag pages as executable.

    Windows NT (since NT 4) has required that programs that put executable code in dynamically allocated memory mark the memory pages that they allocate as executable, using VirtualAllocEx and VirtualProtectEx. This was needed on other architectures at the time, too. This snippet is from the MSDN docs for VirtualAllocEx:

    To execute dynamically generated code, use VirtualAllocEx to allocate memory and the VirtualProtectEx function to grant PAGE_EXECUTE access.

    If Skype needs DEP disabled, then that is due to the ignorance or incompetence of the Skype programmers, or the same of some library they are using. This ignorance isn't rare: the MS programmers of early versions of the .NET CLR committed the same mistake.

    Does disabling DEP decrease security? Yes: if there are buffer overflow problems in Skype, they could be exploited by using this flaw.
    • Old stuff

      I mentioned this myself in an answer on the Borland newsgroups more than 5 years ago:*&_done=%2Fgroup%2Fborland.public.delphi.basm%2Fbrowse_frm%2Fthread%2Ff2a353ccd980c40d%2F3da96f8795953f92%3Flnk%3Dst%26q%3Dbarry+kelly+VirtualAlloc+group%3Aborland.public.delphi.*%26rnum%3D1%26hl%3Den%26#doc_69d032ad7c636a03