Slashdot Mirror
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.
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.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
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?
Because third-party developers can write whatever code they want to.
There is a registry setting that forcibly enables ASLR for all executables.
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.
Can we please stop calling everything "apps" and go back to programs. App is getting to be as annoying as blog.
Just enforce the DEP and ASLR system wide and see what breaks. I personally couldn't imagine doing anything else. Few clicks and that's it.
I guess it's a matter of perspective...
Insomnia Sec's SyScan presentation on defeating DEP [PPT warning]
Google cache HTML-ified alternative to the PPT
It may well be that DEP's useful days are numbered. It's likely just a matter of time before these techniques are better researched, more widely understood and commonplace.
As always, the best defense is in depth, responsible disclosure, and patching, patching, patching.
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.
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.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
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.
Data execution prevention is a no-brainer. Unix has had that since the 1970s.
ASLR, though, is iffy. Randomizing the position of code in memory is a form of security through obscurity. If there's a bug that's exploitable with ASLR, it's a bug that can crash the program without it. It also makes debugging harder. No two crash dumps for the same bug are the same. Not even close.
What's more useful is running applications with very limited privileges. If the browser's renderer can't do much except render the single page it's supposed to be rendering, then corruption within it isn't a big deal. Firefox's approach to running plugins in a separate process is a big step forward, and the more jail-like that process becomes, the better. You really need a mandatory security model like SELinux to make this work, and Windows doesn't have that.
Modern machines rely heavily on cache for efficiency, and thus code and data locality. I wonder what effect ASLR has on this.
"His name was James Damore."
Microsoft also added, "If only those applications would use our special memory access functions, they wouldn't go overwriting other programs' memory. There's nothing we can do at the OS level to prevent this, so it's up to application developers to do the ritght thing."
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.
> 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: http://support.microsoft.com/kb/875352#5
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.
because Its PDF and I don't know if my Adobe reader has DEP so I'm afraid I'll get hacked..... /s
I'd be a bit surprised if Java could take advantage of either of these mechanisms due to the nature of the dynamic compiler and class-loading, without major, major problems. MS probably had to build special mechanisms into the CLR runtime for it to work in .NET.
On the other hand, Java has a reputation of being a pretty bulletproof platform in terms of the exploits that these two mechanisms are designed to protect against.
Some would argue that programming this way is broken to begin with...
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
Managed execution environments, such as .NET and Java, usually recompile each method as it is executed for the first time. In a DEP environment, the JIT recompiler needs a way to tell the OS to flip parts of memory between data and executable. So if "some" argue that managed code is broken by design, I'd guess "some" work for Apple's iOS division, the only company I can think of that has explicitly banned managed code.
[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 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).
DEP should be handled by the operating system, not the apps. This is the philosphy which has made Windows such a mess over the years.
I want to delete my account but Slashdot doesn't allow it.
...when it installs itself, in Windows, at %Userprofile%\Application Data\Google Chrome? That is just amateur programming, and is a real beast if you're in an Active Directory environment with Roaming Profiles, 'cause the damn software keeps getting copied to/from the server with ever logon/logoff. I understand Google might consider compliance with separation of programs from their data might be "difficult," but the ease with which any malmare can corrupt Chrome because of it's lack of installation security make Chrome a pariah in our environment, and I've banned it from all our and client computers!
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.
There's no place I could be, since I've found Serenity...
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 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?