Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 2:33 UTC (Fri) by spender (guest, #23067)
In reply to: Walsh: Introducing the SELinux Sandbox by hozelda
Parent article: Walsh: Introducing the SELinux Sandbox

A couple comments:

As mentioned on the PaX site, Microsoft has DEP (their HW-based PAGEEXEC implementation) and (a weak) version of ASLR. I had remembered reading that Server 2008 would prevent a service from respawning for a period of time if it had crashed multiple times within a short period of time (deterring bruteforcing of ASLR -- something vanilla Linux doesn't have yet) but when I went to look for a link about it last, I couldn't find one.

EULAs don't stop security researchers from doing their work, nor does not having the source. Reverse engineering has advanced quite a bit in the past couple years, as well as the state of art in decompilation. Tools like BinDiff makes vulnerability finding in patches much quicker, while the Hex-Rays decompiler does a decent job of turning x86 assembly into C-like code. The Windows implementations of DEP and ASLR are pretty well documented publicly. Several companies have published papers on them and techniques for defeating the protections (for instance, it took a while for both Microsoft and Linux vendors to figure out that having a make_stack_executable() function without any safeguards wasn't such a good idea).

I sometimes wonder if there's a 'bystander effect' or 'free rider problem' involved with the "many eyes makes bugs shallow" view. There's a lot more people having a feeling of security based on the assumption that other people are reviewing the source instead of them, then there are actually people reviewing the source. The reality is, even though you have the kernel source, I'm pretty sure you don't audit it for security vulnerabilities, and if you did, it'd be impossible for you to audit every single line of it yourself. So in the end, you're putting trust in some entity, whether it's Microsoft or Linux vendors. It's naive to think Linux vendors are somehow unlike Microsoft in that they don't care about their stockholders -- everyone's in it for the money.

I wouldn't bet the farm anytime soon (though you've restated the challenge, which was initially Microsoft employees vs employees of Linux vendors, collectively) -- I know quite a number of people in the security industry. I can name several exceptionally bright security experts working for Microsoft, but can only think of one among the Linux vendors, who works for SuSE. Indeed, there are other bright people in the industry that work on Linux security -- Julien Tinnes and Tavis Ormandy come to mind, but neither of them are employed by a Linux vendor. To me, that says something. After all, security should should be the responsibility of the vendor, not Google; just as it's Microsoft's responsibility, not Mcafee's or Symantec's. Also, as far as the commercial security industry goes, there's far more people looking for vulnerabilities in Microsoft's software than there are looking at Linux -- simply because exploiting Microsoft software is more profitable (the same goes for underground exploit writers).

Regarding:
> That's an unfounded statement. Linus and many Linux developers have
> taken security more seriously than many that will ever pass through
> Microsoft.
you've apparently missed several past discussions both on here and LKML. It's pretty much agreed upon by the security industry that the official policy of the kernel developers (intentionally covering up security vulnerabilities by fixing the bugs without mentioning security impact that they're aware of) is damaging to users. Linus was nominated last year for the "Lamest vendor response" award: http://pwnie-awards.org/2008/nominees.html#lamestvendor

You mentioned not knowing about what Microsoft ships in their updates -- in fact, the security industry has a pretty good idea about what's being shipped in the updates. A huge number of exploits are written based on diffing an old binary with a newly patched binary. Though silent fixes could easily work their way into a service pack, it's harder to work one into the small patches that go out each month. The patches that are released are marked as security fixes. Sometimes obviously they get their security classification wrong and rightly get called to task for it. Of course, they seem to do a better job of it (again, this goes back to why it's important for the Linux vendors to have security experts on staff) than the tendency to call most vulnerabilities in the Linux kernel just "denial of service", when they're exploitable in reality. This has been commented on several times by several security experts. Three examples:
http://kernelbof.blogspot.com
http://www.security-express.com/archives/bugtraq/2006-07/...
http://securitywatch.eweek.com/exploits_and_attacks/inter...

> Closed source is magic. I don't trust it.

In summary, everything is magic -- verify ;)

-Brad

to post comments

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 3:10 UTC (Fri) by spender (guest, #23067) [Link]

Small update:
Though I still can't find the original link I read where it discusses "windows service recovery" as a useful/necessary addition to ASLR, I did find: http://technet.microsoft.com/en-us/library/cc262589.aspx
which shows how it's configured. By default in Windows 2003 and up, a service is allowed to crash 3 times, with a minute in between crashes. After the third crash, the service won't be restarted (thus deterring an ASLR bruteforce).

Given the recent discussions on LKML of quality of randomness for ASLR, I'm surprised no one brought this up. After all, randomness quality isn't of huge concern when nothing stops you from running your exploit as many times as it takes to get the addresses right. Nergal wrote his segvguard module years ago when he wrote his classic ret2libc paper, and similar code has been in grsecurity for years as well. Even if a kernel solution isn't used, it seems like it'd be a good job for a TCP wrapper like xinetd. That still doesn't help suid binaries, though.

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 5:03 UTC (Fri) by hozelda (guest, #19341) [Link]

The EULA does slow down work.

I also think you might be a little over-enthusiastic if you were suggesting that the reverse engineering jobs being undertaken will rival source code access. Just consider the amount of work produced per unit time by the FOSS world vs. the "useful" work being achieved by the underground or by the research world focused on Windows. Clearly one type of work is much more difficult (ie, the one without source code access).

You have high esteem for the top researchers but perhaps miss out on the value and contributions from those not known in the industry. Not to drag SELinux back into this, but a bug fix can have many repercussions, including fixing security issues in the making (not yet analyzed by black hats or even by expert white hats because of information overload). Many people work on their concept of correctness and don't stop to categorize something as security related.

Remember that it takes much more time to develop an exploit usually than it does to fix the bug. With two competent parties analyzing code, which is more likely to finish first, on average?

In fact, you get something of a race to reporting bugs in the FOSS world (to at least get credit) because it is so much quicker to do this than to build an exploit. In the closed source world, you have lots of time to build the exploit with much time left over to craft a business plan around the series of exploits you will build.

Also, the number of eyeballs matters. There is a reason FOSS is quick to fix problems and many times anticipates them, one way or the other.

Of course, if the reverse engineers had done their jobs (assuming it was easy), then they would be patching Microsoft's software for Microsoft just as quickly as is done for FOSS. [I was being facetious.]

You mentioned all the work being done for Windows. Well, I think as time approaches infinity, we see people moving off Windows and onto the more transparent Linux. Research advances more when you have access to the most information possible and then try to fill in those fewest number of remaining holes. This obvious conclusion is among many not escaping those slowly but surely moving to support and contribute to FOSS.

Mainly with Microsoft software in mind, I say that you don't need to (eg) overflow a stack to subvert security or disrupt privacy. You can do it right under people's noses, and it is difficult to catch this because nothing unordinary is happening among an ocean of more unordinary stuff flashing by at hundreds of millions of ordinary instructions per second or faster.

In short, I am not going to be convinced that the reverse engineering job is keeping a check on Microsoft no matter how many tools you mention, nor am I going to be convinced that reverse engineering is comparable to having source. It's one thing to find flaws (diff to help you out, etc). It's another to verify things are correct or are not misbehaving in places you haven't looked. Finding a gem vs accounting for everything in the land. [And surely, the tools don't get as much information as source code+binaries]

To belabor the point.. RE leads to much more information overload. You filter out much to focus on things of interest. If 80MB source patch for Linux is tough to follow.. if everyone is trusting everyone else to see source as you stated.. then how much more difficult is the case when you don't have source yet have lots of changes in binaries. Remember that binaries are updated while the system is running with no need to announce what is going on. The system software can piggyback on any network conversation in any way it wants. It's too large a space to track which is why just looking at the network is not enough, and the binaries clearly have not been deciphered completely. Spotting problems in diffs is much easier than understanding the base. How well does the research community know the Windows base? I don't think nearly well enough. [Eg, you invoke things that Microsoft themselves have stated about their products rather than pointing to an analysis of their binaries to actually show/prove X or Y property is there. With sarcasm.. Don't the reverse engineers know all about Microsoft products the way we know about Linux? Why can't we point out where Microsoft does this or that in actuality (not in theory nor in their marketing nor in their purposely scrapped projects), as we can for Linux, but instead rely on their cribnotes to the public? What kind of checks are those? Who cares that these dissembling tools have progressed "hugely" recently?]

As concerns Red Hat being a public corp just like Microsoft, I addressed that already by saying that the issue is about checks and balances (we look towards their businesses for that.. one relies on openness the other on closedness) and additionally that Microsoft has monopoly profits to protect.