It was a legitimate dispute, one where Sun was (legally) right and MS wrong. Microsoft had agreed to a license and obviously wanted to do something which they were barred from doing.
I'm not claiming that Sun was in the wrong. Far from it. They had their platform to protect - which they did. Microsoft wanted to use Java - but obviously not at any price. They had obvious qualms (shared by IBM years later) and wanted to stretch it. They failed and paid for it. I for one think that justice (as in the correct verdict) was served.
What I have issues with it the revisionist painting this as some sinister attempt on part of Microsoft to try to extend and then extinguish Java. I coded C++ at the time and could certainly see how Java made me more productive. But at the same time AWT was a real pain. And slow. I totally digged Microsofts position at the time.
At the same time I can also recognize Suns position. If the "Windows bindings" could not be successfully replicated on other platforms (e.g. because 3rd party Widgets were not available) that could present a threat to the pervasiveness of Java.
Sometimes the plans do not reconcile. That's what happened. They went separate ways, one ending up a less fortunate, however.
Even though the legal vehicle is different this time around (Oracle claiming patent infringement rather than license breach), you could really see this as very similar suit: Oracle needs to fight forking and fragmentation of the Java platform. That would dilute the value of a very important asset (Java).
Uhm, Paul Allen is not Microsoft, nor is this company owned fully or partially by Microsoft. Rather they have a common owner, Paul Allen - that is if Paul Allen still owns Microsoft stock - which I presume.
But saying that this is a Microsoft deed is a stretch. Microsoft had no hand in these patents.
But if mr. Allen still owns a lot of Microsoft stock, suing MS would be a bit like suing yourself. A bit awkward.
It doesn't matter how much they assure that they won't go after free implementations. Without it written in legalese, irrevocable, it's a worthless statement.
It is written in legalese. And it is actually quite a bit stronger than a license as it does not require the beneficiary (you) to accept any license agreement. The legal term is estoppel. Here, look it up: http://en.wikipedia.org/wiki/Estoppel.
From Microsofts community promise (emphasis mine):
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification ("Covered Implementation"), subject to the following: [...]
Now, could that term "Necessary Claims" leave Microsoft with a legal loophole they could wiggle through and sue anyway? IANAL, but it certainly doesn't appear so, as the only way Microsoft could claim that your infringement on one of their patent wasn't "necessary" would be for them to demonstrate what you could have done. Remember, this is a one-sided promise, the burden would be on Microsoft to demonstrate how you would fall outside of the patent coverage.
Now, this promise covers C#, the common language runtime, common type system and core libraries such as collections, P/Invoke etc. It does not cover some of the framework parts higher-up in the stack, such as WPF, WCF, ASP.NET.
It is still unclear to me how implementation of such APIs would be more prone to infringing MS patents than implementing the same functionality on other platforms with other languages. Remember, you cannot patent an API, you can only patent an actual "machine" implementation. Surely if some critical part is covered by a software patent, said patent is language/platform agnostic.
It appears that the problem Google has with Dalvik/Oracle is precisely covered by Microsofts legally binding community promise. See, Google has no interest in implementing a full Java SE. And they had no interest in paying license fees to Sun(now Oracle) for an official JavaME. So they wiggled around and made their own platform in a way which has opened them up to litigation from Oracle.
Had they gone with Mono instead of Dalvik (remember, Dalvik was merely a way to wiggle around Java licenses) there would have been no license fees, and no patent infringement.
Uhm, Silverlight is pretty much.NET. Silverlight 4 comes with a large subset of the.NET framework (the bits for making server apps have been left out, think ASP.NET). Since Silverlight 2 (IIRC) you can program the code using C# or any other.NET language, like VB.NET, IronRuby (yeah, I know), IronPython or JavaScript.
Silverlight is also fast approaching parity with the full WPF framework.
At the time Java came with its own set of widgets, and it had a terrible reputation (deserved) for being slow. At the center of the conflict was Microsofts insistence that developers should be able to use native Windows widgets for GUI apps - otherwise it would risk tainting the Windows platform as slow and unresponsive (yeah - I know - even slower, ok?).
To facilitate that they wanted developers to have the option to call native APIs directly. Library developers would then be able to make abstraction libraries which could take advantage of the rich Windows GUI (and COM) controls.
Sun would have none of that. Microsoft wouldn't yield. Microsoft lost the lawsuit, and then went on to make a language the way they felt it should be made. With a way to call native APIs which is leaps and bounds better than the nazi-abstraction of Java. No glue code necessary, just pure metadata annotations.
Sun went on with their own business and along comes IBM with Eclipse. Only IBM weren't too happy about the whole Swing deal. Java has definitely improved in speed, but on the GUI side all those gains (and more) had been eaten up by Swing. So IBM went for native GUI widgets with SWT.
There was a reason Microsoft didn't want to fix their JVM so that it would pass the compliance tests. They lost (or settled?) and Sun got an insane amount of $$$. Microsoft created C# and.NET the way they though it should be.
C# has evolved much faster than Java. And in some areas Suns "doubts" about whether such language features were feasible has been put to shame: Delegates, operator overloading, Native API (P/Invoke) marshalling, reified generics, value types etc.
and with Windows 7, it appears (from what I've read) if you want do any sort of work, you still need to use C++.
You read wrong. You can program against any API* using C#. Mind you, C# can also be used in "unmanaged" (they call it "unsafe") mode - where you have access to pointers, pointer arithmetic, direct memory allocation etc.
All regular APIs are either COM or have already been wrapped or even re-implemented in.NET..NET can easily interop with COM APIs.
I believe that the only place where you would want to drop top C/C++ would be for device drivers.
Except that Microsoft is *not* moving away from dynamic.NET languages. They just released a platform unifying and solidifying dynamic language support within the.NET Framework itself.
This support is head and shoulders above anything else. Imagine that the platform and not the languages actually has services for doing dynamic member lookup with advanced caching and global optimizations. Making a platform which generalizes how different dynamic languages such as EcmaScript, Ruby, Python and C# look up members is no small feat.
It means that the language implementations themselves shrink quite a lot.
What we have on one hand is *one* disgruntled ex-Microsoft employee being cited on Microsofts plans for the future. On the other hand we have concrete and recent actions by Microsoft which suggests that they are very much investing in making.NET a dynamic multi-language platform.
I have no doubt that working with implementing an "outside" language inside an organization like MS is an uphill battle. But I have real problems seeing this as a sign that MS is backing away from dynamic languages.
I just got stuck on your explanation about locks; moving locks around wouldn't help, because the malicious code does not need to respect any locks.
You are of course correct. A lock will prevent nothing. If there weren't multiple cores one could prevent the process from being preempted during the critical section. But that is moot now.
Agreed. As I tried to say (perhaps a little convoluted) i expected this copying to happen. But some seem to believe that SELinux will protect against malicious code executing in the kernel. Such code can call APIs directly and can modify kernel-allocated structures. If you can do that, security hooks become moot.
DQUOT_INIT(dir);// line 1887
error = dir->i_op->mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
return error; }
Line 1874 is the "old" permission check.
Line 1883-1885 is actually the SELinux hook. Note how this is a restrictive model rather than an authoritative model, i.e. it doesn't encapsulate the operation. It merely checks to see if you are allowed to perform the operation before proceeding with the very same arguments which were passed to the function (e.g. dentry
Line 1887-1888 is the weak spot. If I were an attacker who passed the "dentry" structure to this function I could still hold a reference to that structure. And holding the reference, I can overwrite the memory. If I time my memory write correctly (easier to do on a multi-core processor where I'm not even required to preempt the first call) I can inject my own parameters *after* the security checks. In this case I can create new directories wherever I want.
Remember, this is *not* something I claim you can do from userspace (haven't investigated that), but from within the kernel this is entirely possible!
I fully expect Windows to be vulnerable to similar attacks from within the kernel.
My gripe is how SELinux is expected to be able to confine malicious code which is already executing inside the kernel. It is a speed bump at best. Code running inside the kernel can modify all writable memory. Certainly it can modify memory it allocated itself.
Note, this is not an attack which is made possible by running as root. You need to be running in kernel - and then it doesn't really matter whether you run as root or not.
Workdays was important because that is what was used in the responsible disclosure guidelines. Which recommends waiting 5 workdays of non-communication before taking a vulnerability public.
Responsible disclosure which Google strongly supported until one of their researchers broke it:
From Googles website (emphasis mine):
"This process of notifying a vendor before publicly releasing information is an industry standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to better protect our users by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure. Our Security team follows the same procedure when we discover and report security vulnerabilities to other companies.
Tavis Ormandy knew this. That is why he made a stupid claim that acted in his personal capacity, not as a Google researcher. Even though he used Google resources, Google colleagues and Google paid time.
Also I see no technical discussion of the problem on any of the links you posted, nor any steps that can be taken until MS gets a update out to fix it.
The technical info is there. If you cared to follow the "fix it" links from their blog entries you would see that they designed workarounds.
But the interesting thing here is that after this debacle, 60 days was put forward as an absolute maximum a vendor should spend analyzing and designing+implementing a fix for a vulnerability. With this Linux bug we see 2 groups need to sit down together to work things out. And they spend 60 days before the distros got their hand on the fix. Just interesting, that's all. This was pointed out by the GP of the post I responded to. And he was immediately attacked.
Here is a novel idea: Stop misrepresenting what actually happened and stop ad hominem attacks questioning posters' motives.
Microsoft took five weeks to prepare the Ormandy patch. During that time, they made no comment - there was no transparency into whether or not it would be fixed.
They made no comments? Did you actually look or did you just assume?
Tavis Ormandy reported the issue June 5th (a Saturday). He wanted MS to commit to a 60-days timeline.
Tuesday (a busy patch Tuesday, no less) MSRT get back to him and say they can present a schedule the upcoming Friday, June 11th (which is less than 5 workdays after the bug report).
Not good enough for Ormandy he goes public immediately, Wednesday June 9th on the 3rd workday after reporting the bug
August 2nd Microsoft updates the bulletin from July 16th,
Hardly a "no comments" approach. If you click through those posts I think you'll find them smack full of info. And I've even excluded their communication on the preliminary "fix it" tools.
Admit it. You are biased, but not classy.
Like your misrepresentation and ad hominem demonstrate more class?
It seems to me that it is indeed interesting that this fix was 2 months in the making (responsibly disclosed). And that is only measuring the time until the kernel had been fixed. Now the distros would have to pick up on it and perform their own regression testing, prepare packages/updates etc.
GP did raise some really interesting questions. For some reason you chose to disregard them right away and go straight for the mans posting history.
Will you be publishing stats on my posting history as well. Am I a shill, too?
I don't get this blind trust in SELinux can do what it was never intended to do. If you compromise the kernel - especially a monolithic kernel like Linux - it really is game over.
Practically every security check (and - yes - that includes SELinux extra hooks) are performed before the actual operation is performed with no kernel lock covering both. Which means that *all* of them are susceptible to concurrent access attacks.
It works like this: The malicious code invokes the syscall passing a structure, e.g. an inode but at the same time the malicious code starts a second thread which after a measured period (clockcycles) modifies the very same structure. By crafting this carefully the attacker can hit the "weak spot" between the security checks and the actual operation. It doesn't work every time due to obvious nondeterminism, but even a 30% hit rate will be exceptionally good in a mass attack.
And you cannot lock down the tools used in this scenario. All processes will need to access memory and spawn threads. Certainly browsers, X servers, pdf readers etc. do.
This is not a bug in the kernel. Avoiding this weakness would involve bigger locks and critical sections which would seriously impede scalability. It is just that the kernel was never designed to withstand attacks from within the kernel itself.
So please stop peddling SELinux as a silver bullet. Once an attacker is inside the kernel it really is game over. SELinux doesn't fix that. Nor was it intended to.
Yeah, Mono would have been safer in a way since Microsoft had patent agreements because it was properly standardised, but that wouldn't make it 100% safe from patent threats from anyone (including Microsoft, who could have used patents covering the implementation using methods that weren't part of the grant).
The Microsoft community promise is open-ended. It does not specifically mention patents, rather it pledges that any necessary patents are implicitly granted for the purpose. You can read this as both good and bad.
Good: Microsoft is not holding any hidden cards, it is not a trap, they cannot suddenly rush out and hit you with a patent (like Oracle did).
Bad: If you implement in a way which cannot be said to be "necessary" or "the only way" *and* infringes on a MS patent, yes then they could theoretically claim that you did not receive grant for that particular patent implicitly with the promise.
IANAL but I would assume that the latter would be a very hard case for MS to prove, since the grant in the first place clearly was only for implementing the spec (i.e. you cannot use the grant for any other software) with the sole intention of liberating implementation from fear of submarine MS patents. Essentially the can only prove it by demonstrating that the patented "invention" was not necessary by presenting a non-infringing implementation.
Suffice to say that had Google built upon Common Language Infrastructure (CLI), C# and associated core libraries a similar situation would not have been possible. Microsoft has made a legally binding "promise" (legal term estoppel) that they cannot sue for infringement of any patents which covers the specifications. On top of that, Microsoft has open sourced.NET Micro Framework with similar patent grants. Oracle's legal leg here is that Dalvik is not covered by patent grants associated with OpenJDK, because it does not live up to the requirements - e.g. it is not a full Java SE implementation and it has not passed the compliance cert.
So why is it exactly that you think Mono is such a bad example? Seems to me that if you cut away all of the FUD thrown at Mono, Miguel was right all along: The CLI and C# is absolutely open and safe from MS patent litigation.
It is correct that some of the higher level parts of the.NET Framework are *not* covered by a similar patent grant. These are parts such as ASP.NET, WCF, WPF. All of which are either irrelevant or over the top for a small-footprint platform.
Even if you implement these APIs, it is not clear that MS has patents which would disallow that. You cannot patent a public API, you may be able to patent an implementation (a "machine").
Hum. Microsoft did this with Vista. Since 2006 (part of UAC) Windows supports file system virtualization for designated processes. Look it up. Since some (poorly designed) applications used their installation folder for storing/exchanging data between users a virtualized process will not be barred from writing. Instead the write goes to one of the user's directories.
You are correct, Tavis Ormandy claims that he acted on his own. Which is a fair claim, except:
Tavis Ormandy is employed by Google as a security researcher - so this is what he does for Google
Tavis Ormandy used Google time and Google resources when researching this vulnerability - whether this was his 20% project or not.
Tavis Ormandy communicated with fellow Google security researchers using their time and resources. He even thanked them publicly in his disclosure.
If Tavis Ormandy was employed has a piccolo or cook maybe Google could get away with disassociating them from his behavior. But not when he does exactly what they pay him to do.
If you really want an operating system based solution, you could make a separate "acrobat" user (which doesn't have any read/write permissions), run Acrobat as this separate user and do a "sudo" whenever you want to allow acrobat to read/write to a file on the filesystem.
Or you could add operating system support which would allow a program's manifest to declare that it is internet-facing and should run with lower privileges than the user launching the program, i.e. stripping the user's writing permissions and limiting reading rights.
To avoid the program (if taken over by an attacker) misusing the permissions for e.g. unsolicited downloads to an otherwise allowed download location we could restrict the process so severely that it would need another process to marshal files in and out. We could then ensure that this other process interacted with the user to make sure that he/she is aware what is going on.
In the real world you'd create an Apparmor or SELinux profile which only allowed it to write to a few places and that would be it. Unless you're on an antiquated OS like Windows, anyway.
Uhm, you do realize that SELinux was developed for Linux because the Linux antiquated (inherited from 1960' era Unixes) security model was woefully inadequate? Only with SELinux did it become acceptable for government agencies to use Linux. It was missing basic security features such as ACLs.
Loadable security modules like Apparmor are necessitated by the fact that Linux permission system is, well, not very granular. Basically without a LSM you can only secure file system objects (and anything you can turn into a pseudo file system object).
Privileged operations in Linux are reserved for root, so to call those you need to become root. You cannot grant individual privileges like you can in Windows. Which leads to the idea of setuid and setgid which are security design problems akin to ActiveX: Hand over the keys to someone (you trust) and hope that he is well-behaved and doesn't contain vulnerabilities, because a single vuln can leads to a system-wide compromise.
Tavis Ormandy reported the bug to Microsoft on a Saturday and wanted Microsoft to commit to a 60 day timeframe.
On Tuesday (a patch tuesday, mind you) Microsoft told mr. Ormandy that they would be able to present a plan the upcoming Friday - i.e. 3 days later and 6 days after the bug had been reported.
Wednesday mr. Ormandy went public.
Microsoft *never* refused to commit to a timeline. They didn't commit to a timeline within 3 days, so 4 days after reporting the bug mr.
Ormandy went public. If he truly believed that 60days would be reasonable he could just have informed MS that he would go public exactly 60 days later. But no, Ormandy just needed an excuse to go public and show the world how much smarter than Microsoft he is.
60 days may seem long, but it is actually very close to the current average for the largest software providers - not just Microsoft. Mozilla patches much faster but we have also seen several incidents where a Mozilla patch broke the browser and/or was ineffective. Consider the fallout if suddenly all French Windows XPs/Vista were unable to boot. MS needs to regression test each and every combination. Remember what happened when malware caused Windows XPs to not boot because and old DLL had been patched and addresses assumed by the malware had shifted?
Windows Phone 7 is a huge departure for the smartphone group at Microsoft and takes quite a radical approach to the way people use their phones. Unlike the iPhone, Google Android, and Palm webOS, WP7 is not focused on the application experience, but is centered on helping you interact with the people you want to and complete the tasks you need to complete with apps mainly working in the background or having other technologies (like Bing Search) do better at meeting your needs without more apps.
The current experience is amazingly stable and fluid and I am quite impressed with what they have done. It has taken some time and they were pretty much out of competing for customers for most of this year, but it looks like they will come out firing with all they have this coming holiday season.
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).
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.
Slashdot Mirror
It was a legitimate dispute, one where Sun was (legally) right and MS wrong. Microsoft had agreed to a license and obviously wanted to do something which they were barred from doing.
I'm not claiming that Sun was in the wrong. Far from it. They had their platform to protect - which they did. Microsoft wanted to use Java - but obviously not at any price. They had obvious qualms (shared by IBM years later) and wanted to stretch it. They failed and paid for it. I for one think that justice (as in the correct verdict) was served.
What I have issues with it the revisionist painting this as some sinister attempt on part of Microsoft to try to extend and then extinguish Java. I coded C++ at the time and could certainly see how Java made me more productive. But at the same time AWT was a real pain. And slow. I totally digged Microsofts position at the time.
At the same time I can also recognize Suns position. If the "Windows bindings" could not be successfully replicated on other platforms (e.g. because 3rd party Widgets were not available) that could present a threat to the pervasiveness of Java.
Sometimes the plans do not reconcile. That's what happened. They went separate ways, one ending up a less fortunate, however.
Even though the legal vehicle is different this time around (Oracle claiming patent infringement rather than license breach), you could really see this as very similar suit: Oracle needs to fight forking and fragmentation of the Java platform. That would dilute the value of a very important asset (Java).
Uhm, Paul Allen is not Microsoft, nor is this company owned fully or partially by Microsoft. Rather they have a common owner, Paul Allen - that is if Paul Allen still owns Microsoft stock - which I presume.
But saying that this is a Microsoft deed is a stretch. Microsoft had no hand in these patents.
But if mr. Allen still owns a lot of Microsoft stock, suing MS would be a bit like suing yourself. A bit awkward.
It doesn't matter how much they assure that they won't go after free implementations. Without it written in legalese, irrevocable, it's a worthless statement.
It is written in legalese. And it is actually quite a bit stronger than a license as it does not require the beneficiary (you) to accept any license agreement. The legal term is estoppel. Here, look it up: http://en.wikipedia.org/wiki/Estoppel.
From Microsofts community promise (emphasis mine):
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification ("Covered Implementation"), subject to the following: [...]
Read the full text here: http://www.microsoft.com/interop/cp/default.mspx
Now, could that term "Necessary Claims" leave Microsoft with a legal loophole they could wiggle through and sue anyway? IANAL, but it certainly doesn't appear so, as the only way Microsoft could claim that your infringement on one of their patent wasn't "necessary" would be for them to demonstrate what you could have done. Remember, this is a one-sided promise, the burden would be on Microsoft to demonstrate how you would fall outside of the patent coverage.
Now, this promise covers C#, the common language runtime, common type system and core libraries such as collections, P/Invoke etc. It does not cover some of the framework parts higher-up in the stack, such as WPF, WCF, ASP.NET.
It is still unclear to me how implementation of such APIs would be more prone to infringing MS patents than implementing the same functionality on other platforms with other languages. Remember, you cannot patent an API, you can only patent an actual "machine" implementation. Surely if some critical part is covered by a software patent, said patent is language/platform agnostic.
It appears that the problem Google has with Dalvik/Oracle is precisely covered by Microsofts legally binding community promise. See, Google has no interest in implementing a full Java SE. And they had no interest in paying license fees to Sun(now Oracle) for an official JavaME. So they wiggled around and made their own platform in a way which has opened them up to litigation from Oracle.
Had they gone with Mono instead of Dalvik (remember, Dalvik was merely a way to wiggle around Java licenses) there would have been no license fees, and no patent infringement.
I did not mean you, and I was not replying to you. Sorry if it came out that way.
I did notice your ridiculous post about MS moving away from .NET, but it has been modded correctly already, so there's no need to address it.
Uhm, Silverlight is pretty much .NET. Silverlight 4 comes with a large subset of the .NET framework (the bits for making server apps have been left out, think ASP.NET). Since Silverlight 2 (IIRC) you can program the code using C# or any other .NET language, like VB.NET, IronRuby (yeah, I know), IronPython or JavaScript.
Silverlight is also fast approaching parity with the full WPF framework.
At the time Java came with its own set of widgets, and it had a terrible reputation (deserved) for being slow. At the center of the conflict was Microsofts insistence that developers should be able to use native Windows widgets for GUI apps - otherwise it would risk tainting the Windows platform as slow and unresponsive (yeah - I know - even slower, ok?).
To facilitate that they wanted developers to have the option to call native APIs directly. Library developers would then be able to make abstraction libraries which could take advantage of the rich Windows GUI (and COM) controls.
Sun would have none of that. Microsoft wouldn't yield. Microsoft lost the lawsuit, and then went on to make a language the way they felt it should be made. With a way to call native APIs which is leaps and bounds better than the nazi-abstraction of Java. No glue code necessary, just pure metadata annotations.
Sun went on with their own business and along comes IBM with Eclipse. Only IBM weren't too happy about the whole Swing deal. Java has definitely improved in speed, but on the GUI side all those gains (and more) had been eaten up by Swing. So IBM went for native GUI widgets with SWT.
There was a reason Microsoft didn't want to fix their JVM so that it would pass the compliance tests. They lost (or settled?) and Sun got an insane amount of $$$. Microsoft created C# and .NET the way they though it should be.
C# has evolved much faster than Java. And in some areas Suns "doubts" about whether such language features were feasible has been put to shame: Delegates, operator overloading, Native API (P/Invoke) marshalling, reified generics, value types etc.
and with Windows 7, it appears (from what I've read) if you want do any sort of work, you still need to use C++.
You read wrong. You can program against any API* using C#. Mind you, C# can also be used in "unmanaged" (they call it "unsafe") mode - where you have access to pointers, pointer arithmetic, direct memory allocation etc.
All regular APIs are either COM or have already been wrapped or even re-implemented in .NET. .NET can easily interop with COM APIs.
I believe that the only place where you would want to drop top C/C++ would be for device drivers.
Except that Microsoft is *not* moving away from dynamic .NET languages. They just released a platform unifying and solidifying dynamic language support within the .NET Framework itself.
This support is head and shoulders above anything else. Imagine that the platform and not the languages actually has services for doing dynamic member lookup with advanced caching and global optimizations. Making a platform which generalizes how different dynamic languages such as EcmaScript, Ruby, Python and C# look up members is no small feat.
It means that the language implementations themselves shrink quite a lot.
What we have on one hand is *one* disgruntled ex-Microsoft employee being cited on Microsofts plans for the future. On the other hand we have concrete and recent actions by Microsoft which suggests that they are very much investing in making .NET a dynamic multi-language platform.
I have no doubt that working with implementing an "outside" language inside an organization like MS is an uphill battle. But I have real problems seeing this as a sign that MS is backing away from dynamic languages.
Ah right. No one should sanely expect this.
You'd be surprised...
I just got stuck on your explanation about locks; moving locks around wouldn't help, because the malicious code does not need to respect any locks.
You are of course correct. A lock will prevent nothing. If there weren't multiple cores one could prevent the process from being preempted during the critical section. But that is moot now.
Agreed. As I tried to say (perhaps a little convoluted) i expected this copying to happen. But some seem to believe that SELinux will protect against malicious code executing in the kernel. Such code can call APIs directly and can modify kernel-allocated structures. If you can do that, security hooks become moot.
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
{
int error = may_create(dir, dentry, NULL);
if (error)
return error;
if (!dir->i_op || !dir->i_op->mkdir)
return -EPERM;
mode &= (S_IRWXUGO|S_ISVTX); //line 1883
error = security_inode_mkdir(dir, dentry, mode);
if (error)
return error;
DQUOT_INIT(dir); // line 1887
error = dir->i_op->mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
return error;
}
Line 1874 is the "old" permission check.
Line 1883-1885 is actually the SELinux hook. Note how this is a restrictive model rather than an authoritative model, i.e. it doesn't encapsulate the operation. It merely checks to see if you are allowed to perform the operation before proceeding with the very same arguments which were passed to the function (e.g. dentry
Line 1887-1888 is the weak spot. If I were an attacker who passed the "dentry" structure to this function I could still hold a reference to that structure. And holding the reference, I can overwrite the memory. If I time my memory write correctly (easier to do on a multi-core processor where I'm not even required to preempt the first call) I can inject my own parameters *after* the security checks. In this case I can create new directories wherever I want.
Remember, this is *not* something I claim you can do from userspace (haven't investigated that), but from within the kernel this is entirely possible!
I fully expect Windows to be vulnerable to similar attacks from within the kernel.
My gripe is how SELinux is expected to be able to confine malicious code which is already executing inside the kernel. It is a speed bump at best. Code running inside the kernel can modify all writable memory. Certainly it can modify memory it allocated itself.
Note, this is not an attack which is made possible by running as root. You need to be running in kernel - and then it doesn't really matter whether you run as root or not.
Workdays was important because that is what was used in the responsible disclosure guidelines. Which recommends waiting 5 workdays of non-communication before taking a vulnerability public.
Responsible disclosure which Google strongly supported until one of their researchers broke it:
From Googles website (emphasis mine):
"This process of notifying a vendor before publicly releasing information is an industry standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to better protect our users by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure. Our Security team follows the same procedure when we discover and report security vulnerabilities to other companies.
Tavis Ormandy knew this. That is why he made a stupid claim that acted in his personal capacity, not as a Google researcher. Even though he used Google resources, Google colleagues and Google paid time.
Also I see no technical discussion of the problem on any of the links you posted, nor any steps that can be taken until MS gets a update out to fix it.
The technical info is there. If you cared to follow the "fix it" links from their blog entries you would see that they designed workarounds.
But the interesting thing here is that after this debacle, 60 days was put forward as an absolute maximum a vendor should spend analyzing and designing+implementing a fix for a vulnerability. With this Linux bug we see 2 groups need to sit down together to work things out. And they spend 60 days before the distros got their hand on the fix. Just interesting, that's all. This was pointed out by the GP of the post I responded to. And he was immediately attacked.
Here is a novel idea: Stop misrepresenting what actually happened and stop ad hominem attacks questioning posters' motives .
Microsoft took five weeks to prepare the Ormandy patch. During that time, they made no comment - there was no transparency into whether or not it would be fixed.
They made no comments? Did you actually look or did you just assume?
Now to your claim that they "made no comments":
Hardly a "no comments" approach. If you click through those posts I think you'll find them smack full of info. And I've even excluded their communication on the preliminary "fix it" tools.
Admit it. You are biased, but not classy.
Like your misrepresentation and ad hominem demonstrate more class?
It seems to me that it is indeed interesting that this fix was 2 months in the making (responsibly disclosed). And that is only measuring the time until the kernel had been fixed. Now the distros would have to pick up on it and perform their own regression testing, prepare packages/updates etc.
GP did raise some really interesting questions. For some reason you chose to disregard them right away and go straight for the mans posting history.
Will you be publishing stats on my posting history as well. Am I a shill, too?
I don't get this blind trust in SELinux can do what it was never intended to do. If you compromise the kernel - especially a monolithic kernel like Linux - it really is game over.
Practically every security check (and - yes - that includes SELinux extra hooks) are performed before the actual operation is performed with no kernel lock covering both. Which means that *all* of them are susceptible to concurrent access attacks.
It works like this: The malicious code invokes the syscall passing a structure, e.g. an inode but at the same time the malicious code starts a second thread which after a measured period (clockcycles) modifies the very same structure. By crafting this carefully the attacker can hit the "weak spot" between the security checks and the actual operation. It doesn't work every time due to obvious nondeterminism, but even a 30% hit rate will be exceptionally good in a mass attack.
And you cannot lock down the tools used in this scenario. All processes will need to access memory and spawn threads. Certainly browsers, X servers, pdf readers etc. do.
This is not a bug in the kernel. Avoiding this weakness would involve bigger locks and critical sections which would seriously impede scalability. It is just that the kernel was never designed to withstand attacks from within the kernel itself.
So please stop peddling SELinux as a silver bullet. Once an attacker is inside the kernel it really is game over. SELinux doesn't fix that. Nor was it intended to.
Yeah, Mono would have been safer in a way since Microsoft had patent agreements because it was properly standardised, but that wouldn't make it 100% safe from patent threats from anyone (including Microsoft, who could have used patents covering the implementation using methods that weren't part of the grant).
The Microsoft community promise is open-ended. It does not specifically mention patents, rather it pledges that any necessary patents are implicitly granted for the purpose. You can read this as both good and bad.
Good: Microsoft is not holding any hidden cards, it is not a trap, they cannot suddenly rush out and hit you with a patent (like Oracle did).
Bad: If you implement in a way which cannot be said to be "necessary" or "the only way" *and* infringes on a MS patent, yes then they could theoretically claim that you did not receive grant for that particular patent implicitly with the promise.
IANAL but I would assume that the latter would be a very hard case for MS to prove, since the grant in the first place clearly was only for implementing the spec (i.e. you cannot use the grant for any other software) with the sole intention of liberating implementation from fear of submarine MS patents. Essentially the can only prove it by demonstrating that the patented "invention" was not necessary by presenting a non-infringing implementation.
Suffice to say that had Google built upon Common Language Infrastructure (CLI), C# and associated core libraries a similar situation would not have been possible. Microsoft has made a legally binding "promise" (legal term estoppel) that they cannot sue for infringement of any patents which covers the specifications. On top of that, Microsoft has open sourced .NET Micro Framework with similar patent grants. Oracle's legal leg here is that Dalvik is not covered by patent grants associated with OpenJDK, because it does not live up to the requirements - e.g. it is not a full Java SE implementation and it has not passed the compliance cert.
So why is it exactly that you think Mono is such a bad example? Seems to me that if you cut away all of the FUD thrown at Mono, Miguel was right all along: The CLI and C# is absolutely open and safe from MS patent litigation.
It is correct that some of the higher level parts of the .NET Framework are *not* covered by a similar patent grant. These are parts such as ASP.NET, WCF, WPF. All of which are either irrelevant or over the top for a small-footprint platform.
Even if you implement these APIs, it is not clear that MS has patents which would disallow that. You cannot patent a public API, you may be able to patent an implementation (a "machine").
Hum. Microsoft did this with Vista. Since 2006 (part of UAC) Windows supports file system virtualization for designated processes. Look it up. Since some (poorly designed) applications used their installation folder for storing/exchanging data between users a virtualized process will not be barred from writing. Instead the write goes to one of the user's directories.
You are correct, Tavis Ormandy claims that he acted on his own. Which is a fair claim, except:
If Tavis Ormandy was employed has a piccolo or cook maybe Google could get away with disassociating them from his behavior. But not when he does exactly what they pay him to do.
If you really want an operating system based solution, you could make a separate "acrobat" user (which doesn't have any read/write permissions), run Acrobat as this separate user and do a "sudo" whenever you want to allow acrobat to read/write to a file on the filesystem.
Or you could add operating system support which would allow a program's manifest to declare that it is internet-facing and should run with lower privileges than the user launching the program, i.e. stripping the user's writing permissions and limiting reading rights.
To avoid the program (if taken over by an attacker) misusing the permissions for e.g. unsolicited downloads to an otherwise allowed download location we could restrict the process so severely that it would need another process to marshal files in and out. We could then ensure that this other process interacted with the user to make sure that he/she is aware what is going on.
If only someone would come up with such a solution. Oh, wait: http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx
In the real world you'd create an Apparmor or SELinux profile which only allowed it to write to a few places and that would be it. Unless you're on an antiquated OS like Windows, anyway.
Uhm, you do realize that SELinux was developed for Linux because the Linux antiquated (inherited from 1960' era Unixes) security model was woefully inadequate? Only with SELinux did it become acceptable for government agencies to use Linux. It was missing basic security features such as ACLs.
Loadable security modules like Apparmor are necessitated by the fact that Linux permission system is, well, not very granular. Basically without a LSM you can only secure file system objects (and anything you can turn into a pseudo file system object).
Privileged operations in Linux are reserved for root, so to call those you need to become root. You cannot grant individual privileges like you can in Windows. Which leads to the idea of setuid and setgid which are security design problems akin to ActiveX: Hand over the keys to someone (you trust) and hope that he is well-behaved and doesn't contain vulnerabilities, because a single vuln can leads to a system-wide compromise.
Microsoft *never* refused to commit to a timeline. They didn't commit to a timeline within 3 days, so 4 days after reporting the bug mr.
Ormandy went public. If he truly believed that 60days would be reasonable he could just have informed MS that he would go public exactly 60 days later. But no, Ormandy just needed an excuse to go public and show the world how much smarter than Microsoft he is.
60 days may seem long, but it is actually very close to the current average for the largest software providers - not just Microsoft. Mozilla patches much faster but we have also seen several incidents where a Mozilla patch broke the browser and/or was ineffective. Consider the fallout if suddenly all French Windows XPs/Vista were unable to boot. MS needs to regression test each and every combination. Remember what happened when malware caused Windows XPs to not boot because and old DLL had been patched and addresses assumed by the malware had shifted?
From http://www.zdnet.com/blog/cell-phones/microsoft-windows-phone-7-technical-preview-a-definitive-guide/4286?pg=8&tag=mantle_skin;content
Windows Phone 7 is a huge departure for the smartphone group at Microsoft and takes quite a radical approach to the way people use their phones. Unlike the iPhone, Google Android, and Palm webOS, WP7 is not focused on the application experience, but is centered on helping you interact with the people you want to and complete the tasks you need to complete with apps mainly working in the background or having other technologies (like Bing Search) do better at meeting your needs without more apps.
The current experience is amazingly stable and fluid and I am quite impressed with what they have done. It has taken some time and they were pretty much out of competing for customers for most of this year, but it looks like they will come out firing with all they have this coming holiday season.
http://msdn.microsoft.com/en-us/library/Bb250462
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).
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.
At time of this posting parent is modded zero.
All parent did was to provide the exact information GP was asking for. Is the truth really so inconvenient?
Even if you don't agree, please show some integrity when modding, ok?