Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Security Programming Software Windows

Many Popular Windows Apps Ignore Security Options 202

eldavojohn writes "The latest versions of Microsoft Windows have some good security options available — now if only they could get their most popular third-party applications to use them. A report from Secunia takes a look at two such options — DEP and ASLR — and Brian Krebs breaks down who is using them and who is not. A security specialist noted, 'If both DEP and ASLR are correctly deployed, the ease of exploit development decreases significantly. While most Microsoft applications take full advantage of DEP and ASLR, third-party applications have yet to fully adapt to the requirements of the two mechanisms (PDF). If we also consider the increasing number of vulnerabilities discovered in third-party applications, an attacker's choice for targeting a popular third-party application rather than a Microsoft product becomes very understandable.' Among those with neither DEP or ASLR: Apple Quicktime, Foxit Reader, Google Picasa, Java,, RealPlayer, and AOL's Winamp. While Flash player can't implement DEP, it does have ASLR. Google Chrome is the only popular third-party application listed with stars across the board." It's worth noting that several apps highlighted in the Secunia research paper have added support for those security options in recent patches, or are in the process of doing so. Examples include Firefox, VLC, and Foxit Reader.
This discussion has been archived. No new comments can be posted.

Many Popular Windows Apps Ignore Security Options

Comments Filter:
  • Re:Wait a minute (Score:4, Informative)

    by Ironchew ( 1069966 ) on Saturday July 03, 2010 @02:00PM (#32787006)

    Because third-party developers can write whatever code they want to.

    There is a registry setting that forcibly enables ASLR for all executables.

  • Re:Wait a minute (Score:3, Informative)

    by seibai ( 1805884 ) on Saturday July 03, 2010 @02:05PM (#32787032)

    Because enforcing that every application use these would mean certain sorts of applications couldn't be written (or at least not as easily).

    DEP is data execution prevention. It marks certain areas of address space as being "data only", so the processor won't execute them. While this is generally a good idea, as it prevents a hacker from constructing a NOP sled and then using an access violation bug somewhere to execute code they've stuck in memory, it also has the side effect of making self-modifying code more difficult to write.

    ASLR (address space layout randomization) is similar, as it breaks certain sorts of odd programming techniques like arithmetic variable addressing.

  • Re:Wait a minute (Score:4, Informative)

    by guy-in-corner ( 614138 ) on Saturday July 03, 2010 @02:27PM (#32787166)

    Also, the DEP setting is opt-in on workstation SKUs (your app has to say that it wants it) -- for compatibility, and opt-out for server SKUs (your app has to say that it doesn't want it) -- for security.

  • Re:"app" (Score:1, Informative)

    by Anonymous Coward on Saturday July 03, 2010 @02:27PM (#32787168)

    It's too late. Apple started it, and now the rush is inevitable. I saw someone on lkml call a program an 'app' the other day - there is no more resistance.

  • by hitmark ( 640295 ) on Saturday July 03, 2010 @02:27PM (#32787170) Journal

    DEP sounds similar to what simcity did back in the dos days, use memory after it had freed it. Funny thing is, microsoft made sure that if windows detected a dos binary named simcity do that, it would allow it. This to maintain backwards-compatibility.

    and i suspect this is also why DEP is made optional pr program, as there may have been some lazy code written back in the day thats still in use somewhere.

  • by pavon ( 30274 ) on Saturday July 03, 2010 @02:29PM (#32787180)

    No, for most applications it wouldn't have much impact on the code base to implement these changes, especially compared to the other changes in GUI, Networking, IPC, and other system libraries that they already have to maintain.

    The two features are both about preventing memory access errors from turning into exploits. The only apps that need to be changed before enabling DEP are ones that do some sort of JIT compilation of code into data memory and then execute it - and even these apps can enable DEP if they allocate memory for this compiled code using a windows specific api that marks it a executable. The only apps that will run into problems with ASLR are those that hardcode memory locations. No one should be doing this and a cross-platform app definitely won't be.

    So it isn't a big deal for cross-platform applications, they probably just haven't spent the time to investigate all the ins and outs of MS's features, since they aren't native to that platform. I know I haven't on my in-house applications; I probably should.

  • by hitmark ( 640295 ) on Saturday July 03, 2010 @02:30PM (#32787182) Journal

    or hired guns pulling black ops missions on the people writing the malware.

  • by yuhong ( 1378501 ) <> on Saturday July 03, 2010 @03:09PM (#32787430) Homepage
    Not to mention that all of these these features are themselves cross-platform too. Linux had NX support since 2.6.8 released right around the release of XP SP2 (in around August 2004) for example, it was just that most distros was not enabling it because they were defaulting to non-PAE kernels. What made it worse was Intel made the mistake of releasing Pentium Ms without PAE in 2003 and 2004. They had to finally add PAE in order to add NX to Pentium M which was done at the beginning of 2005 but by then it was too late. Mandriva tried to default to PAE kernels back in 2005, but was forced to back off after that mistake was discovered. Ultimately Ubuntu and Fedora added auto-detection to their installer last year, finally installing a PAE and thus NX capable kernel on capable processors.
  • Re:Wait a minute (Score:5, Informative)

    by TheLink ( 130905 ) on Saturday July 03, 2010 @03:12PM (#32787446) Journal

    > I know that under FreeBSD and Linux applications are expected to run with the provided resources unless they're specifically run as root or similar.

    DEP and ASLR are all about making it harder for stuff like say Mozilla to be pwned. Not really about resources.

    You can force DEP to be on for everything on Windows: []
    But if your favourite app crashes badly, hope you know how to exclude it.

    The trouble is if Mozilla is pwned, and runs "arbitrary code of the attacker's choice", that code can do anything that user account can do, and access anything that user account can access. This is true for FreeBSD, Linux and Windows.

    Just because I run a browser doesn't mean I want to allow it full access to whatever my account can access/do.

    Windows Vista and Windows 7 actually sandbox IE, so in fact Windows is one up on most major Linux distros in that respect.

    I've seen the default apparmor template for firefox on ubuntu. 1) It's not enabled by default, and 2) Even if you enable it, it doesn't really help if you want security, you have to modify the template if you want to protect all your nonbrowser-related files from a pwned browser instance.

  • by Anonymous Coward on Saturday July 03, 2010 @03:39PM (#32787606)

    None - ASLR affects the initial base location where various program sections are placed, so code & data locality remains the same relative to each other.

  • Re:Wait a minute (Score:5, Informative)

    by mlts ( 1038732 ) * on Saturday July 03, 2010 @03:52PM (#32787674)

    There is a balance between a walled garden and complete anarchy. Right now, Windows programs are such a poor quality level because they can get away with it. It is SOP in the Windows arena to ship alpha or beta code, call it a release, then fix it after launch, if ever. Most of the time, bugs end up given a "FNR", or fixed in next release status.

    When Vista came out that added UAC for basic security, and the screaming of app developers whining about not being able to have all their code have Administrator privs by default, was unbelievable. In that time, Apple changed architectures and even though there was a tad of griping, it was not this hand-wringing that was observed from the Windows camp. Similar when something changes under Linux that forces program developers to change course. Similar with drivers in Vista. I know of more than one company which shipped broken drivers deliberately and pointed the finger at Microsoft when things crashed, as opposed to actually writing production quality code.

    I'd like to see a compromise between the two extremes: First, applications that manage to pass a code quality review get a certificate. Second, have a rule that Authenticode-signed programs adhere to some code quality guidelines. Failure to do so gets the cert revoked. This way, programs install as normally. Finally, Other programs that don't do either of these wind up in a virtual machine, completely isolated from the main OS and the app windows they put up are clearly marked as coming from an untrusted application, similar to untrusted applets in Java's sandbox.

    Microsoft has to both address being able to handle legacy code, and be able to keep a hand on lazy developers who will do the absolute minimum it takes to ship, even if means ignoring every security guideline out there. This is what virtualization is for -- Allow well behaved apps, and companies who agreed to code quality standards to install on the OS, while the legacy stuff can go play at the kiddie table in an encapsulated VM. Of course, if someone wants to drop a self signed cert in for their code as they are developing it, or a company wants to write code in-house and wants their CA to be trusted for code revisions, they can feel free to do so.

  • Re:DEP yes, ASLR no (Score:3, Informative)

    by benjymouse ( 756774 ) on Saturday July 03, 2010 @04:14PM (#32787794)

    You really need a mandatory security model like SELinux to make this work, and Windows doesn't have that.

    Oh? Since Vista, Windows can run executables in "low integrity mode". When a low integrity mode process is started, the security token of the process (which is inherited from the user) is stripped of all admin privileges, stripped of write access to anywhere but a designed cache area and barred from making changes to the registry.

    Basically, Windows allows a user account to be sub-divided based on the activity the account is used for. If it is a potentially internet faced activity the app should use low-integrity mode. That *is* a jailed sandbox. In fact, it is so restrictive that for an app such as IE (or Chrome) to allow files to be downloaded, a separate "helper" or "broker" process must be used. IE comes with a standard process for that. If a plugin (or ActiveX control (shudder)) needs to download a file, it must enlist the help of this process. It is in fact this process which displays the download dialog, meaning it is very, very hard to sneak files on to a user's system through IE, Chrome or other sandboxed apps.

    To do so you will have to explore some a in a process which already runs outside the sandbox - e.g. in IEs broker process (no example of that yet) or in Flashs' own helper (one example of that in pwn2own 2008).

    One interesting twist on the low integrity mode is that usually processes (apps) running under the same account in the same session (i.e. interactively logged on) can "talk" to each other by sending messages. Which means that Excel can send messages to Outlook. But a lower integrity process *can not* send messages to a higher privileged process.

    Office 2010 now also uses a low integrity process to view "unsafe" documents. Unsafe documents are documents received from the internet or through mail (the receiving app writes a note of the origin to an alternate datastream).

    Firefox is the laggard here. Chrome and IE already uses Windows low integrity mode to sandbox the browser session. Chrome takes steps to further reign in its process. This means that despite the fact that Chrome has had more vulnerabilities discovered (webkit) than IE through the latter years, it would be *very* hard to exploit those. Firefox not so much. It actually has a worryingly high number of vulnerabilities - many more than IE. And they (at this time) has no sandbox. The separate process for plugins is still not sandboxed. The only thing Mozilla has going for them at the security front is that they seem to be among the fastest patchers.

  • Re:Java? (Score:2, Informative)

    by BitZtream ( 692029 ) on Saturday July 03, 2010 @04:40PM (#32787952)

    You simply have to ask for memory that doesn't have the NX bit set when requesting a memory allocation.

    Translation: You don't call malloc(), you use VirtualAlloc with the right flags. Then you get a block of memory back that can be executed.

    Either way, with interpreted languages, there is no requirement to be able to directly execute the memory. The interpreter is the executing code, reading and basing its execution path based on what the 'compiled' java byte code looks like. Java doesn't compile to native code so theres no reason to need memory without the NX bit.

    Of course, it has become common practice to JIT compile the java byte code into native code for performance increases, and thats where you'll need memory that can be executed, but all you have to do is ask for it from the OS.

    Emulators and x86 Hypervisors are a good example of uses of memory that needs to be allocated without the NX bit set so it can be directly executed because they try to run the code directly otherwise performance would suck ass.

    Either way, the 'special mechanisms' that the CLR uses are available to everyone and have been since before the .NET runtime existed.

    People have been able to 'do the right thing' in regards to DEP for at least the last 10 years in Windows.

    As far as Java being 'safe from'. This is simply a side effect of the nature of Java. Some of it intentional and a good thing, some of the effects were unexpected, and some of those are good and some are not so good, but thats mostly an issue for debugging bugs in the JVM.

  • by pavon ( 30274 ) on Saturday July 03, 2010 @04:46PM (#32787984)

    No DEP only prevents execution on memory that is not marked executable. Enabling DEP marks all memory as nonexecutable by default, but you can use the VirtualAlloc [] function in windows to allocate memory that is marked executable. This allows for the implementation of JIT compilers even with DEP turned on.

  • DEP isn't really similar to that at all. That was a case of misusing a memory manager, which is bad behavior and can cause security holes, but doesn't really count as failing to use a security feature. DEP - Data Execute Protection - does just what it sounds like: it prevents the data (stack and heap) of a program's memory representation from being executed. More specifically, if the instruction pointer tries to move to a page of memory that has the NX (No eXecute) bit set, it throws a hardware interrupt and the OS kills the program (and pops up a warning). The idea is to prevent somebody from injecting binary instructions - a shellcode - into a memory buffer and then overwriting a return address or similar to execute those instructions. The overwrite can still work, but because the instructions are in a data page, not a code page, the exploit will fail.

    The problem is, a lot of programs - especially those that execute any kind of code, such a JavaScript in Foxit or ActionScript in Flash - use executable code in data pages legitimately, and intentionally call into it. The CPU doesn't know the difference, so those programs get killed too. The OS *can* know the difference - you can set exemptions for specific apps in Windows - but adding such an exemption just turns of DEP for that program entirely.

    Side note: if you're willing to deal with figuring out which of your apps are DEP-compatible but don't have the flag for it set, you can change Windows default behavior to use DEP unless instructed not to. In fact, you can tell it to use DEP on everything, regardless of exemptions, but this is likely to make some apps get killed by the OS. I run with DEP set on opt-out, and aside from a couple of apps (StarCraft, for example... not sure why) that were incompatible but too old to include the flag saying so, it's worked out well.

  • Re:Kernel, not apps (Score:3, Informative)

    by cbhacking ( 979169 ) <.moc.oohay. .ta. ... isiurc_tuo_neeb.> on Saturday July 03, 2010 @05:42PM (#32788300) Homepage Journal

    First of all, DEP is technically a kernel feature, or at least parts of it require kernel support. MS even wrote a completely software-based feature that tries to implement DEP on systems without the NX bit (it's not perfect, but it helps a bit).

    Windows has 4 settings for DEP enforcement:

      * Turn it all off (generally not used, unless you have a misbehaving driver). This option is only available if you know where to look; it's not in the UI
      * Turn it on if a program opts in (most MS software does, and some third-party code as well). This is the default on client versions of Windows (XP, Vista, 7)
      * Turn it on unless a program specifically opts out or an Admin added an exemption (a few apps currently opt out, a few others will crash unless you add the exemption). This is the default on server versions of Windows (2003, 2008, 2008 R2)
      * Turn it on for everything, regardless of what the program wants (some software will crash, not much you can do except not run that software). This option is only available if you know where to look; it's not in the UI

    I recommend changing the setting on your box to the third option. Computer Properties -> Advanced -> Performance -> Data Execution Prevention -> Turn on DEP for all...

  • by n0-0p ( 325773 ) on Saturday July 03, 2010 @05:42PM (#32788302)

    There's nothing wrong with installing a program in the Application directory; it's pretty much the norm on Windows for per-user installations. Think of it as equivalent to ~/bin on Unix systems. Of course that doesn't fit in well for enterprise environments, but Google does provide a pack installer for managed systems, [] which installs under "Program Files" and lets you disable auto-updates. And while the current version of Chrome is lacking other enterprise features, the next version will have full support for GPO configuration, Admin templates, and all the other things you'd expect in an enterprise.

    As for your absurd claim that per-user installations are somehow a security vulnerability, you're going to have to provide something to back that up. Because I've spent about 15 years in the information security field I can't even get close to a rationale for that one.

  • Re:Java? (Score:3, Informative)

    by bertok ( 226922 ) on Saturday July 03, 2010 @08:40PM (#32789244)

    No, they just designed .NET to always execute fully compiled. Unlike Java, .NETs "intermediate code" was never intended to be interpreted at runtime. Instead .NET JITs an assembly (dll) before executing. .NET even supports creating assemblies dynamically (no hacks) through Reflection.Emit (no need to save to files and do bytecode manipulation). A dynamic assembly is still compiled fully to machine instructions before execution begins.

    I was just reading the .NET 4 help file on this this week, and the JIT compiler is invoked on a per-method basis. The virtual function table is used to substitute the compiled methods for the original bytecode.

    One difference between .NET and Java is that .NET invokes the JIT on the "first call", whereas Java still prefers to run code using emulation until a method has been called a certain number of times, after which the JIT is invoked. You're almost right: .NET never executes anything other than compiled code, but the compilation is done in smaller increments than a whole DLL!

    The program installer has to explicitly invoke 'ngen.exe' to trigger a full compilation. Lots of programs do this. You can tell because the installer takes forever to run even with fast drives (e.g.: SSDs), and the CPU sits at 100% for a long time...

  • by LO0G ( 606364 ) on Sunday July 04, 2010 @11:26AM (#32791956)

    The kernel did enforce the flags as best as it could. But the processor didn't allow you to have a writable page without the X bit until the 64bit extensions for x86 were designed by AMD []. Once processors were available that supported the NX bit (some time around 2004), the OS was modified to support it.

    The scandal is that its' been 6 years since that time and apps still haven't caught up with the change.

Things equal to nothing else are equal to each other.