Popular apps don't bother with Windows defences
Many popular software applications have avoided including security protection mechanisms built into the latest versions of Windows. The omission leaves these applications at greater risk of hacker attack, according to a study by security patching and notification firm Secunia. Two key security mechanisms in Windows - DEP (Data …
I thought you used the phrase "Windows defences".
Looking at the "related stories" underneath, two of them are:
"Microsoft sees spike in attacks targeting 0day Windows bug (30 June 2010)"
"Patchy Windows patching leaves users insecure (7 March 2010)"
at once again proving that commentards really cant read.
"Patchy Windows patching leaves users insecure (7 March 2010)"
Yup an article NOT about Windows, but software running on windows.
Well Done.
The post is required, and must contain letters.
actually have a kind of sandboxing mechanism since IE8 and VISTA. But only MS can use it.
Linux Security Modules exist for years now and there are systems like SE Linux and AppArmor which use LSM.
When it comes to Security, MS plays the bunch of illiterates.
Bloody grand thing that is. I absolutely love ho...waitaminute...WHY ISN'T THIS BLOODY PACKAGE WORKING?!?!?
<Google "how do I make this farking thing work with SELINUX">
<Fiddle for twelve hours trying to make it work>
**** it, I'm going to use tables^h^h^h^h^h^h^h^h^h^h^h just disable the damned thing.
SELinux is truly like trying to code a website in CSS: grand in theory, and with enough tinkering or wizardry it's possible to implement in practice. It's still a miserable PITA however, missing the most basic bits of usability. Microsoft could stand to learn a lot from how secure SELinux makes an operating system. Linux devs could stand to learn a lot from Microsoft about making it easy to use and administer.
Same as it always was…
I got the impression from the story that windows software is fine and secure. All none windows software fails to use these technologies.
So are secuna in bed with windows? paid by them to produce this report?
Those defences certainly aren't pushing a case to remove the Anti virus from my machine, so are they really any good, is this article actually saying anything other than none windows doesn't use windows stuff. (Not that bad a thing at times)
Newer versions of Windows add functionality that applications need to be built against to work. These help secure against certain attacks.
Data Execution Prevention (DEP) makes applications more resilient against techniques that make use of attacks to write code to an area of the program that contains data and then call into that code.
Address Space Layout Randomization (ASLR) changes where core DLLs are loaded to in the application at load time so the location is non-deterministic. This makes it harder to use attacks that make use of that knowledge.
These features don't make applications invulnerable to attacks, but they make it harder for an attacker to exploit weaknesses in the code.
In general, Windows /is/ fine and secure. There are a few vulnerabilities discovered every now and again, but every few vulnerabilities in the actual operating system have been actively exploited for the past few years. (Most extant malware exploits stuff for which patches have existed for bloody ages.)
I will not say "Windows is secure." Mind you, I wouldn't say that about ANY operating system. I will say that the attack surface is much smaller today than five years ago, and that there ROI no longer favours attacking the operating system directly. Instead, the greatest ROI for an attacker is third-party software. (Usually Adobe.)
This is true of virtually everything nowadays though. Putting aside the predjudices and preconceptions we all naturally hold, all operating systems are similarly vulnerable when an application doesn’t play ball. I’ve seen Linux systems rooted because some CMS or other wasn’t compatible with SELinux, thus resulting in SELinux being disabled, and the system getting pwned. (If it’s incompatible with SELinux, there’s usually a damned good reason. Don’t use a non-SELinuxed system facing the net…)
I’ve seen plenty of Macs (and even the odd iPhone) where the user downloaded something stupid and the devices had to be wiped. (Seriously, Mac Trojans piss me off. Mac users never have any defences.)
Windows systems are unique though, because of the legacy of insecurity. Microsoft finally got it’s act together in creating a set of tools and APIs that allow applications to run in a secure fashion on it’s operating system, and none of the app vendors want to play ball. What does Microsoft do? Impose these new security features on all applications, thus breaking 80-90% of everything available for its operating system? That’s asking Microsoft to go outside and cut its own throat. Independent software vendors (ISVs) matter. People don’t actually /care/ if the computer is Windows or Mac or whatever. They care about what applications it can run, and that boils down to ISV support.
Microsoft has only two advantages over its competitors: it is easier to use and administer than anything else, and it has a larger installed base of applications. Rather than throw away one of those two advantages, it has instead embarked on the very long and difficult road of begging, pleading, cajoling, threatening and bribing ISVs to clean up their code.
Jobs just tells them to go to hell in public, then boots them out of his playground. There’s something to be said for that, but it all depends on how far he takes it. If his booting Adobe out of the sandbox was nothing more than example to scare the other devs into cooperating, then he’s probably a thousand times smarter than Ballmer could ever hope to be. If he’s actually nuts and goes on similar rampages against anyone and everyone who doesn’t play ball then he’s going to slit Apple’s wrists before they even really get started.
AFAIK Google doesn’t actually work with any ISVs for anything at all. When you are in a Google world, there is Google, Google, some more Google, Google does some things, you can use Google, oh and there’s some other websites out there, but you don’t need them because it’s all done by Google. When I think about their business model, the only thing that comes to mind is “who’s the monopoly now?” If Google were to win the forthcoming war between Microsoft, Apple, Google, Oracle and HP, then there would be only one software developer left in the entire world: Google. It’s true that (for now) they have an app store on Android, but Google has made mention many times of how much they absolutely abhor “native code”. ChromeOS is all about the web, and let’s face it, Google own the web. If there’s a good service out there, Google either clones it, buys it or rips it off. If Google won the IT wars, they would be a massively vertically and horizontally integrated behemoth.
Fortunately, that will absolutely never happen. People want choice, and this will prevent Google from every actually becoming a Monopoly in any practical fashion. There will always be another operating system, be that Linux, OSX/iOS/ Winwhatever, WebOS or Solaris. People won’t stand for the lockin…they absolutely require the ability to run applications from ISVs, and won’t have it any other way.
So what’s the solution to the security problem?
Linux: you can do anything you want, but if you want to make it secure, or remotely interoperable with all the other stuff on out platform you will have to jump through these 10,000 hoops. Otherwise your application pretty much will be ignored, or not actually work with important things like 3D acceleration. Also, please pay attention to the moving goalposts, those 10,000 hoops are constantly in motion. What do you mean that’s a pain in the ASCII? You’re just a terrible programmer!
Google: Web services, web services, web services, web services. Introducing Google whatever webservice you sunk a squillion dollars into Beta! (Please get your invite from the hype dispenser.) Oh, and you can use the android market, lol. For now.
Apple: you vill comply und you vill like it!
Microsoft: Let’s get everyone in a room and talk about our feelings. Let’s build a “developer ecosystem” and ensure that everyone has the tools they need to make any application they want. As long as you are coding you app to run on Windows, Microsoft will even help you write an application that competes directly with their own offerings. Anything and everything will be given to the Windows developers.
I will go out on a limb and say that ALL of these approaches are wrong, or at least incomplete. So there you have it, the basic approaches to handling security and developers tie in with the business model and the philosophies of the people who use, manage and oversee the platforms. Same as it ever was, with one exception:
Windows itself is finally pretty damned secure. It’s just their entire philosophical approach to giving devs enough rope to hang themselves that’s biting them in the *** now.
In Linux ALSR is enabled on a system wide basis and DEP is an opt out feature that is only opted out if the compiler flags the app as needing executable data areas. Since it is rare for apps to need executable data areas most Linux apps run with DEP enabled.
I don't see why Microsoft needed to do this backwards.
Microsoft have always done these things backwards.
A Windows application also needs to opt in to get the XP or later themed look. If they don't, they get the 9x/2000 look and look out of place.
"Microsoft has only two advantages over its competitors: it is easier to use and administer than anything else, and it has a larger installed base of applications."
It may be easier to administer but it certainly isn't easier to use than, say, OSX. Mac has had the ease of use title for quite some time. Trouble is people on here look at ease of use from a geek perspective and geeks make up a tiny percentage of global computer users. I like windows 7 and I'm looking forward to my workplace XP boxen being updated, but it still doesn't beat OSX on the usage front.
I'd even venture to say that it's only the apps that keep it alive and the locki-in/sunken investment on the part of big businesses that are loathe to re-engineer.
Presumably Java is entirely vulnerabe to attack if it doesn't use Windows defences. It's not as though it's designed to work in a sandbox and has it's own security model that works consistently across all the platforms the virtual machine runs on.
Funny then how java seems to cause problems consistently across all platforms. Maybe if it made a little bit better use of the native security features of those platforms it wouldn't be so loathed and reviled by sysadmins everywhere.
I dont see any reason why java couldnt use Address space randomisation, however, due to the nature of it, it cant really use non-executable data areas.
Havent had too many issues with Java recently myself, the main issues being around the nature of UTF-8 as defined by inputstreams and outputstreams, which appears to be platform dependant (I know there not meant to be, thats the issue), but when i've done stuff with the SWT, its all nicely cross-platform. Even printing works these days.
Er, these two systems increase the workload of developers, both by coding and having to think about how they affect what you're trying to write.
How many developers have heard of these systems, let alone use them? And why should they when all they do is shift the cost onto developers?
Of course they won't be used. MS need to fix the security model properly, not try to bolt-on stuff that developers can ignore.
I'm not sure why they would be. Based on NON-MS implementations of things that do the same thing, the workload consists of roughly "Find 'mem_allocate(', replace with 'secure_mem_allocate('" and "Find 'load_lib(', replace with 'sec_load_lib('". Unless Microsoft picked some amazingly bass-ackward method of implementing these things...
Of course, the really bastard way to do this would simply be to replace the things in the OS at the API level, and solve THIS problem for all time. Plus or minus a little consequential damage, admittedly...
...it's their patootie on the line since THEY'RE the ones in the crosshairs. This is not a Microsoft thing at issue since third-party applications, used wrong, can play havoc in any system: Windows, Mac, Linux, whatever. Think of DEP like a protective cup--not that difficult to use and pretty handy in case someone tries to go at you "downstairs" (caveat: JIT compilers can't use DEP properly since they, by design, generate executable code for on-the-fly execution). ASLR is like picking a different time of day each day to, say, run to the bank. That way, it's harder for someone to pick up on your routine and start to tail you.
They ARE part of the security model, but it's not enough that the OS uses them since third-party apps can easily poke holes in the defenses and therefore have to THEMSELVES be fortified.
"Er, these two systems increase the workload of developers, both by coding and having to think about how they affect what you're trying to write."
Unless your still programming in assembly language, These are both compiler issues.
I cant think of any HLL where address space randomation would be an issue unless you specifically decide to make it one, and the only reason you could possibly want to use Executable data areas is for Self modifying code, which is a *really* bad idea anyway, except in very limited circumstances. (JIT compilers for interpreted code for instance).
Why would applications need to be explicitly written to support ASLR/DEP? And would applications written in this way fail to work on older versions of windows?
As i understand it, the ASLR and NX support present in linux (and addon patches like pax) does not require modifications to userland applications - ie they all benefit from the kernel features unless you explicitly disable them.
The problem with that approach is that it breaks things. Even on Linux. It's easy to say "well it would only break bad applications," but people still keep demanding the ability to run them...
"...shows that the vast majority of 16 popular utilities analysed fail to support either DEP or ASLR."
It costs money and needs a NDA to MS. Labour and design costs of course on top of those.
MS can't design anything which isn't a cash cow for them so no-one is willing to pay.
...but why the hell should the app devs need to care about this? Surely it is up to the OS/kernel devs to ensure that their code protects itself? Expecting the app devs to do it is just buck-passing; the app devs may be too lazy, too busy, or simply inexperienced.
I read the story as saying that Windows is simply not a secure platform and not good enough for any sensitive operations (e.g. on-line banking). Am I the only one?
Altering existing API calls to have different semantics (e.g. DEP) to what they usually have will break any existing applications that use JIT compilation, for example.
DEP is therefore opt-in on Windows. Code that isn't self-altering can just enable DEP in the linker and work. Code that is self-altering can still use DEP, but needs changes to specifically mark "non-DEP" sections of memory.
ASLR is similar. I'm not entirely sure of the reasons not to enable it, other than all components loaded by an ASLR-enabled component must also be ASLR-enabled. I imagine that there are low-level applications that make assumptions about the address space layout.
"Altering existing API calls to have different semantics (e.g. DEP) to what they usually have will break any existing applications that use JIT compilation, for example."
FWIW, DEP has been part of the Win32 API since the early days. Dig out the very first Win32 SDK, and there you will see VirtualProtect() and friends in all their glory. http://msdn.microsoft.com/en-us/library/ms810627.aspx is an old (1993) article describing some of these.
The catch is that it took another ten years or so before we saw x86 hardware support this. By then, the other WNT hardware platforms (capable of DEP before DEP had a name) had ceased to be. (incidentally, it would not do any harm to use these API functions on non-DEP hardware, they simply turn into NOPs -- there was never any excuse not to support DEP, even back in 1993)
But yes, JITters should face difficulties and it is telling that both shockwave and java forced IE to run without DEP until quite recently. The lack of flash is still making 64-bit IE a daunting user experience.
Most applications however do not use features that would require any special thought vis-a-vis DEP. There were some surprises in the early days, e.g. with Borland Delphi it was commonplace to patch the runtime library at runtime, but it did not take long until these patches had been made DEP compliant (using VirtualProtect() as I recall).
The real issue however is that some ISVs insist on eating the same dog crap their customers do. I.e. if most customers use WinXP, then by golly, the developers must use XP too. How could anyone implement ASLR support then? I remember advocating using WinNT back in the day, to idiot developers who insisted on using Win95. They were hopelessly crashing left and right with that sorry excuse for an OS, but could not abandon it because of a misplaced sympathy with their customers... It was bizarre then, and it is just as bizarre now.
I have always felt that even half-decent software developers should help lead their customers/users into the future. Be it through providing a smarter user interface, faster performance or better integration. You rarely accomplish that by sticking to ten year old technology. Most people have seen the newest flavour of MSOffice, and many of them will expect new software to adopt that particular look and feel (or something equally impressive). 64-bit Windows offers improved security (MS finally removed the feature where drivers can hook into the kernel), so that means decent ISVs should help people make the transition to 64-bit Windows. (When I joined my current employer, one of my first priorities were to make sure to help them realize they could get their software to run just fine with 64-bit Windows, something they had failed at in the past due to a basic lack of know-how)
In any case, it is sad to see how an ISV like Adobe can be so slow at adopting e.g. Win64 support for flash.
compiler switches are soooo hard to use these days...
http://msdn.microsoft.com/en-us/library/bb430720.aspx
I suspect a lot of ISVs think they don't need to care about this because they can simply blame windows if there's an attack vectored through their badly written app, but I know companies abandoning things like Adobe Reader for Foxit tools simply because the latter doesn't have the crummy code and bloatware reputation Adobe are acquiring
Despite being a magnitude lighter and less complicated than Acrobat Reader, Foxit has had some quite serious vulnerabilities. For example, Foxit would execute arbitrary shell commands embedded in a pdf automaticly without any prompt or permission. This "feature" has since been mitigated but one wonders what other vulnerabilities lurk inside...
"do a rather better job of applying DEP but this integration is inconsistent between different Windows platforms" ... I think you could equally say that DEP integration is inconsistent between different Windows platforms.
Surely it is the job of the OS itself to manage resources and sanitise requests? The way programs are designed, there's executable code, there's data, and there's the stack. For 99% of applications (excepting compilers and JITs), only executable code should be executed, and such code should not be writable. Enforce that properly, we ought to see a lot of buffer overflow type nonsense go away (buffers are writable but non-executable). Why should the application be left to cater for omissions in the OS? The OS manages memory, yes? So it should be the OS who tells the application what's up, not the other way around.
As in: apps not fit for purpose.
Sounds like a lawsuit in waiting to me.
Or even worse: lawsuits in waiting?
Linux has had address space randomization like for ever, and non-executable stack and data too. in most distros it's enabled by default, and you (well, the distro's packages I suppose) *dis*able it for the few non-behaving apps. Even when it came out, that was Java and, for some reason, emacs. They apparently both try to execute code off the stack. I'm just shocked that Microsoft ended up implementing these so these huge quantities of apps don't support them, or don't support them properly.
"I'm just shocked that Microsoft ended up implementing these so these huge quantities of apps don't support them"
Then you fail to understand the meaning of "open source". In Linux-land, if the OS designers decide to impose new restrictions on what apps are allowed to do then they can fix and rebuild any apps that fall foul of the change. This the big difference between "open source" and "free as in beer" software.
Microsoft can't move the goalposts like this. For some Windows apps, no-one has the source, certainly not Microsoft. For the rest, the customer doesn't have the source and the original ISV is unwilling or unable to make the changes, either for free or even sometimes even for a price. MS therefore have the choice of "make the new feature opt-in" or "make the latest version of Windows unable to run existing Windows apps". Guess which one of those options rakes in the most upgrade fees.
I didn't get viruses when I used Windows either. But it's not the user's fault -- Windows is excessively insecure! Using Ubuntu, I *can* download torrents, go to dodgy web sites, and do other things that I'd be a moron to do on Windows. And, no, it's not because it's less popular, it's because it has all the security features 7 "could" have but are apparnetly turned off for most apps, it has an execute bit so there's not some "click on a file and find out it's an executable" problem, and on and on. Windows has the features it needs to be secure, but doesn't use them properly... UNIX didn't USE to be so secure, but the morris worm (circa 19*88*) started UNIX devs thinking maybe they should start hardening things, whereas Microsoft didn't take security seriously until about 15 years later, after NIMDA & Code Red forced their hand.
Any OS security policy depending on the userland apps to not have bugs in their security opt-in implementation has serious design problems.
Sign up, sign up for The Register's weekly IT security newsletter - click here
