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.
Why doesn't Windows enforce it's security?
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 should this be up to an application at all? You either have a secure install or you don't, if you do, then no application would have the authority to run outside of the rules, if you don't, you have to acknowledge it as a user and force the OS not to bother forcing this.
It's FIRST: User's choice. Second: OS enforcement. Distant third: what an individual application is doing.
So if the user says: Enforce, then all calls to OS routines to allocate memory for example must be rerouted by the OS through this memory randomization thing and OS must force certain memory to be for execution and the rest to have the 'no-execution' bit set. OS should be able to make any application into a compliant one, so what's the deal?
You can't handle the truth.
You can enable DEP on Windows and still allocate executable memory. You just can't to get it from malloc(). This feature is needed so little that it should be a pretty trivial amount of modifications to get code working. It's probably not that they can't, but that they simply won't because it's too low a priority compared to the next big shiny feature.
VLC uses both DEP and ASLR in the latest VLC 1.1.0.
The blog is a rewrite of a blog from Secunia who is testing an old version of VLC...
They can't even spread their "security fear" correctly...
Can we please stop calling everything "apps" and go back to programs. App is getting to be as annoying as blog.
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.
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.
Depends on what the specifics of the code are. That's usually the responsibility of a library to deal with, you can also use ifdefs in languages like C if you have to, but generally speaking the ideal cross platform code will segregate platform specific code from the rest of it.
Every app can be forced to use DEP and ASLR. Its a Windows setting, not an app setting.
Apps can choose to make themselves fall into those categories or not for compatibility reasons, but the sys admin can most certainly force both on for all applications. Windows controls
Second whoever said 'flash can't do DEP' needs to stop injecting their ignorance into the conversation. Thats roughly the same as saying no web browsers can do DEP, and that the C#/VB/*.NET compilers can't produce DEP compatible output. The only thing even close to a problem is the scripting, which doesn't actually present a problem unless you're using crappy hacks from the 70s main frames in order to make it work a little faster. Of course, they could just use the right API call so they can dynamically allocate executable memory rather than just using malloc and saying it can't be done, but ...
Who really expects Adobe to actually know what they are doing or do anything right anymore?
The problem is that the default configuration in the mainstream versions of Windows right now is not to default to 'on for all' for DEP and ASLR. If you give a developer two choices A) Easy and quick B) long and hard, but safer. Unless he/she is doing the code for free, you can assume their going to pick A over B. The only people who pick B are the ones doing it out of love, not a paycheck.
Until Windows forces them to pick B, most are going to pick A.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
Yes, but I doubt any program on that list doesn't already have platform specific code.
When ideas fail, words become very handy.
Wait, Are we shocked because third party application do not support DEP and ASLR? Hell, most of them completely ignore even the basics of User Permission Management.
"Do you want to use our software? run it as Administrator!".
And when microsoft starts implementing some resonable security in windows 7, guess what's the common answer to such Problem? "Disable UAC", of course!
My mouse from Thrust wouldn't even detect the multiple buttons on it if UAC isn't turned off....and, of course, if an always-running service written in VB6 that eats 25 mb of ram is active, too (together with the always running punkbuster deamon from some forgotten and long unistalled game, the Adobe Licesing Manager Server, the Ipod management service, and some other shitty "I don't know how to properly hook with the operating system" utility, like using a single application to make the cdrom "eject" button working.
I'm a graphic, and I've no time nor the inclination to deal with such problems, yet I need a machine as much responsive as possible.Personally, I'm fleeing to Mac Os as fast as possible (that is, when Adobe will accept my platform license switching).
Frankly, until the windows software enviroment changes radically, I don't see how somebody would voluntary put himself in such mess.
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."
Also I should add that Linux, OS X, and other operating systems have these same features under different names, so any work required to clean up the code to meet the standards required to enable them would be beneficial to all the platforms. Only a small amount of platform specific code would be needed to enable the features on each platform.
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.
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.
Apple Quicktime, Foxit Reader, Google Picasa, Java, OpenOffice.org, RealPlayer, VideoLAN VLC Player, and Winamp - no DEP/ASRL Flash player - ASRL only
Adobe Acrobat Readder - DEP only, but DEP can be circumvented
Firefox - DEP only
http://krebsonsecurity.com/wp-content/uploads/2010/07/depaslr-236x300.jpg
Was that meant to be funny?
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
So, basically run your own malloc function that, in turn, detects the OS and uses the required API?
If it's that simple, why hasn't it been done yet? Yeesh. I hope it's that simple and yet I hope it isn't (because if it is, that means lazy coders are involved)
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...
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.
DEP should be handled by the operating system, not the apps.
Some applications still need to be aware of the operating system's DEP facility. (See discussion above for why.)
...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!
16-bit Windows apps generally won't work in DOSBox, in my experience.
Someone else's experience says Windows 3.1 works in DOSBox. From when is your experience?
In any case, emulating another OS on top of your current OS does not actually mean that your software will run on your current OS.
Mac OS X on PowerPC paravirtualized Mac OS 9 to run Mac OS 9 apps. Microsoft appears to be doing something similar with "XP Mode" in Windows 7 Professional.
you can not natively run 16-bit software on 64-bit Windows.
I was only pointing out that 0123456 didn't say natively.
seems to work in python...
but yes, whats wrong with a #ifdef and a configure script?
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
You probably know but, for people not using actual OS X or never used NeXT OS, the extension of application on OS X is ".app", of course it has nothing to do with the .exe format, it is a self contained directory "acting like" single application file.
WindowMaker (GNUStep) dock applets are called .app too
More interestingly, Symbian calls them ".app" (e.g. Opera.app) internally too. J2ME applications? Called .fakeapp :) If I was a J2ME developer to target Symbian devices, that would really make me think twice.
Apple Quicktime is Windows/Mac, shares a lot of same code between clients. VLC? Insanely multiplatform and multi CPU, Real Player is almost like Firefox , the pack the open source Helix Player for different target platforms. OS X/Linux Real Players are said to differ a little from the raw material while on Windows, you know the story.
For Opera, things go really interesting. Opera Core is actually a single, amazingly portable pure C. UI is tailored for different operating systems and their needs and no need to say, they can't do anything which won't eventually ship to other platforms. One of the reasons they don't bother to open the source since they would have to reject a lot.
So, will these guys have to code differently for using Windows security features like DEP/ASLR? They aren't MS, they have to ship the same source to everyone and expect anyone with a recent libs/gnu toolchain to compile fine for any modern OS/CPU (ARM/PPC/MIPS).
As Apple has the same/similar stuff built into OS X since 10.4.x days and actually automatically enabled it without any apparent problems, I really wonder if you take advantage of these features on OS X without doing any platform tricks? Lets say, if they found a neat way to do it?
On OS X, VLC is the king of all download sites. No matter what kind of a person it is, he/she automatically installs VLC after first fresh OS X install.
There has been NO reports of VLC failing under normal user (non admin) on OS X. Same goes for other mentioned apps, including Real PLayer and even games.
As there is no separate VLC source for both platforms (and Linux), it must be something with underlying OS mechanisms, even the UI or the architecture causing problems under normal user/uac.
In fact, it may have something to do with ignoring 40 year old *NIX model and trying to re-invent wheel over a _wrong_ base.
It can easily be circumvented with a return-to-libc attack.
Hell, it's worse than that: read this 2005 Usenix security conference paper (PDF). It's been a while since I read it, so I can't remember exactly how they did it, but the gist the following. Pretty much all of these attacks require overwriting a return address or function pointer or something like that, so that control transfers to your injected code, to the function in libc that you want to execute (return-to-libc), etc. There are a variety of techniques to detect that sort of thing (especially return address clobbering) with relatively low overhead. The authors of that paper illustrate how you don't even have to do that: just overwriting program data suffices.
Now, that said, I don't not put on my seatbelt when I'm in a car simply because seatbelts don't prevent all deaths (to use an analogy of another poster). As long as people keep using unsafe languages like C, the goal is just going to be reducing the attack surface for even "dumb" attacks like buffer overflows. And DEP does that reasonably well.
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?
I got marked down a troll... I actually meant that question. I used Winamp way back at Winamp 2, when it was a light weight, exceptionally useful Media Player. AOL killed it. I am aware that there is a version of the source code for Winamp 3 floating around, and I was rather fond of Beep Media Player because it supported Winamp 2 themes. But in this day and age where Media Players are also full-featured Multimedia Managers, I don't think Winamp is still relevant. So I ask again, is that obsolete program really still relevant, when even light-weight programs like foobar 2000 are more fully featured and only iTunes is more bloated?
"Now I am become Death, the destroyer of worlds"
So, basically run your own malloc function that, in turn, detects the OS and uses the required API?
Even simpler. Since we're talking about native code here, you have to compile it separately on different platforms - and, on each, you compile it against the version of the library that wraps the native OS API. So there's no "detection" to speak of, it's just a thin wrapper (and if you do link-time optimizations, it may even be stripped out completely by the compiler in the output binary).
If it's that simple, why hasn't it been done yet?
It has been done. Thing is, most applications which are written as cross-platform to begin with usually don't have any problem with this, and never did. The apps which have the problem are typically some kind of ancient stuff that was originally compiled for Win98 or thereabouts, which didn't have any notion of process boundaries to begin with, much less something like DEP. That kind of code is usually both highly nonportable and very messy.
However that type of attack could also easily be made much more difficult by having separate stacks for return addresses and stack frames. While the x86 doesn't have direct support for it (are there other processors which do?), I think due the fact that an x86 usually local variables are referred to through the base pointer, not the stack pointer, it should not be too hard to implement that (it would, however, be an ABI change, so it couldn't be enabled for existing executables; OTOH you wouldn't need to rewrite your programs, just recompile them with a compiler that supports such a modified ABI - the hardest part would probably be for the OS to support both ABIs at the same time). For extra protection, one could put a non-writable page between the return stack and the rest of the data (including the stack frames), so that buffer overruns will trigger a segmentation fault before reaching the return address stack.
The Tao of math: The numbers you can count are not the real numbers.
What does PAE have to do with NX? PAE was just a kludge back before x86-64/amd64 came on the scene. Yes, PAE did support NX later on, but requiring PAE was never a compulsory feature for NX support...NX worked fine on regular 32bit or 64bit kernels on supported hardware/kernels.
Yes, PAE is compulsory for NX support. Part of it is because there is no more room for the NX bit in the plain 32-bit page tables. If you don't believe me, read Intel's or AMD's x86 manuals.
The latter is not what I disagreed with. Yes, there is no room for the NX bit in the plain 32bit page tables, however that does *not* mean that PAE is an absolute requirement for NX support.
http://linuxgazette.net/107/pramode.html
http://en.wikipedia.org/wiki/NX_bit
http://www.wordiq.com/definition/NX_bit
PAE or long mode always mean 64-bit page tables, non-PAE always mean 32-bit page tables. Go read the Intel or AMD x86 manuals.
It's obvious you're not understanding a word I've said, and you persist in clinging to your belief that NX doesn't work in a pure 64-bit OS (since PAE doesn't work in the same) all evidence to the contrary. I suggest you read up yourself on what a 64-bit kernel means.
Yes, long mode requires PAE be enabled and use similar page tables, thus NX works in long mode too.