Many Popular Windows Apps Ignore Security Options

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, OpenOffice.org, 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.

Wait a minute

[Anonymous Coward]

Why doesn't Windows enforce it's security?

Adobe's problem

[ILuvRamen]

Somehow I think that adding both of those options to anything Adobe makes wouldn't make an ounce of difference. They first need to patch that whole "putting features and pretty design before security" thing.

Re:Wait a minute

[Anonymous Coward]

Why doesn't Windows enforce it's security?

Because they write the OS and do not dictate what you can run on your box?

Or do you want your windows apps to only come from Windows Application Store?

"app"

[Anonymous Coward]

Can we please stop calling everything "apps" and go back to programs. App is getting to be as annoying as blog.

Re:Wait a minute

[hedwards]

You mean despite the fact that other OSes enforce the security model on all the applications that expect to run on it? 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. I'm not sure I understand why MS would allow third party apps to do so without having the user make adjustments themselves. Ultimately this is MS' fault for allowing in the first place.

Re:Wait a minute

[0123456]

Because then 90% of old Windows apps won't run and since people only buy Windows to run Windows apps, they get pissed off.

It's bad enough with 64-bit Windows 7 where many games require hacks and workarounds or simply won't run at all in the case of old 16-bit games. I only use Windows on my laptop for games and video editing and given the incompatibility issues I'm not sure it's even worth bothering; the average older game seems about as likely to run in Wine as Windows.

Microsoft are screwed because they've allowed such bad programming practices in the past that they can either block them for security and have millions of users beating down their door because old apps no longer work, or they can allow those bad practices to continue so Windows remains an insecure piece of junk.

Re:Wait a minute

[X0563511]

Some would argue that programming this way is broken to begin with...

Authenticode for free software?

[tepples]

[Programs not signed by a commercial code review agency] 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.

Then any program that doesn't have a commercial entity behind it would have to run in the sandbox. For example, a lot of free software [wikipedia.org] for Windows lacks Authenticode signatures because many individuals who maintain free software in their spare time don't want to incorporate ($100 or more depending on state) in order to become eligible for an Authenticode certificate and then keep the certificate up to date ($179.95/year [instantssl.com]).

Re:ASLR possibly degrades performance?

[cbhacking]

None, really. ASLR doesn't mean that every single instruction winds up somewhere random, it just means that when loading a file of executable code - either a program or a library - it places the in-memory representation at a random address. This means you can't, for example, do a return-to-libC attack by simply figuring out the address that your target platform places its C runtime at; it will instead be different on every system and every day. However, within any given binary, the relative locations of instructions are unaffected. Net result: code locality is almost entirely preserved, but exploits get a lot harder.

Re:Wait a minute

[mysidia]

Well, they could remove the ability to opt out of DEP for an application, then the apps would have to adapt or stop working.

It's backwards compatibility features that are being used, and conspire with current developers to hose new Windows security measures.

Apple doesn't just make Mac OS X

[tepples]

Apple doesn't allow unsigned programs to run at all.

Since when has Mac OS X Snow Leopard blocked the use of unsigned or self-signed software on the Mac?

Popular open-source projects that would like a certificate can petition their users for donations

If a program has to be signed to be useful, such as if it has to be signed just to be able to open the documents that the user chooses, then how can the program become popular in the first place?

Re:DEP yes, ASLR no

[mpe]

While DEP does prevent stack overflow types of attacks, it also complicates writing high security software. The inability to execute data means:


1. You can't run self-decrypting programs.
2. You can't alter instructions at runtime to fool debuggers.
3. You can't place keys in executable code sections at runtime, making it much easier for someone to stop your program and dump the keys out of the memory image.
DEP actually makes attacks against cryptographic software *easier* to implement.

How often does regular cryptographic software need to do any of these? Points 1 and 2 involve self modifying code. Self modifying code is a good way to create a complete lack of any secuity. If order for software to actually be secure it needs to be verifiable that it operates according to the algorithm, this means avoiding both obfuscated and self modifying code. Even then small details matter, e.g. the Debian "bugfix" to SSL which reduced effective keyspace by orders of magnitude.
All of the points only really apply to situations where programmers don't understand the basics of encryption (which predate electronic computers by several hundred years) especially well or where encryption is being used (hacked) for a task it isn't especially suited to in the first place. e.g. DRM (Where "Bob" and "Eve" are the same person...)