At Blackhat this year Mark Dowd of IBM and Alexander Sotirov or VMware presented a paper concerning how to bypass Vista’s Buffer Overflow Countermeasures. The paper is worth a read both because of the vulnerabilities, and because it does a great job detailing how much protection Microsoft has provided to people who can’t write good code. The analysis of the paper by various people on the Internet is mind numbing though (probably this post included).

Before continuing, I think some things need to be established up front. Vista provides protection that no other OS does against poorly written code. Even if the security features were completely worthless Vista would not be more dangerous than any other OS- just more dangerous than Vista from last month. This additional protection was meant to be a stop gap to secure bad code, not an excuse not to fix the bad code. The root cause is that some code sucks to begin with. It is like throwing a WAF on a wide open Internet app. That buffer overflows still exist to the extent they do is just disgraceful to us as an industry. We know exactly what causes buffer overflows and we know how to avoid them. Do not use unchecked buffer copies. Explicitly copy no more data than a buffer can hold (and please, please do not use inline calculations in strncpy, since that may as well be an unchecked buffer copy). Don’t dynamically create the first argument for *printf/*scanf without knowing exactly how many other parameters will need to be provided. And the list goes on. These are all things that static source code analysis tools are remarkably competent at finding. A clever source control system will flat out ban people from checking code in with bad APIs (strcpy and its unchecked brotheren). Finally, fuzz the crap out of all your input points (hey Jim, this is why input validation is important :-p). You will find and kill 99% of your buffer overflows if you do that, and the remaining 1% won’t be very discoverable (bad guys do fuzz testing too you know).

Anyway, there is a reason why MS has had a huge decline in buffer overflows relative to the industry, and it is because they do all of the above. They have too much legacy code and third party giblets to fully get rid of overflows, but all of the extra protection in Vista is primarily to provide some level of protection for the OS because a retarded third party (*cough*quicktime*cough*acrobat*cough*flash*cough) has yet one more buffer overflow that can be used to compromise the box. The protection was not a permanent fix, but simply something to raise the bar to perform exploitation, and I think Microsoft has been reasonably good about presenting it in that light while still trying to sell 3rd party developers on the protection. The biggest flaw in the protections that Vista presents is that applications opt into using them. Programs need to explicitly state they want the protection which is why the paper focuses on exploiting applications that do not have all of the protections (like IE 7 which doesn’t use data execution prevention because the poorly written piece of junk sun java plugin would blow chunks if they did; fortunately IE 8 does use it, as does firefox 3).

Now on to the commentary on the web. Peter Bright of Ars Technica tries to downplay it and many of his points are valid. Bruce Schneier thinks it is a big deal, which is true. A month ago people didn’t know how to bypass these protections but now they do. That is a big deal, but Adrian Kingsley-Hughes of ZDnet is still a moron for saying it renders Vista security next to useless.

So to respond to the commentary, the reason this is a big deal (moreso than Bright believes) but not the end of the world (as Kingsley-Hughes thinks) is that it makes exploits feasible but more costly. Any technological measure that increases the cost of exploiting something will decrease the number of instances that blackhats bother exploiting it. For example, to defeat ASLR the authors advocates hosting a .Net Web Component of sufficient size to dramatically impact how the address space can be randomized, and in order to facilitate downloads they also recommend the webserver hosting the component use gzip compression (which in turn means controlling web server configuration). That’s entirely possible, but if a malware author had the choice between an exploit targetting all of XP that didn’t require that extra work or an exploit for both XP and Vista, I suspect 90% will choose to just go after XP. (the exploit using Java applets is a bit more likely at the moment do to the GIFAR hack recently discussed, since you can very easily get hundreds of sites to host that for you).

On top of that, to bypass the multitude of protections requires some sophistication, which is just going to raise the bar on who crafts the exploits (well, until all of the bypasses are just built into metasploit). Raising the bar lowers the number of attackers capable of compromising the system.

Additionally, the easiest work around for DEP was to target applications that don’t use it, but this will become increasingly difficult, especially as MS enforces DEP to a greater degree. Finally, at least in terms of IE, one feature that was not addressed with the process isolation of the browser in Vista. It remains an open question on whether the IE sandbox in Vista is vulnerable, as it may still contain the attack.

So attacks are now possible, but the exploitability is still more difficult than other platforms. That’s big, but it by no means renders the protection next to useless. As the authors conclude

In this paper we demonstrated that the memory protection mechanisms available in the latest versions of Windows are not always effective when it comes to preventing the exploitation of
memory corruption vulnerabilities in browsers. They raise the bar, but the attacker still has a
good chance of being able to bypass them. Two factors contribute to this problem: the degree to
which the browser state is controlled by the attacker; and the extensible plugin architecture of
modern browsers.

At the end of the day, good OS design cannot completely mitigate bad code. Get rid of buffer overflows and this is all a moot point anyway. Its 2008 people, why aren’t buffer overflows extinct?

~ Joshbw

A blacklist file was found by an iPhone hacker and the internet is all abuzz over the possibility that Apple has a kill switch for applications. Well of course they do- Apple clearly shows by their insistance on the App store that they will control what gets run on the device- but I don’t think the blacklist file mentioned is that mechanism. Showing up in the location cache is a really sketchy area to put a file that blacklists applications, unless it is an exceptionally stupid instance of security through obscurity, so I think people misunderstand what it is for.

Now if I were Apple and I wanted complete control over what ran on the device I would only allow the device to run signed applications so that both the identity of the app author can be checked and the integrity of the binary can be scrutinized. I would insist on being the only CA, which I could do because all apps have to go through my store *anyway*, so why not include issueing certificates in the whole deal. I would then publish a certificate revocation list via SMS at regular intervals so that the user has no control of when an app gets blacklisted and I can count on it being pushed to the device.

This isn’t a foolproof design but it does provide pretty decent control over the platform. In essence it isn’t really any different from what console manufacturers do. People seem willing to accept that they don’t actually have control over the device the bought, and have certainly been willing to deal with the draconian oversight of cell carriers for years, so they would very likely accept this from Apple. So what if they suddenly lost they ability to use an application that they ultimately purchased from Apple?

Is this what Apple is doing? I don’t know. But given their aims it seems the best way to do it. I hate touch screen interfaces no matter how slick they are done, so I won’t be investigating myself.

~ Joshbw

A couple months ago I had a bit of an argument with an Opera developer. He was critical of MS with IE 8, because IE 8 will not pass cookies when doing a cross domain XHR. Like everything from Opera the argument is that it deviates from the standard, and as they like to toot their own standards compliance horn as their marketing message this is pretty much their primary form of criticism against any browser. I had a problem with this, because the concept is inherently flawed and I do not believe that standards (and lets be clear, when they say standards, what they mean is specifications, and not even very well written specifications) should be blindly followed when in contrast to security considerations. This could diverge into a general rant that I have about the W3C not being an effective body to begin with, producing neither horribly useful documentation, nor having an appropriate method to settle on specification to begin with, but I will save that for a later date.

Anyway, Cross domain XHR that passes cookies allows for private data to be retrieved off of remote sites, which is problematic because it only provides a mechanism to authenticate the user (and not a particularly strong one) but no means to truly authenticate the original site who served up a web page with the XHR (oh sure, you could check referrer headers and other such details, but the integrity of those are always suspect; it also increases the impact of XSS). It enables client proxies to 3rd party websites by design; website A asks client to retrieve data from website B for it. There is already a mechanism for two trusted domains to share information; federation and webservices. That way both endpoints as well as the client using the browser can all be authenticated. Yes, this requires more work. Doing it correctly always requires more work than doing it wrong.

Some websites will implement this all correctly- they will be very careful what data they let slip, what actions are exposed to cross domain XHR- but most will not (come on, they can’t even get input validation on their own forms right). It is like justifying the continued use of strcpy in place of strncpy because it is possible to use it correctly and it is just a pain to force developers to specify the buffer size. We as an industry know that we should ban strcpy, because even though it *can* be used safely, it is very common for developers to make mistakes with its use. The same can be said with cross domain XHR- it can be used safely but there are better methods available that inherently enable the developer to be more safe.

Anyway, I bring this all up because Window Snyder of Mozilla fame announced at Blackhat that, while it was pulled from Firefox 3 for security reason, Cross Domain XHR will be added back to Firefox 3.1 and pass cookies. I was very much hoping that both IE and Firefox would implement a safer XHR that did not pass cookies when going cross domain, but it appears that only IE 8 is willing to err on the side of security. That’s too bad. Fortunately NoScript will probably come to the rescue but I am really tired of having to rely on third parties to provide security for something that should be there from the start.

And Opera, sorry, I never was confident you were secure, especially since you don’t freaking star out password fields on your blackberry client, and the Cross Domain XHR only exacerbates things.

~ Joshbw

It is now Joshbw, CISSP. I don’t think the cert says a great deal specifically about my App Security knowledge, that being a ten mile wide, inch deep sort of certification. The test wasn’t any less a pain because of it though, and at least it says I have the fortitude to make it through the long nights studying the optimal height and candle power of external lighting, how far away backup facilities should be, 8 million different security models, and what the initialization vector length of each encryption algorithm happens to be.

~ Joshbw, CISSP

Ars has their panties in a twist because Kevin Turner dared to suggest that vista is more secure than OS X or Linux. The thing is, from one point of view, Kevin is absolutely right, but from other points of view he is wrong, which just points out the general failing that keeps popping up among security folks: How on earth do you measure security?

When talking about security there isn’t a clean metric.  You have

Vulnerability: Software (for this purpose) weakness that provides a door in
Threat: danger that someone will find the vulnerability
Risk: the likelihood and cost of the vulnerability being exploited
Exposure: time that a vulnerability remains

Companies/orgs love to cherry pick which one they go off of.  Firefox is big on touting their low exposure while being horribly quiet about the number of vulnerabilities.  Microsoft is big about vulnerability (and to some extent exposure, at least on the OS level) count, since they do have a much lower count then competitors that don’t have a decent secure development lifecycle (which would be Apple and most of the OSS projects), but they don’t like mentioning risk because they have more risk than freaking anyone.

The problem is, all of these approaches are at least a little right.  Sure the risk is huge on windows as a whole, but if you install patches quickly your risk is actually pretty low, and with a lower vulnerability count there is less likelihood that someone will release a zero day for a vulnerability that isn’t patched. Mozilla is also right about firefox being more secure, as the fast patch and deployment rate means that zero day isn’t going to remain a concern long (except that they have been a little too quick pushing patches and have regressed things on a number of occassions), but their higher vulnerability count does mean zero days are going to crop up more often.

The only stance that isn’t right is one that throws out vulnerability count as a metric because of “more eyes” (which I have complained about before). Being open source may mean that more good guys have access to code reviews, but it also means more bad guys can get a leg up looking for flaws. The number of known vulnerabilities is ALWAYS a problem regardless of why they are there (incidnetally, again, that more eyes arguement is crap. Code reviews are a horribly inefficient way of finding flaws, and you never know when some poorly trained reviewer will comment out the functionality that actually makes your random function random).

So if all of these are a little right, what is the problem? I think it is really twofold. First, it makes it very hard to make an informed comparison of two platforms in terms of security and best fit for your org. Second, it makes it hard to gauge your own security and communicate that to people in and out of your organization. Both are pretty important, and a common, informative, metric benefits everyone (except those that look bad because of it).

Thinking about it I like:

[Ʃ (CriticalityModifier * Exposure)] / (nTotal * 10)

or, in English, the sum of Criticality of each vulnerability in the past twelve months * the number of days that the vulnerability was unpatched (patches that get rolled back don’t count), then divided by the total number of vulnerabilities times ten, to scale down the number a bit.

The criticality modifier is 0.5 for low, 1 for moderate, 2 for high, 3 for critical. As an example, if a hypothetical product had the following vulnerabilities over the past twelve months:

would give you (3*45 + 3*35 +3*4 +2*20 + 1*45 + 1*50 + 0.5*145 + 0.5*75) / (8 * 10) = 6.15 Security Rating.

This seems like a fair metric, as it measures a level of impact (the criticality, though this isn’t horribly quantitative) of the flaw, the days of exposure to the flaw, and the number of total flaws. What it does not take into account is likelihood, as I can’t come up with a good quasi-quantitive means to measure said likelihood (open to suggestions here).

Thoughts?

~ Joshbw

There are some interesting posts coming out of the IE 8 team on security and I think it is heartening that the two major browser manufacturers are viewing security as a competitive feature (now if only Safari would…). The big news seems to be the default XSS filter to protect against reflective XSS. You are still screwed with persistant XSS but at least we are making ground. There has been some noise that MS is just aping features from NoScript, for which I say, GREAT! One browser shouldn’t be bared from a great security feature just because someone else thought of the protection earlier, and this has the benefit of being installed by default (if what happened in one browser was blocked from other browsers the whole XHR wouldn’t exist; that was an MS innovation after all, even if it wasn’t native).

The blog posting has several folks that are worried about false positives, but I think they either don’t understand how reflective XSS works, or they are concerned that their insecure webpage will be broken. The filter seems pretty simple; if content in a request is echoed unsafely in the response it is flagged. Just because some webpages echo intended content that way does not mean that they shouldn’t be flagged. I think the “false positives” might actually be a selling point as it will point out to web developers where they have been remiss.

Just as interesting is the smörgåsbord of security controls discussed in the follow up post. I’m sure MS will probably catch flack for deviating from the standard, but my hope is that the functionality becomes the standard. Good client side input validation functions (toStaticHTML) are a great idea, as are many of the other features (I wonder how secure anyone can make mashups though; they are a fundamentally horrid idea from a security perspective).

Anyway, let the race to a more secure browser commence. Competition is good for everyone.
~ Joshbw

Ars Technica has an article on four things that need to be fixed to secure the future of the web and I find it a horribly depressing list. The only marginal nod for security is security considerations in integrating JSON fully into the gecko rendering engine.

I think this points out a fundamental issue with security on the web; web developers just don’t think about security. It isn’t on their radar. The list is four things that web developer want to do “cool things” with, but black hats are going to be equally happy to do “cool things” with the technology and no thought has been given to that.

Instead of the list provided, I offer more generic fixes I would love to see to ensure a bright future for the web:

1) A truly stateful protocol replacing the stateless HTTP and the cookie session ID hack that we are using now. The current system is fragile and easily compromised; it is the definition of kludge but everyone goes along with it.

2) End to End trust, not based on trivia. Forget usernames and passwords; let’s develop a means for the server to verify the identity of the client and vice-a-versa, to kill phishing sites and role your own retarded authentication/forgot password scheme. What we really need is the equivalent of two way SSL, but in a more portable scheme for end users.

3) simplification of the tiers. Complexity is the enemy of security (I have a lot of enemy/bane/unfriend of security criteria, but complexity is definitely one) and the tiers have seriously made things complex. I have an HTML event trigger a javascript function that makes an XML request to a JSP that communicates to an EJB which performs an RPC to a mainframe to ultimately execute SQL, and then backtrack. There are so many points of failure in this scheme that I feel like weeping.

4) Make people care about security. I really want to go off on the dynamic languages, since they are all about speed to market at the expense of good, secure, code, but the real issue isn’t the languages but the mentality that speed to market can’t afford secure practices. We need to make executives and developers and marketing and customers really care.

so what are your top 4 for things to save the web?
~Joshbw

Blizzard, makers of the extremely popular World of Warcraft game, now offer a token based authentication scheme to help with account hijacking. Two things strike me about this, first, that this is a freaking crazy world when hijacking WoW accounts is serious enough business to warrant this security and second, that we fundamentally need a better way of asserting identity when a FREAKING VIDEO GAME REQUIRES A TOKEN. I wrote a screed about that here, but I think this accentuates all the more a need for a new end to end method of asserting identity and establishing trust.

~ Joshbw

Perhaps I was a bit misleading in the title as this is a flaw in an internet connected coffee machine (why, oh why, do we need this) that allows, among other things, access to a connected PC.

There are a couple lessons in this. First, no matter how trivial your product, you very likely still need to worry about security if it connects to something that does have value. Second, your system is only as secure as all of the systems that connect to it, unless the system is inherently paranoid about connections. In this web 2.0 world of mashups, in the world of connected enterprise applications, our applications are not living in a bubble. They are connected to multiple other systems, and in most cases there isn’t a whole lot of thought that went into security over these connections. A web application may be horribly paranoid about anything it receives from the user, but then blindly accept data from internal systems without a thought. If any of those systems is flawed and you don’t validate input from them, your application is just as susceptible to attack as it would be if it didn’t validate user input.

This just further cements in my head the need to push threat modeling out to more people. I think the real value of threat modeling isn’t the complex threat trees that get built for risk analysis. I actually find those pretty worthless. I think the data flow diagram is the big thing. It is a convenient visual diagram showing where a process or feature is pulling data from and where it is sending the data to. Any source of data is a source of attack, and the DFD is a useful tool for identifying where further scrutiny is necessary. Any output source is a particular asset that might be attacked through your application. I think every dev spec should require a data flow diagram simply because it gets people thinking.

Finally, the last immediate lesson from this is that it is a scary time to be a client. The OS may be pretty solid but there are a million ways to execute code that seem perfectly valid from the OS point of view. Every connected application, any application that pulls data or opens data originally from a remote source, is a potential open door. If a freaking coffee machine can be a source of attack client security is in a lot of trouble.

~ Joshbw

Apple just released an update for quicktime, no surprise there. Doing some digging I found the five security issues patched:

Playing maliciously crafted QuickTime content in QuickTime Player may lead to arbitrary code execution

Viewing maliciously crafted Indeo video media content may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted PICT image file may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted AAC-encoded media content may lead to an unexpected application termination or arbitrary code execution

Opening a maliciously crafted PICT image file may lead to an unexpected application termination or arbitrary code execution

Five exploits, all in how a variety of media (video, audio, and picture) parses code. This tells me two things pretty much immediately- 1) Apple does not do a great deal of Fuzz testing on their formats, but researchers are happy to do so for them and 2) if I do fuzz testing on quicktime myself I will probably find something exploitable as well.

Fuzzing is a horribly brute force method for security testing. It requires a lot of work to wire things to adequately monitor an application (you want to see memory spikes, process spikes, and all of the myriad of crashes) and automate the loading of media. Regardless, it is very effective at breaking parsing and validation code. Microsoft requires 100,000 iteration on all parsed formats. For complex formats (office docs, media files), they basically never stop. Apple would be well served by doing the same (or caring about security at all).

Fuzzing is also applicable to web apps. They process an immense amount of data from end users, and other than specific known attacks done by pen testers, most companies don’t seem to test for various malformed input. The problem is that it is very hard to detect where and why something failed when fuzzing a remote machine. It would be nice to see a good distributed testing harness that can monitor the application state on the server and produce decent debugging logs.

~ Joshbw