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.

Comments

Wait a minute

[Anonymous Coward]

Why doesn't Windows enforce it's security?

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?

Re:Wait a minute

[Ironchew]

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

[seibai]

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

[John Hasler]

Because enforcing that every application use these would mean certain sorts of applications couldn't be written

Yes. Buggy ones.

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

[guy-in-corner]

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:Wait a minute

[booyabazooka]

Why doesn't Windows enforce it's security?

I question your assertion that Windows is security.

Re:Wait a minute

[yuhong]

Properly written applications will mark data areas as executable if code is going to be executed from it, it is just that many older applications aren't written properly and thus crashes when DEP is enabled.

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

[TheLink]

> 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.

Re:Wait a minute

[Anonymous Coward]

Any moron writing an application to run that way is a moron.

Re:Wait a minute

[Anonymous Coward]

How would you write a JIT without the ability to turn off DEP on certain pages of memory?

Re:Wait a minute

[yuhong]

I have manually set it to opt-out on the Vista system I am posting this on myself. On compatibility issues, I once had to add a DEP exception for Parallels Workstation 2.2, otherwise starting a virtual machine using it would cause a BSoD. It was even worse in the original version 2.0 dating back to 2005 which did not support the PAE page table format at all forcing PAE and thus NX to be completely disabled.

Re:Wait a minute

[Anonymous Coward]

What the hell is "Stock Keeping Unit' supposed to mean here?

Re:Wait a minute

[X0563511]

Er, "Professional" (XP) and "Ultimate" (Vista, 7) let you pick: Opt-In, Opt-Out, Force-On, Off.

Re:Wait a minute

[X0563511]

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

Re:Wait a minute

[hedwards]

That's not entirely true, I'm not as well versed at Linux as BSD, but we've got things like security levels, flags on top of that. An exploit of that fashion is not going to be able to do things to the kernel if you've got it properly configured, nor is it going to be able to make things run at boot without ones say so.

Sandboxing helps, but Windows has to do it, because it's just way too easy for viruses to install crap to the boot sector.

Re:Wait a minute

[Anonymous Coward]

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

And by many I assume he means "one", because that's how many apps I had trouble with in Windows 7 (StarCraft), and yet that works perfectly with Chaoslauncher, and almost perfectly without it.

Re:Wait a minute

[Nutria]

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?

That's a crock of camel dung.

The Linux kernel (and presumably Unix/BSD) just does ASLR whether you want it or not, and distro packagers enable the NX bit in some kernels.

Re:Wait a minute

[tepples]

How would you write a JIT without the ability to turn off DEP on certain pages of memory?

The JIT engine would have to tell the operating system to mark a given range as writable, write, mark the range as executable, and finally execute. Opting in to DEP is an application's way of telling the OS that it is aware of these newly introduced DEP syscalls.

Re:Wait a minute

[mlts]

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:Wait a minute

[Nutria]

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

That's big in CompSci circles and it's infected a great deal of programmers.

However, COMPUTED GOSUB/GOTO/PERFORM are stunningly useful and are just another term for arrays of function pointers.

Re:Wait a minute

[tepples]

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.

Old 16-bit games run just fine in Windows 7 through the appropriate emulator, such as DOSBox or Snes9x. Or what am I missing?

Re:Wait a minute

[LBt1st]

I know I'd hate to have to debug an app on an OS that randomized the memory addresses each time I ran my code. Much better to be able to enable this sort of thing in the release builds.

But then, you'd probably never knew there was an access violation to begin with. You'd notice something odd once and perhaps only once, without any way to reproduce it.

There's always going to be bugs, and they must be fixed. The OS enforcing this on all apps would make this nearly impossible.

Re:Wait a minute

[tepples]

Any moron writing an application to run [by recompiling code and then executing it] is a moron.

The publishers of VMware, VirtualBox, Virtual PC, Java, and .NET would take issue with your characterizing their developers as morons.

Re:Wait a minute

[cbhacking]

Actually, it's not (and hasn't been for years). Opening a drive's boot sector (or loading kernel drivers) requires administrative privileges, and starting with Vista the default configuration is that your apps don't *have* admin privileges (I configured XP this way too, but it didn't have a nice mechanism like UAC or sudo for those times when Admin is needed - runas is a pain by comparison). NT has a very powerful security model... it's just that most users say "Give me and everything I run full permissions, don't bug me with this security crap" and make said security model somewhat useless.

Re:Wait a minute

[RobertLTux]

its a term from the retail world
each different version of Windows has a different SKU (hint its the UPC barcode or mapped to same)
so for each combo of 32/74 bit Home/Business/Ultimate and Upgrade or Full Install there is a different SKU

Re:Wait a minute

[cbhacking]

16-bit Windows apps generally won't work in DOSBox, in my 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. It's annoying, but the simple truth is that due to the design of the processor, you can not natively run 16-bit software on 64-bit Windows.

Re:Wait a minute

[drsmithy]

See their Trusted Platform Modules (TPM), DRM and HDCP divisions and reconsider our imaginary "freedom to run what we want" a double standard.

None of those do anything unless the application and/or user tells them to.

From Vista on a clause in every Windows EULA gives MS the right to delete executables and files from YOUR computer should they choose to do so (does XP also have this?)

Please quote the relevant section of the EULA.

Re:Wait a minute

[simcop2387]

This is what core dumps are for, you can then open them up in the debugger and examine the program at the state of execution when it crashed. You can also do debugging live still too.

Re:Wait a minute

[Niten]

Linux doesn't enforce DEP or ASLR, either. OS X doesn't even support real ASLR.

You're blatantly wrong here, and your attitude toward the parent poster speaks poorly of your character.

Re:Wait a minute

[John Hasler]

> I know I'd hate to have to debug an app on an OS that randomized the memory
> addresses each time I ran my code. Much better to be able to enable this
> sort of thing in the release builds.

You can turn randomization off on your development machine when you need to. You still should write code that will run with it on as it should be on production machines.

Re:Wait a minute

[God of Lemmings]

This is probably a reference to this clause, found both in Vista and Windows 7 eulas. Available here in various eulas, such as Vista Home Premium English and Windows 7 Home Premium English, found here: microsoft Searching the XP sp2 eula does not seem to contain a similar clause.

"6. POTENTIALLY UNWANTED SOFTWARE. If turned on, Windows Defender will search your computer for “spyware,” “adware” and other potentially unwanted software. If it finds potentially unwanted software, the software will ask you if you want to ignore, disable (quarantine) or remove it. Any potentially unwanted software rated “high” or “severe,” will automatically be removed after scanning unless you change the default setting. Removing or disabling potentially unwanted software may result in other software on your computer ceasing to work, or your breaching a license to use other software on your computer. By using this software, it is possible that you will also remove or disable software that is not potentially unwanted software."

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.

Re:Wait a minute

[sortius_nod]

Yeh, I have no idea what the GP was on about.

Also, don't use the term SKU unless you're trying to restock your warehouse... makes you look like a fool.

Re:Wait a minute

[yuhong]

Yea, this is for Windows Defender which is built into Vista and later.

Re:Wait a minute

[yuhong]

Which are not actually newly introduced. They existed from the beginning of Win32, they just didn't do anything until DEP was introduced.

Re:Wait a minute

[Eskarel]

This is more like SELinux than about resource restriction. UAC does it's best to ensure that even admin users(nothing wrong with them for single user pcs) have to explicitly grant privilege escalation(admin is more like wheel now), and in 7 it's actually tolerable to leave it on.

Unfortunately most desktop apps don't conform to those kind of rules in windows any more than they do in Linux so it doesn't enforce by default any more than selinux is generally enabled by default.

Re:Wait a minute

[tepples]

They existed from the beginning of Win32, they just didn't do anything until DEP was introduced.

Then how were developers supposed to test their programs against an implementation that didn't do anything?

Re:Wait a minute

[gig]

> Why doesn't Windows enforce it's security?

Because the high-end part of the PC market has been all Mac for many years now, well over 90%, leaving Windows as just a low-end commodity system where nobody pays for software so it has to run stuff that's 10 years old. Because there is no incentive for the authors of Java or QuickTime to fix Microsoft's problems for them. Most Windows users are still on XP and don't even have these features.
 

Re:Wait a minute

[Anonymous Coward]

"If you've got it properly configured" I think is the line of interest here.

I'm not as well versed in BSD as I would like to be, and I must admit I've found FreeBSD to be quite awesome from a security aspect (although I'm sure we can have the security argument of Free vs Open another time). I'm not sure anything should be able to do anything to the kernel, even if you didn't configure it in the first place. Also, I think it's worth considering what it could do to your own files, too. I don't want sandboxing to protect my kernel, I want sandboxing to protoect my files; My kernel can't even be touched from my day-to-day login.

Re:Wait a minute

[shutdown -p now]

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

You don't even have to go to the registry for it, though it really is tucked away in a corner that's only missing the "beware of the leopard" sign.

(assuming Vista/7) Control Panel -> System and Security -> System ->Advanced system settings -> Advanced tab -> Performance Settings -> Data Execution Prevention.

The default is it being turned on for all stock Windows applications, and (while it doesn't clearly say so) for anything that opts in. As I understand, it is largely due to the sheer amount of code out there that fails under it - which was a big deal in Vista timeframe, but less so today. I really hope this gets switched to "DEP all the way" in next major release.

Re:Wait a minute

[nabsltd]

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

Unless setting "Turn on DEP for all programs and services except those I select" doesn't do what it says (i.e., a program can still "opt-out" in code), then there are very few apps that have a problem with DEP.

I have this set on dozens of machines (both server and desktop), and have had to make exceptions for less than 5 programs, with the only really annoying one being the driver installer for a TV tuner card (since I think that means that any program named "SETUP.EXE" would be exempted). After I ran the install, I revoked the exception just in case.

Re:Wait a minute

[Anonymous Coward]

Yes, and he was describing the default settings. Server versions default to Opt-Out.

Re:Wait a minute

[drsmithy]

This is probably a reference to this clause, found both in Vista and Windows 7 eulas. Available here in various eulas, such as Vista Home Premium English and Windows 7 Home Premium English, found here: microsoft Searching the XP sp2 eula does not seem to contain a similar clause.

So in other words, it bears only the vaguest and most indirect relevance to the OP's accusation. My, how surprising.

Re:Wait a minute

[spongman]

DEP was first available in XP SP 2 beta, which was available to developers by the start of 2004. that's over 6 years ago. how much testing does one need?

Re:Wait a minute

[BasilBrush]

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

It's obviously commercially suicidal to go from having the current diverse system to a single application store. With new platforms that possible - iOS's iTunes App Store, or to have approved applications only - all games consoles. But not when a platform already has an established anarchy of supply chains, the option isn't there to make all apps go through a single approvals process.

But it'd be perfectly reasonable for Microsoft to have a non-exclusive app store, with the applications guaranteed to have passed through certain quality controls. Like, for example, they have DEP and ASLR enabled, and have been virus scanned.

Re:Wait a minute

[mpe]

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.

Given how hard self-modifying code can be to debug and formally verify making it hard to write is typically a very good thing.

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

Is using such techniques generally a good or bad idea? Are there other situations in which such code can break, including in ways which appear random?

Re:Wait a minute

[Anonymous Coward]

... 32/74 bit Home/Business/Ultimate ...

jumping the gun a bit there, aren't they?

Re:Wait a minute

[IllusionalForce]

That doesn't mean they can't give strong hints to the developers. For example, at least Microsoft's compilers should give deprecation warnings stating that the developer should conform to DEP and ASLR technologies and that compilation support for such stone-age applications will run out at a certain version/point of time. Library functions become deprecated, why shouldn't entire programs be affected of the same?

AOL's Winamp?

[Anonymous Coward]

I remember using Winamp on Windows 98SE. How the mighty haven fallen.

Ya think?

[mcgrew]

Did MS pay for this story? Kudos to them for making the OS more secure, though. Now if I could only get Mandriva on this netbook...

I didn't RTFA, is there a list of unsecure apps?

Re:Ya think?

[Anonymous Coward]

yes

Re:Ya think?

[tokul]

I didn't RTFA, is there a list of unsecure apps?

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

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:Adobe's problem

[beakerMeep]

I know it's cool to hate on Adobe these days, but did you even read the summary? They got it right on this one.

Re:Adobe's problem

[ILuvRamen]

then why did the last 5 people I removed viruses for have javascript PDF exploits detected by the cleanup scanner after the virus was disabled and partially removed? Apparently they didn't "get it right" completely. There's only so much autoprotection you can do to your software before bad design and general insecurity takes over and it doesn't matter anymore.

Re:Adobe's problem

[shutdown -p now]

Neither ASLR nor DEP completely mitigate attacks. A buffer overrun is a buffer overrun, those just make it much harder to exploit - ideally, the chance of success is so low that the attack is impossible for any practical purpose, but pragmatically, there are many creative ways in which a programmer can screw up even further and open the hole wider.

Then, of course, no ASLR will save you if you do downright moronic things, such read untrusted input that is potentially downloaded from the Net and pass it over, unsanitized, to the local shell - which, IIRC, is what Adobe did.

Multi-Platform Programs

[Anonymous Coward]

I'm not a programmer, so I might be completely off on this, but I've noticed that a lot of those programs are multiplatform. If DEP and ASLR are only implemented in Windows (and again, I don't know if they are), wouldn't the developers have to make a separate version of the program just to take advantage of those features?

Re:Multi-Platform Programs

[pavon]

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.

Re:Multi-Platform Programs

[hedwards]

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.

Re:Multi-Platform Programs

[badpazzword]

Yes, but I doubt any program on that list doesn't already have platform specific code.

Re:Multi-Platform Programs

[pavon]

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.

Re:Multi-Platform Programs

[Anonymous Coward]

are you sending this loaded question from you iPhone ?

Re:Multi-Platform Programs

[yuhong]

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:Multi-Platform Programs

[X0563511]

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)

Re:Multi-Platform Programs

[cynyr]

seems to work in python...
but yes, whats wrong with a #ifdef and a configure script?

Re:Multi-Platform Programs

[shutdown -p now]

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.

Re:Multi-Platform Programs

[Bujang Lapok]

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.

Re:Multi-Platform Programs

[yuhong]

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.

Re:Multi-Platform Programs

[Bujang Lapok]

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

Re:Multi-Platform Programs

[yuhong]

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.

Re:Multi-Platform Programs

[Bujang Lapok]

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.

Re:Multi-Platform Programs

[yuhong]

Yes, long mode requires PAE be enabled and use similar page tables, thus NX works in long mode too.

isn't that OSs problem?

[roman_mir]

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?

Re:isn't that OSs problem?

[Anonymous Coward]

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.

Re:isn't that OSs problem?

[hitmark]

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.

Re:isn't that OSs problem?

[Eudial]

[citation needed]

Re:isn't that OSs problem?

[hitmark]

heh, seems it was the win3.x version, not the dos version, but still:
http://www.joelonsoftware.com/articles/fog0000000054.html

Re:isn't that OSs problem?

[TheLink]

It's already been the user's choice since WinXP SP2. The deal is, 1) you cannot turn it on by default because many apps will break. 2) most users are ignorant, they wouldn't know about the choice, understand the choice, or figure out what to do if stuff doesn't work and how to exclude them if desirable.

http://support.microsoft.com/kb/875352#5

If you are logged on as an administrator, you can manually configure DEP to switch between the OptIn and OptOut policies by using the Data Execution Prevention tab in System Properties. The following procedure describes how to manually configure DEP on the computer:

      1. Click Start, click Run, type sysdm.cpl, and then click OK. [or press winkey + pause/break]
      2. On the Advanced tab, under Performance, click Settings.
      3. On the Data Execution Prevention tab, use one of the following procedures:
                    * Click Turn on DEP for essential Windows programs and services only to select the OptIn policy.
                    * Click Turn on DEP for all programs and services except those I select to select the OptOut policy, and then click Add to add the programs that you do not want to use the DEP feature.
      4. Click OK two times.

Most of the windows users who don't know about it, shouldn't be touching it. The rest who know about it, know what to do with it.

Thing is the malware bunch aren't targeting the latter.

Re:isn't that OSs problem?

[cbhacking]

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:isn't that OSs problem?

[Anonymous Coward]

Good description. IIRC 64-bit applications have DEP on automatically. I think VS2008 was the first version to enable DEP and ASLR flags by default (32-bit and 64-bit).

Re:isn't that OSs problem?

[shutdown -p now]

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.

Any application that doesn't run unless exempted from DEP should be considered seriously broken and require fixing (indeed, this is how it is for MS's own software). Any application that needs writable-executable data pages for whatever reason (JIT etc) should use the appropriate API calls to request OS to change page permissions from writable to executable and back as needed.

Re:isn't that OSs problem?

[Anonymous Coward]

I used DEP opt-out back when I was still using Windows XP Pro. It worked fine and there were very few programs which crapped out. Mainly Java-based and dotNet apps, SqlManager (edu use and I think it may have been built in dotNet), and a few others which don't come to mind at the moment.

Why can't Flash implement DEP?

[PhrostyMcByte]

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.

Re:Why can't Flash implement DEP?

[Anonymous Coward]

Because Flash is not an application but a plugin. It is up to application (eg. web browser) to enable (or rather not opt-out) of DEP.

Re:Why can't Flash implement DEP?

[pavon]

Yeah, and apparently Flash is "DEP-safe", since IE 8 enables DEP and Flash works there (unless IE is only enabling DEP for the main process and not the tab processes).

Re:Why can't Flash implement DEP?

[Anonymous Coward]

. . . nice bashing there. But if you had any clue what you are talking about you'd know that Flash uses Just-In-Time compiling techniques which, like Javascript JITs, or Java VMs, have to turn data into executable code. The very thing DEP prevents. So no, they cannot use DEP.

Re:Why can't Flash implement DEP?

[pavon]

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.

Re:Why can't Flash implement DEP?

[Anonymous Coward]

. . . nice bashing there. But if you had any clue what you are talking about you'd know that Flash uses Just-In-Time compiling techniques which, like Javascript JITs, or Java VMs, have to turn data into executable code. The very thing DEP prevents. So no, they cannot use DEP.

If you had any clue about what DEP is you'd know that you can still use VirtualAlloc() with PAGE_EXECUTE | PAGE_READWRITE as the third parameter, and voila, you have read/write memory that's also executable.

DEP only affects the default state of the stack and heap. It doesn't prevent you from allocating memory yourself with whatever flags you want.

Re:Why can't Flash implement DEP?

[shutdown -p now]

you can still use VirtualAlloc() with PAGE_EXECUTE | PAGE_READWRITE as the third parameter, and voila, you have read/write memory that's also executable.

Which is actually a very bad idea in general, for precisely the reasons DEP was introduced in the first place. Really, there's no reason why an app needs a memory page to be both writable and executable at the same time. A typical JIT generates the code once and executes it after; more advanced ones (e.g. JVM HotSpot) can periodically re-JIT stuff, but they don't do it all that often.

Consequently, the proper technique is: use VirtualAlloc with PAGE_READWRITE only, write whatever you want there, then use VirtualProtect to switch it to PAGE_EXECUTE only, and run it. That way, if your app gets exploited, only the pages currently being JIT'ed will be open for code injection, rather than every page that has ever being JIT'ed.

Report is flawed

[Anonymous Coward]

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...

"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:"app"

[Anonymous Coward]

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.

Re:"app"

[hedwards]

Well, then God help you when you come across an app blog that blogs blog apps.

Re:"app"

[Anonymous Coward]

"App" now means a small, useless program that you buy or get for free from a "store."

Re:"app"

[Anonymous Coward]

"App" has been short for "application" for a long time. I'm more annoyed by people who think it's specific to the iPhone (an intranet blog at work not long ago claimed (with no iContext, it was about the progress of technology rather than anything directly Apple-related) that the "first app" appeared in 2008).

Re:"app"

[mlts]

To me, apps are modules of code you find on smartphones. Applets are Java based pieces of code. Applications are executables made for a general purpose computer like a Windows machine, Mac, or pSeries. Programs are a catch-all, but I tend to use the word programs for code written on a full computer OS, as opposed to a smartphone.

Re:"app"

[TeknoHog]

In my understanding, "application" means a piece of software with which users interact directly. "Program" means a piece of software in general, even kernels and libraries are programs. As "program" comes from a broader meaning (a set of contents/instructions, a plan) it is not limited to user interaction.

Nevertheless, I keep using the word "program" for applications. Probably because, back in the days of Basic et al, we talked about writing "programs", and "application" was a later term I associate with commercially packaged stuff. Think about saying "I write code" vs. "I am an application developer".

Re:"app"

[Anonymous Coward]

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

Fair enough, we can call programs "programs" again. What do you propose we call blogs instead?

Re:"app"

[EvanED]

In my understanding, "application" means a piece of software with which users interact directly. "Program" means a piece of software in general, even kernels and libraries are programs.

This is a pretty dumb argument because it doesn't matter much, but just for anther perspective, I'm not as "loose" with what "program" means as you are. To me, a "program" is something that the OS can turn into a process -- this makes the program/process distinction but makes the terms very related. That definition excludes the kernel and libraries. (Though to add to the confusion, I might consider the actual code in a library as "program code".)

As for program vs application, that's much more hazy. Something like Word or Firefox is definitely an application; something like Grep probably isn't (though it's definitely a program). "Application" to me means something that 1. the user interacts with (no daemons), 2. is reasonably heavyweight (so no Grep), and 3. is actually doing something the user wants to do, as opposed to a more supporting task (so no window manager).

I'm not saying I'm right or my definitions are better than yours or anything like that, just giving another viewpoint.

Re:"app"

[KillShill]

You can use a Firefox extension like https://addons.mozilla.org/en-US/firefox/addon/7902/.

It'll replace any word with another of your choosing. Very useful if you don't like seeing lower case i's every other paragraph.

Re:"app"

[grahammm]

Maybe the reasoning behind referring to "apps" is to distinguish between "Application programs" and "System programs". In a long past life, my job title was "systems programmer".

Re:"app"

[maxwell demon]

Well, actuallyfor me the distinction of "program" and "application" is a bit different. A program is basically an executable together with the dynamic libraries it uses, and typically runs in a single process. An application, on the other hand, is something the user perceives as a single entity. While often an application is implemented in a single program, that's not always the case. The main program of the application may execute any number of helper programs which, while separate programs, are actually working together. A typical example would be separation of a GUI frontend and a non-GUI program doing the actual work. Those are two programs, which together form a single application.

Of course, this separation isn't too strict: For example, if you use ddd with a gdb backend, you might consider both together as an application. But on the other hand, gdb is developed independently from ddd, is designed to be used standalone, and even in ddd you can give commands to gdb directly.

Another example would be an IDE for compilers. Many people use their compiler only through the IDE, therefore from their view it can be seen as an integral part of the IDE, even though it is a separate program which also can be called separately. Moreover, the compiler itself may actually consist of several programs as well; for example, a C compiler traditionally consisted of separate executables for the preprocessor and the actual compiler, which nevertheless were called both by the same command (which in addition then also compiled the assembler and possibly the linker), so from the user's view it was just one single (command line) application, even though it consisted of several programs (today the preprocessor is usually integrated into the compiler, and many compilers produce machine code directly, instead of going through an assembler, so apart from calling the linker, the compiler application is indeed implemented in a single program).

So in short: In my view "Application" is the user-level concept, while "program" is the OS level concept. An application may consist of several programs working together to provide a single experience to the user.

Also note that the notion of a program also differs from the notion of an executable, because the program also includes all shared libraries used by that executable.

Re:"app"

[herojig]

"Suite" now means a bloatload of worthless outta-store apps that are never worth the money paid, yet are "upgraded" every 6-18 months like a magazine subscription.

Re:"app"

[mini me]

Software applications have been called apps for as long as I can remember. Certainly years before the iPhone was released to the public.

"decreases significantly"?

[RenQuanta]

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.

Re:"decreases significantly"?

[hitmark]

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

Re:"decreases significantly"?

[cbhacking]

Defeating DEP in and of itself is trivial. That's what ASLR is for. It's still technically possible to exploit an application that uses both, but it's much, much harder, and generally speaking you can't get a guarantee of success like you can with a return-to-shellcode or return-to-libc attack - the first of which DEP prevents and the second of which ASLR prevents.

Stop talking about things you don't understand

[BitZtream]

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.

Re:Stop talking about things you don't understand

[EvanED]

Second whoever said 'flash can't do DEP' needs to stop injecting their ignorance into the conversation.

Actually, while I am all for bashing Flash at most opportunities, really the summary/article is right here.

DEP is enabled on a per-process basis. Flash doesn't create its own process, the browser does: therefore Flash has no say in whether it runs with DEP or not.

(In fact, another poster somewhere above says Flash is actually "DEP-clean", so if the browser starts with DEP enabled, Flash won't cause it to bomb.)

DEP yes, ASLR no

[Animats]

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.

Re:DEP yes, ASLR no

[abigsmurf]

By that logic, encryption is also security through obscurity, therefore there's no point in encrpyting data.

The point of ASLR isn't to provide absolute security, it's to provide an additional layer of security to make it harder to produce meaningful exploits from vulnerabilities.

Re:DEP yes, ASLR no

[benjymouse]

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:DEP yes, ASLR no

[tepples]

for an app such as IE (or Chrome) to allow files to be downloaded, a separate "helper" or "broker" process must be used. [...] a lower integrity process *can not* send messages to a higher privileged process.

Then how does IE tell its "broker" what to do?

Re:DEP yes, ASLR no

[Anonymous Coward]

What you're saying sounds a lot like people bragging that they don't like wearing seatbelts while driving.
Because programs will always have bugs, this measure just makes sense.

Re:DEP yes, ASLR no

[benjymouse]

http://msdn.microsoft.com/en-us/library/Bb250462

Re:DEP yes, ASLR no

[Anonymous Coward]

Named pipe probably. What they meant was send a high privileged process messages using SendMessage() and PostMessage()

Re:DEP yes, ASLR no

[KillShill]

Visit the following page to find out how to run any program in low-integrity mode: http://msdn.microsoft.com/en-us/library/bb625960.aspx

Re:DEP yes, ASLR no

[JackDW]

Agreed, seems like security theatre to me. ASLR makes legitimate debugging a pain, and what's the benefit? It's the computing equivalent of airport security.

Furthermore, DEP sounds good, but my eyes were opened recently to return-oriented programming, which allows arbitrary exploits to run without ever modifying any executable code. And ASLR/DEP are useless when the exploits run as managed code anyway: a common attack vector ever since the first MS Word macro viruses.

Re:DEP yes, ASLR no

[shutdown -p now]

ASLR, though, is iffy. Randomizing the position of code in memory is a form of security through obscurity.

Yes, and guess what? Security through obscurity works, too. It's not foolproof, for sure, but it can make it much harder to break something. Especially - as is the case with ASLR - the "obscured" bits change every time.

The direct analogy would be passwords - they are themselves a classic example of security through obscurity (indeed, the security of the password-protected system hinges on only trusted person/people knowing the password, and no-one else), and the more often you change them, the more secure you are from someone guessing your password. With ASLR, the "password" to the program - which you need to know to effectively exploit a buffer overrun in most cases - is randomized on every run.

If there's a bug that's exploitable with ASLR, it's a bug that can crash the program without it.

It's the other way around. Typically, a bug that's exploitable without ASLR will "just" crash the program with it.

It also makes debugging harder. No two crash dumps for the same bug are the same. Not even close.

The usermode crash dump is the same for all practical purposes if the symbols are resolved, and why would you debug without resolved symbols?

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.

And who enables this? If we're talking about the renderer process willingly dropping any permissions it may have to that effect at start so that they can't be re-enabled anymore, then it's already doable in Windows. Indeed, IE does something of that kind (though arguably doesn't go far enough), and Chrome does a similar thing with even tighter sandboxing.

If we're talking about the OS forcing renderer to such permissions, then who sets those permissions? It'd have to be done by the user, or an average app developer - which is to say, folks who are clueless about much simpler and easier to deal with stuff (such as DEP/ASLR) today already.

Re:DEP yes, ASLR no

[gillbates]

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. And the problem it addresses - mainly the stack overflow - is such a well-known vulnerability that only the most negligent of programmers are ignorant of it, and most companies use tools to detect and prevent these sorts of defects. (Granted, Microsoft is a glaring exception, but they are hardly considered a secure software vendor). Finally, DEP is a historical accident - it was so easily implemented in hardware that it was adopted by UNIX systems long before stack-checking utilities and stack canaries had become commonplace. It offers little, if any, more security than a security-conscious developer using modern stack-overflow checking tools would accomplish.

Re:DEP yes, ASLR no

[spongman]

why does ASLR complicate debugging? as long as your dumps contain the relocation info and your debugger is aware of it there shouldn't be any problem. wefault, adplus, windbg & visual studio are all ASLR-aware.

Re:DEP yes, ASLR no

[JackDW]

Fair question. The issue is not that the code isn't debuggable, but rather that no two executions are the same. Consider trying to find an obscure bug by comparing two executions, as I recently needed to do with the QEMU simulator.

Just ignoring memory addresses isn't enough because their values have significance within the simulator's JIT engine. For example, if two translated basic blocks are far apart, then a different sort of jump is needed to go from one to the other in some sorts of machine code. ASLR means that subtly different code is produced in each case, hiding the actual bug within a haystack of irrelevant differences.

Fortunate, then, that it's easy to disable ASLR. My contention is that, as a security feature, it's pretty pointless.

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...)

Re:DEP yes, ASLR no

[Anonymous Coward]

Mod parent up. Great post.

Re:DEP yes, ASLR no

[Anonymous Coward]

Having examined a lot of crash logs for third party plugins, including ones from big companies like Apple, Google, and Adobe...ooooh, Adobe...I can assure you that stack overflows are alive and well.

Re:DEP yes, ASLR no

[Anonymous Coward]

You just finished saying (in the GGP post) that DEP's major failing is that it can't handle return-oriented attacks. That's exactly where ASLR is useful.

The majority of the attacks I see defeating one of those relies or disabling the other. The remainder tend to be much more difficult.

ASLR also gets much more useful in a 64-bit space. Makes it much harder to just shotgun a section of memory space for a return-to-libc.

Re:DEP yes, ASLR no

[spongman]

but ASLR doesn't affect basic blocks. relative jumps remain untouched, ASLR only affects the base address of loaded modules which are fixed up by the loader. even without ASLR the base address of a DLL isn't guaranteed to be the address that's requested. historically, a DLL can request a preferred base address, but the loader may chose not to load at that address (for example, if something else is already loaded at that address). the only downside to ASLR here is that load-time fixups MUST be applied because, in general, the DLL will NOT be loaded at the requested base address. it used to be that you could optimize the base addresses of the DLLs loaded by your application (using LINK.exe /BASE: ) in such a way as to (almost) guarantee that the DLLs would load at their preferred address and the loader would be able to skip the fixup step. however, processor speed and shared-code pages have made this optimization largely insignificant.

as far as JITed code is concerned, the OS makes no significant guarantees about the location of the memory returned by VirtualAlloc. even with ASLR disabled, two consecutive runs of a JIT on the same machine may well result in code residing in different locations.

Re:DEP yes, ASLR no

[gillbates]

There are (or were) several well publicized incidents where cryptographic keys were discovered because the programmer left them on the stack. Putting them in the executable code sections would have mitigated this risk.

Java made DEP pretty much irrelevant to everyone except those few programmers trying to write secure code where protecting the algorithm itself is an important trade secret. While no algorithm executing on your machine is theoretically impossible to discover, DEP makes it easier for the reverse engineer. In the 3 to 6 month development timeframe for most consumer electronics, this can be a significant liability.

"just" DEP and ASLR? Really?

[Sal Zeta]

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.

Re:"just" DEP and ASLR? Really?

[yuhong]

Hell, most of them completely ignore even the basics of User Permission Management. "Do you want to use our software? run it as Administrator!".

What was IMO even worse was that feature has existed since NT 3.1!

Re:"just" DEP and ASLR? Really?

[shutdown -p now]

It's not for the lack of trying from Microsoft's side, I can tell you that. Certification requirements for those "Designed for Windows" stickers you see on the boxes for some software cover all those things - properly running under non-admin, elevating only for things that actually require elevation, and a bunch of other common sense technical requirements such as not trying to catch & swallow segfaults (believe it or not, some try...). IIRC, this was the case since "Designed for Windows XP". Since Vista/7, running correctly on x64 is also a must for certification.

It helped a lot (though releasing Vista probably helped even more), but, as you rightly note, we still aren't fully there yet.

Anyway... I suggest looking at the Windows logo requirements, and if it sounds like what you'd expect from well-written Windows software, you should pay attention to that sticker. For commercial software, I really don't know any excuse for not having it (I've lead the effort to get an app certified in one of my past jobs, and it was for an app with 4 developers on the team, and probably a few thousand users at most). Free -including FOSS - stuff likely won't have it, of course, so there you're on your own - but, as a rule of thumb, FOSS specifically can be assumed to not do really stupid things.

ASLR possibly degrades performance?

[Rockoon]

Modern machines rely heavily on cache for efficiency, and thus code and data locality. I wonder what effect ASLR has on this.

Re:ASLR possibly degrades performance?

[Anonymous Coward]

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:ASLR possibly degrades performance?

[Anonymous Coward]

Probably none. I did not RTFA, but ASLR is probably done at the page level (page size is at least 32K) but caching is done in much smaller blocks (maybe 4K maximum... been a long time since I did a hardware class) and the boundaries will align (so locality is not an issue on a boundary).

Re:ASLR possibly degrades performance?

[Anonymous Coward]

no impact: the randomization is done when the program loads

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:ASLR possibly degrades performance?

[LO0G]

You're close but off by an order of magnitude (base 2). On current x86 and x64 machines, pages are typically 4K or 8K and cache lines are typically 32 bytes.

Note the word typically - I know that this can be changed by tweaking various CPU options, but for Windows these are the normal values.

Microsoft also mentioned memory protection

[noidentity]

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."

I can't RTFA

[sproketboy]

because Its PDF and I don't know if my Adobe reader has DEP so I'm afraid I'll get hacked..... /s

Java?

[alannon]

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.

Re:Java?

[benjymouse]

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.

It is entirely possible to take advantage of these counter-measures. I believe that Java on BSD does something like copying memory around to support the NX bit and still allow the running process to write new code. The restriction that is enforced is that a memory block cannot be *both* executable *and* writable. It is perfectly ok to write memory and then switch it to executable code.

MS probably had to build special mechanisms into the CLR runtime for it to work in .NET.

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.

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.

Whaaat? Java has an abysmal vulnerability track record, and this exact issue was used in a pwn2own exploit of Windows Vista. Not the OS, but a blended attack through Java and Flash. The attacker took advantage of the fact that Java did not support NX and even string literals was executable. Because the attacker could load perfectly legit looking Java code (but with string literals which - when executed as machine instructions - was actual attack code).

Re:Java?

[BitZtream]

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.

Re:Java?

[Anonymous Coward]

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.

Chrome JITs all their JavaScript and manages to use DEP and ASLR. And Java is a freaking static language. There's absolutely no reason why they can't use DEP and ASLR while stilling doing JIT.

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.

WHAT?! No, it doesn't. Java has an abysmal security track record.

You have upgraded to 1.6 Update 20, right? Because it fixes quite a few security flaws.

Re:Java?

[bertok]

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...

Wha?

[toadlife]

Was that meant to be funny?

Re:Wha?

[suomynonAyletamitlU]

Do you mean, were Microsoft's bad decisions meant to be funny, or did you mean, was the executive summary of Microsoft's bad decisions highlighted at an opportune time with ironic phrasing meant to be funny?

Re:Wha?

[BitZtream]

Guess you don't realize that when MS made that statement it was when most PC owners didn't have a PC with an MMU, so there truely wasn't anything the OS could do about it on the common hardware.

You need VMM support which requires a MMU (on chip or otherwise) in order to actually have protected memory.

Go ahead though, pretend you have a clue, no one will notice.

Re:Wha?

[Anonymous Coward]

Your answer is the same answer to the question, "Was your post supposed to illicit jokes on just how stupid you are?" Because I'm feeling spunky today, here you go. The answer is yes.

Re:Wha?

[Anonymous Coward]

I thought so, but many people around here actually believe the things you wrote, so I wasn't sure.

Re:Wha?

[noidentity]

I was making the point that it's silly for Microsoft in 2010 to say that application developers need to have their code observe security limits, rather than have the OS enforce them on the application. My joke was illustrating a clearly absurd example where modern operating systems do enforce it, so that the reader might ask why it can't do the same for these security features as well.

Re:Wha?

[EvanED]

My joke was illustrating a clearly absurd example where modern operating systems do enforce it, so that the reader might ask why it can't do the same for these security features as well.

As has been said many times in this thread, it can. As a user, you can tell Windows to always enforce DEP. Just expect that you may not be able to run all your software, which is why it's not configured that way by default.

MS didn't get where it is by breaking backwards compatibility with a ton of Windows programs, that's for sure.

True, some work for Apple

[tepples]

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.

Re:True, some work for Apple

[shutdown -p now]

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.

The flags to request the newly allocated memory block to be executable have been there since WinNT 3.1.

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.

Not really, JS is also managed code, and Apple's implementation is even a JIT.

Re:True, some work for Apple

[tepples]

The flags to request the newly allocated memory block to be executable have been there since WinNT 3.1.

If the kernel doesn't enforce the flags, as it didn't on x86 until halfway through Windows XP, there's no way for a programmer to be sure that he's passing the correct flags.

Re:True, some work for Apple

[LO0G]

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.

Re:True, some work for Apple

[shutdown -p now]

If the kernel doesn't enforce the flags, as it didn't on x86 until halfway through Windows XP, there's no way for a programmer to be sure that he's passing the correct flags.

Of course there is: he just needs to read and understand the documentation. He has no way to test it, but testing isn't the only way to ensure that code is correct.

Re:True, some work for Apple

[tepples]

He has no way to test it, but testing isn't the only way to ensure that code is correct.

As I understand it, test-driven development took off precisely because formal verification of commercial off-the-shelf software is usually cost prohibitive.

ASLR more effective than DEP

[Anonymous Coward]

I agree that `DEP' is a no-brainer, but it's only effective against very basic attack techniques. It can easily be circumvented with a return-to-libc attack.

ASLR, when implemented properly, is very effective against most attacks. If you have any clue in computer security, you would notice that nearly every security mechanism works in a similar way (passwords, cryptographic keys, CSRF tokens, etc...).

When attacking a remote machine, it can take some serious amount of time to `crack' ASLR (especially on a 64bit box, comparable to cracking a password). Such `brute force' attacks can easily be discovered by an IDS, and ASLR can give the sysadmin the necessary time to patch the potential flaw.

If you think that randomizing something is security through obscurity, you're full of BS. Security through obscurity means that the design or implementation (i.e. of a cryptographic algorithm) is kept secret or is obscured, and therefore the security of such system can not be determined.

Re:ASLR more effective than DEP

[EvanED]

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.

Re:ASLR more effective than DEP

[maxwell demon]

I agree that `DEP' is a no-brainer, but it's only effective against very basic attack techniques. It can easily be circumvented with a return-to-libc attack.

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.

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 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).

Re:Authenticode for free software?

[Anonymous Coward]

Apple doesn't allow unsigned programs to run at all. So let them run in a sandbox. The benefit far outweighs the drawbacks. Popular open-source projects that would like a certificate can petition their users for donations, like WinCDEmu has done.

Re:Authenticode for free software?

[Anonymous Coward]

I think the trade wouldn't be that unfair.
Firstly, people writing apps for Windows make a lightened choice. They do write apps for a proprietary system, which impose it's own rules.
If they want more freedom, there are other systems to write applications for.

Re:Authenticode for free software?

[tepples]

If they want more freedom, there are other systems to write applications for.

If by "other systems" you meant "popular Linux distributions for PCs", end users will likely run into some hardware support landmines unless the hardware is purpose-built to run free software (read: came with preinstalled Linux).

Kernel, not apps

[Gothmolly]

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.

Re:Kernel, not apps

[cbhacking]

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...

Re:Kernel, not apps

[Gothmolly]

This is slashdot - nobody cares about your recommendation for anything, especially something on MS Windows.

Re:Kernel, not apps

[Anonymous Coward]

Yet strangely enough, GPP still contributed far more to the discussion than you did...

...Did they just say...?

[Zixaphir]

What the hell is Winamp doing on this list? That was popular, what? 2000? 2001? Is that obsolete program really still relevant?

Re:...Did they just say...?

[Zixaphir]

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?

Two words: JIT recompiler

[tepples]

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.)

How Can Google Chrome Be Considered "Safe"...

[CAOgdin]

...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!

Re:How Can Google Chrome Be Considered "Safe"...

[n0-0p]

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:How Can Google Chrome Be Considered "Safe"...

[shutdown -p now]

There's nothing wrong with installing a program in the Application directory; it's pretty much the norm on Windows for per-user installations.

In fact, it's precisely what ClickOnce - which is an install technology from MS itself - does.

Re:How Can Google Chrome Be Considered "Safe"...

[maxwell demon]

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.

That's not a problem of installing anything there, but a problem of Window's implementation of Active Directory. First, it's plain silly to copy the whole user directory to the local machine and back again, instead of simply accessing the remote one (and I wonder what happens if you log into two computers at the same time). Second, it is even more silly to copy files back which have not changed (like executable data of a program which asn't been updated).

Note that in your directory you also might have other large files which rarely change.

Re:How Can Google Chrome Be Considered "Safe"...

[Anonymous Coward]

simple answer. Security is about documenting, knowing, and granting privileges. Sure you can always install per user applications, and in windows if you dont want them you would disable all executables that are not in program files or windows directory. BUT it is an expectation of most IT staff to have system wide installs that make documenting versions, centralized deployment, and patch management easier. This also makes testing easier of patches easier. Not just google testing, but internal testing to make sure it doesnt conflict with security policies. Now with the combination of addons/extensions that are also user installed, Chrome (along with firefox) are system admin's security nightmares.
In multi-user systems, these are cardinal sins.

Re:How Can Google Chrome Be Considered "Safe"...

[CAOgdin]

Okay, so my 53 years trumps your 15. The issue is that by installing Chrome in profile directories, you've left it completely read/write-capable. That means some malware can simply change the executable at boot time to what ever they'd prefer to put in place, and there's no protection. When it's in the %ProgramFiles% structure, however, I can set the permissions (like Windows 7 does, by default, with the "TrustedInstaller" service, or like most of us who care about security do with prohibiting writing to executables by imposing an Administrator's permissions as the only "Write" authority.) Generally, things in the %ProgramFiles% structure should be--under proper security--virtually invulnerable to malware attempting to corrupt software, while data, largely in the "Profiles", can be read and written freely. Perhaps that's not a security vulnerability in your world, but it certainly is in mine.

Re:How Can Google Chrome Be Considered "Safe"...

[Anonymous Coward]

No, see I can tell you why they are a "security vulnerability". You have to change your mindset from "Actual security" to "Dictator like control", and realize that "Security" means to many companies, etc. "Preventing users from installing what they want". Granted, if the network and OS were properly configured, it wouldn't matter much what they can install, but they usually aren't. It's easier to say "No AOL!" than it is to actually block the ports AIM uses, for example.

When users can install things locally to their user account, the admins don't like it. But... Windows has nothing like the non-executable mount option, so there is nothing the admins can do, actually. Most people I know use PortableApps.com to get "portable" versions, not just for running from USB, but for running from their "My Documents" folder on machines where they can't install to the "Program files" folder.

Windows 3.1 in DOSBox

[tepples]

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.

Re:Windows 3.1 in DOSBox

[0123456]

I was only pointing out that 0123456 didn't say natively.

I rather thought that was implied; otherwise you might as well have said that Windows 7 runs PS2 games, because it can do in an emulator.

Though I'd accept merely running them playably, which no emulator/virtual machine I've tried so far can do with Carmageddon. Either the graphics are corrupt or it's too slow to play.

Comes from NeXT and OS X

[Ilgaz]

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.

Re:Comes from NeXT and OS X

[Anonymous Coward]

They stopped doing that several years ago (from Symbian9 and onwards, it's .exe)...

Massively multiplatform apps

[Ilgaz]

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?

Source is the same, OS is the issue

[Ilgaz]

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.

Mod parent up

[BhaKi]

I wish I had mod points.

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:Apple doesn't just make Mac OS X

[EvanED]

Who the crap modded that a troll?

two ideas

[Anonymous Coward]

perhaps the fsf, or even a completely new foundation, could offer to organise the collection of donations or micropayments, or even ad revenue from participating opensource sites, to be used for registration and certification for the most popular and sucessful open source software.

fix the software

[Anonymous Coward]

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

So?

OpenBSD initially introduced ASLR and other security options, and a whole bunch of software in their /usr/ports broke because of it. Initially they didn't enable it by default to allow people to test third-party software and submit bug reports and/or patches. After a little while they turned it on by default.

ASLR has been around in Windows since Vista, and now again with W7. If companies haven't fixed their software by now, tough shit, it should be on by default. Ditto for DEP.

Sometimes the only way people will do the right thing is to light a fire under their ass. Windows 7 SP2 should turn it on by default. In Windows "8" there should be no way to turn it off.

Not true

[Anonymous Coward]

I think windows default applies this security to all apps.

Therefore this story is not true.

(At least on xp x64).

app = application of a program as a f(inputs)

[Anonymous Coward]

Chris here. Too lazy to log in. A program is something that can be loaded in executed. It is applied to some task. The application of the program to the task has been shortened to app. What confuses the shit out of the masses is that a single program can be many different "apps" - that is a single set of opcodes can be applied in different ways. Think initial conditions. Duh. Banish app from the lexicon. Or at least use it correctly and unabiguosly to mean a program + a set of initial conditions. Please.