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'
Can we please stop calling everything "apps" and go back to programs. App is getting to be as annoying as blog.
[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).
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.
There's no place I could be, since I've found Serenity...
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?
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...)