The funny thing is that the SLA is what the marketeers *promise*. If they don't actually provide it (more than likely given 'black swan' outages that affect everyone no matter how hard they work) then you really have to work hard to get compensation - meaning you won't get it since it costs more for legal to fight for than the money you'd recover. I outta know, we've just built a very high availability cloud product for a global company, and we know that accidents still happen.
In short, SLAs are indicative only and if you are choosing Office365 over *free* competitors based on the SLA alone then you probably need to stop believing so much marketing and re-evaluate the financials of each product.
Thanks for your explanation (which I already knew, btw) and for your work in raising the advisory.
My understanding was that an applet with default permissions could not make an RMI call to the originating host without a change to security settings (or being signed). I have seen a list of ports that an unprivileged applet can make back to the originating server (port 80 for example) but did not see the RMI port on that list of permitted ports - although there is admittedly conflicting documentation out there on the Interwebz. Perhaps the documentation is wrong? Otherwise a priviledged applet is needed, yeah?
How does the affected class get deserialized? It is not being run (permissions before the exploit prevent it without user interaction) and a copy of RMIConnectionImpl is loaded from the client's machine into their browser. So I'm curious as to how the offending code gets activiated and whether the user bypasses protections or not.
> including native code of the platform it's being run on.
Still needs to load it the same way the native library loader does, with the same privilege as an ordinary user (same as a bad local Java application, so the OS should limit the damage - except maybe on Windows). You also have to know where the particular library is (not too hard on Windows and Mac, harder on Linux due to the differing layout of different flavours). I suppose you could then use a local exploit of the library to get further - again a decent O/S (eg. Linux) will be fortified against user escalation.
the CVE-2010-0094 exploit was for deserialization of RMIConnectionImpl.
Applets need to be trusted to do RMI over the default RMI ports back to the server serving the applet. Hence, applet signing required at this stage to establish the RMI connection (before any deserialization can occur). If the applet has been accepted then the vulnerability comes into play, and that the privilege to deserialization of RMIConnectionImpl is not checked (this is the flaw), but that is after the connection is established.
The CVE entry stats that the exploit allows system-level *Java* calls to be run, not arbitrary x86 code as you claim (not every JVM runs on x86 dontcha know).
From the description the exploit appears to be due to a malware applet already downloaded and running in the user's browser.
That still requires certificate acceptance before the applet can run.
If the certificate was signed by the trusted Certification Authority (CA) the user would not see warning - and the CA needs to be notifified so they can revoke the cert).
Of course even with these mechanism the malware applets are still dangerous to the "Click OK, OK, OK until you are done installing crowd".
If the infections were coming via Java Applets then it becomes pertinent to ask how did they get on the machine. Java appplets must be signed to write to the user's hard drive. This means the user was prompted to approve an untrusted certificate and they did so, or the malware organisation had a trusted certificate, in which case the trust authority should revoke the certificate. It is not like applets are without protection to the end user.
Ha! You are saying because you personally are faster at installing Windows Server that Samba4 is worse? Sounds like you are good at Windows so that's what you want to install (at some license cost to the client), which is fair enough.
What you are missing is that it was a shame the organization didn't get someone who was better than you at Samba. The labor cost would be the same and the licensing cost would be zero. There are certainly people out there who can do this stuff and *save the customer money* at the same time. Just doesn't happen to be you - so you should recognize your own point-of-view is affecting your product comparison so it becomes less objective. The lower long term cost *and* initial cost of Linux makes it better than Windows in the long-term (I know, I'm working on a Linux-based solution where the number of servers will easily exceed ten thousand) - in fact Linux was chosen (not by me) for this very reason, it is a much better strategic investment on this large scale.
And the reason this doesn't happen is even simpler - it's pretty much corruption that prevents progress in Africa. Africa is rich in resources, gets lots of aid money, and has plenty of smart folks (even if the bulk are poorly educated). Just can't get anything done though - even rich Nigeria loses out with lots of parties (government politicians, tribes, revolutionaries) all get their cut of the oil (pipeline stealing) or revenue. Until this is sorted Africa will never improve (can't fight disease and famine if the donated aid is stolen or looted, etc).
> The process can slow down if Oracle and IBM decided to apply their efforts in different directions
I believe the announcement is they wish to work together. Wouldn't this mean that they should be moving in a common direction?
> If you look at the C++0x efforts, a lot of vendors are adopting draft features already
This sounds good but about 15 years ago I wrote a C++ program that I maintained for a decade. The use of 'draft' features made it a pain to maintain, and was worse as I was keeping it portable (every vendor had slightly different headers that changed with each compiler release). This was just awful and Java was bliss in comparison, which is why I'm an advocate of it. The stability of Java means much more to me (with huge, long-lived programs) than any neat features that'll get be out-of-vogue in a few years.
> Here's hoping the good ideas get unblocked and back on track
Same here. Thanks for your comments.
These companies have different DNA:
Sony's instinct is to use proprietary formats and lock stuff down. I bought a PS3, but psbuntu on it and intended programming it. Couldn't do anything could since Sony locked me out. I learned my lesson not to use their stuff.
Google on the other hand are the opposite. They are pretty open with their technologies and using them is a joy in comparison. While there are restrictions on some stuff (Map API) the rest of it can pretty much be used as you wish and for no cost.
These two collaborating would probably work as well as a marriage between a neurotic, secretive but immaculately coiffured woman and a hippy.
Yeah, you're completely right. IBM's code is pretty noxious (and Eclipse is a bit like Visual Studio where you need to learn lots of little tricks - whereas Netbeans is marginally less powerful but vastly simpler than either).
> I really don't think bodes very well for OpenJDK.
Huh? How do you get that. Now you have the resources of *two* giants working on Java and ensuring it remains compatible and new features are added.
> I see less and less hope for Java adopting the positive language and library features from the C# and Ruby worlds. I am currently working on a C# project, and things like LINQ, anonymous types, extension methods (haven't used dynamic yet) and the functional/fluent programming styles they enabled enhances my productivity compared to Java.
Java users for large-scale projects doesn't generally don't want to adopt these things. They have massive existing investments and projects that take years to complete (due ot the sheer number of featiures being built). They can't throw that away every two years for the next coolest version of Visual Studio with new things in it. Enterprise software architecture is a different beast and has strategic considerations that don't correspond to tactical niceities (eg. LINQ). A lot of the Java feature conservatism is deliberate because you can get people with less experience to be *productive* in Java earlier..NET rapid feature adoption is deliberate because Microsoft need to continually add features to Visual Studio to ensure you buy each release (which unfortunately can prematurely obsolete your investment in existing code - which is one reason enteprises don't always pick.NET - can you see how rapid feature adoption might be good for the desktop but as a result would be bad in the enterprise?).
The deliberate simplicity of Java means you can do *massive* projects with it (where you get a spectrum of developer abilities and the time scale is long where the people who start the project may not be around at the end). When you start to use more obscure features you limit how big your project can get, since not everyone will use the feature in the same way or be bug-free with it. I'm sure those C# features are nice, but it turns out Java already has a vast array of alternatives (some see this as an advantage, some as a disadvantage) and the features you speak of are significant for small projects but aren't a significant part of the code-base for *massive* projects.
In short,.NET is designed to be great to build your desktop apps and moderate-scale webapps in, and Java is designed to run your bank and Internet-scale services (millions of simultaneous users). Simply different horses for courses with different advantages. It is not like the JDK team and Java users don't see some of the new stuff in.NET, but it turns out that what is good for.NET would not be good for the stuff developed in the Java space (although.NET devs don't always grok that).
Don't forget, all of Oracle's customers use Java (like it or not, it is the leading enterprise development language/platform) - and they have a lot of investment in hardware and software that can't be transitioned to Windows (the Java apps can be, but the big-iron hardware often cannot).
Apparently the Serbians and Republika Serbska (Bosnia) used decoys a great deal when they were under air attack from NATO. From the Serbians I talk to (over TeamSpeak when playing LockOn Flaming Cliffs 2 - greatest combat flight sim out there, and the DCS series is awesome) it seems to be a matter of great pride that they duped NATO and much of their real equipment surived while the decoys got the complete hammering.
I hope the DRDO does better than their previous projects. For example, the Arjun tank has not been a good use of Indian taxpayer money, but internal politics seem to keep it and similar projects alive: http://en.wikipedia.org/wiki/Arjun_MBT
Yeah, worked on systems for semiconductor fabrication where the penalty was US$1,000,000/hour. But then the "chain of blame" was no use, better to get good systems (that I'd tested) and keep'em running.
Meh. Sounds like you're in an organization that isn't doing much innovative with their gear.
In less staid places you can test stuff yourself and check that it works and then maybe install it if it passes the criteria appropriate for "your" organization (not whether some sales or procurement dude thinks). Using on certified stuff is good if you want a "chain of blame" for when things go bad. However, lately I've found Ubuntu better than Windows in this regard (for the stuff I've tested), so relying on that "chain of blame" is not so necessary.
I'd rather have a cluster of *up-to-date* working systems (that I've tested myself) than cover my career with out-of-date stuff (and heaven knows, things Nvidia drivers need to be as up-to-date as possible, the WHQL certified ones are often relatively out of date and thus have all sorts of gripes that "uncertified" ones fix).
Thanks for explaining. Maybe that'd apply to "different" companies in NZ, but then once a complaint came in they'd still investigate. Plus, even if there was no legal resolution we have a TV show called "Fair Go" that looks at consumer-unfriendly behaviour and puts it out in the public eye (with only 4.3 million people you can't peeve your market too much).
On the other hand the US has a written constitution, bill of rights, and Miranda etc. We don't have that - but then our cops won't shoot you on sight unless you're shooting at them.
In New Zealand it is *illegal* to advertise one price and then charge another when the customer is in the store. Shame the US is so pwned by corporate interests that you have every right to murder each other with unlicensed automatic weapons (people can legitimately buy 50 caliber M2 machine guns, wtf!?) but have nothing protects customers from rip-off "bait n' switch" with a something akin to the Kiwi "Consumer Guarantees Act" and "Fair Trading Act"s.
Well, if someone proposes a law and if it includes a "think of the children" aspect no matter how whacky or egregious the rest of it, then it is likely to get passed.
A politician can't stand against it since the proponents of the law simply have to ask, "so, you agree with child pron/molestation/pedophilia/organized crime/drugs/terrorism [take your pick] then?".
This also happens in regular political circles (eg. conservative US, Lebanon, Iran etc) where the "holier than thou" crowd can easily stiffle debate by their opponents by introducing a moral dimension to an otherwise repugnant law. It it often too polically dangerous to vote against such things - which is why laws can become more extreme over time.
Crazy stuff, eh? As they say, "The Law is an ass". It doesn't have to make sense, it's just a bunch of rules.
Just wait until the US foists a treay on you where they slip in defences again 'seriously immoral' stuff and making drinking under 21 illegal (like Texas etc).
Thanks for checking the facts of the case/UK law. Keep that in mind the next time police and the media bandy around the "child pr0n"/"predator" aspect. Also, I'd also like to clarify that the real child predators, pronsters, and molesters etc are disgusting. Just be careful that the Law's definition of "child" might not match your own point-of-view (hell, when I was a younger fella I'd have gone to jail these days for what we did with our girlfriends - and that was all mild compared to what young folk get up to now [both on and off my lawn:)]).
Ooooh the scary words "child pr0n" where people lose all their reason (sure it is a terrible thing, but don't stop thinking, k?). A "child" in this case could be his 17 year old girlfriend that sent him a clothed but "lascivious" picture for example.
Slashdot Mirror
Maybe "Office success in the cloud" will be co-temporal with "Year of the Linux desktop" :)
Thanks for your informative post (you're already at the exalted height of +5 so we can't mod more).
The funny thing is that the SLA is what the marketeers *promise*. If they don't actually provide it (more than likely given 'black swan' outages that affect everyone no matter how hard they work) then you really have to work hard to get compensation - meaning you won't get it since it costs more for legal to fight for than the money you'd recover. I outta know, we've just built a very high availability cloud product for a global company, and we know that accidents still happen.
In short, SLAs are indicative only and if you are choosing Office365 over *free* competitors based on the SLA alone then you probably need to stop believing so much marketing and re-evaluate the financials of each product.
Thanks for your explanation (which I already knew, btw) and for your work in raising the advisory.
My understanding was that an applet with default permissions could not make an RMI call to the originating host without a change to security settings (or being signed). I have seen a list of ports that an unprivileged applet can make back to the originating server (port 80 for example) but did not see the RMI port on that list of permitted ports - although there is admittedly conflicting documentation out there on the Interwebz. Perhaps the documentation is wrong? Otherwise a priviledged applet is needed, yeah?
How does the affected class get deserialized? It is not being run (permissions before the exploit prevent it without user interaction) and a copy of RMIConnectionImpl is loaded from the client's machine into their browser. So I'm curious as to how the offending code gets activiated and whether the user bypasses protections or not.
> including native code of the platform it's being run on.
Still needs to load it the same way the native library loader does, with the same privilege as an ordinary user (same as a bad local Java application, so the OS should limit the damage - except maybe on Windows). You also have to know where the particular library is (not too hard on Windows and Mac, harder on Linux due to the differing layout of different flavours). I suppose you could then use a local exploit of the library to get further - again a decent O/S (eg. Linux) will be fortified against user escalation.
the CVE-2010-0094 exploit was for deserialization of RMIConnectionImpl.
Applets need to be trusted to do RMI over the default RMI ports back to the server serving the applet. Hence, applet signing required at this stage to establish the RMI connection (before any deserialization can occur). If the applet has been accepted then the vulnerability comes into play, and that the privilege to deserialization of RMIConnectionImpl is not checked (this is the flaw), but that is after the connection is established.
The CVE entry stats that the exploit allows system-level *Java* calls to be run, not arbitrary x86 code as you claim (not every JVM runs on x86 dontcha know).
From the description the exploit appears to be due to a malware applet already downloaded and running in the user's browser.
That still requires certificate acceptance before the applet can run.
If the certificate was signed by the trusted Certification Authority (CA) the user would not see warning - and the CA needs to be notifified so they can revoke the cert).
Of course even with these mechanism the malware applets are still dangerous to the "Click OK, OK, OK until you are done installing crowd".
If the infections were coming via Java Applets then it becomes pertinent to ask how did they get on the machine. Java appplets must be signed to write to the user's hard drive. This means the user was prompted to approve an untrusted certificate and they did so, or the malware organisation had a trusted certificate, in which case the trust authority should revoke the certificate. It is not like applets are without protection to the end user.
Ha! You are saying because you personally are faster at installing Windows Server that Samba4 is worse? Sounds like you are good at Windows so that's what you want to install (at some license cost to the client), which is fair enough.
What you are missing is that it was a shame the organization didn't get someone who was better than you at Samba. The labor cost would be the same and the licensing cost would be zero. There are certainly people out there who can do this stuff and *save the customer money* at the same time. Just doesn't happen to be you - so you should recognize your own point-of-view is affecting your product comparison so it becomes less objective. The lower long term cost *and* initial cost of Linux makes it better than Windows in the long-term (I know, I'm working on a Linux-based solution where the number of servers will easily exceed ten thousand) - in fact Linux was chosen (not by me) for this very reason, it is a much better strategic investment on this large scale.
And the reason this doesn't happen is even simpler - it's pretty much corruption that prevents progress in Africa. Africa is rich in resources, gets lots of aid money, and has plenty of smart folks (even if the bulk are poorly educated). Just can't get anything done though - even rich Nigeria loses out with lots of parties (government politicians, tribes, revolutionaries) all get their cut of the oil (pipeline stealing) or revenue. Until this is sorted Africa will never improve (can't fight disease and famine if the donated aid is stolen or looted, etc).
People don't expect to run apps on their TV (not yet at least) - they do expect to on their phone.
> The process can slow down if Oracle and IBM decided to apply their efforts in different directions I believe the announcement is they wish to work together. Wouldn't this mean that they should be moving in a common direction? > If you look at the C++0x efforts, a lot of vendors are adopting draft features already This sounds good but about 15 years ago I wrote a C++ program that I maintained for a decade. The use of 'draft' features made it a pain to maintain, and was worse as I was keeping it portable (every vendor had slightly different headers that changed with each compiler release). This was just awful and Java was bliss in comparison, which is why I'm an advocate of it. The stability of Java means much more to me (with huge, long-lived programs) than any neat features that'll get be out-of-vogue in a few years. > Here's hoping the good ideas get unblocked and back on track Same here. Thanks for your comments.
These companies have different DNA:
Sony's instinct is to use proprietary formats and lock stuff down. I bought a PS3, but psbuntu on it and intended programming it. Couldn't do anything could since Sony locked me out. I learned my lesson not to use their stuff.
Google on the other hand are the opposite. They are pretty open with their technologies and using them is a joy in comparison. While there are restrictions on some stuff (Map API) the rest of it can pretty much be used as you wish and for no cost.
These two collaborating would probably work as well as a marriage between a neurotic, secretive but immaculately coiffured woman and a hippy.
Yeah, you're completely right. IBM's code is pretty noxious (and Eclipse is a bit like Visual Studio where you need to learn lots of little tricks - whereas Netbeans is marginally less powerful but vastly simpler than either).
> I really don't think bodes very well for OpenJDK.
.NET rapid feature adoption is deliberate because Microsoft need to continually add features to Visual Studio to ensure you buy each release (which unfortunately can prematurely obsolete your investment in existing code - which is one reason enteprises don't always pick .NET - can you see how rapid feature adoption might be good for the desktop but as a result would be bad in the enterprise?).
.NET is designed to be great to build your desktop apps and moderate-scale webapps in, and Java is designed to run your bank and Internet-scale services (millions of simultaneous users). Simply different horses for courses with different advantages. It is not like the JDK team and Java users don't see some of the new stuff in .NET, but it turns out that what is good for .NET would not be good for the stuff developed in the Java space (although .NET devs don't always grok that).
Huh? How do you get that. Now you have the resources of *two* giants working on Java and ensuring it remains compatible and new features are added.
> I see less and less hope for Java adopting the positive language and library features from the C# and Ruby worlds. I am currently working on a C# project, and things like LINQ, anonymous types, extension methods (haven't used dynamic yet) and the functional/fluent programming styles they enabled enhances my productivity compared to Java.
Java users for large-scale projects doesn't generally don't want to adopt these things. They have massive existing investments and projects that take years to complete (due ot the sheer number of featiures being built). They can't throw that away every two years for the next coolest version of Visual Studio with new things in it. Enterprise software architecture is a different beast and has strategic considerations that don't correspond to tactical niceities (eg. LINQ). A lot of the Java feature conservatism is deliberate because you can get people with less experience to be *productive* in Java earlier.
The deliberate simplicity of Java means you can do *massive* projects with it (where you get a spectrum of developer abilities and the time scale is long where the people who start the project may not be around at the end). When you start to use more obscure features you limit how big your project can get, since not everyone will use the feature in the same way or be bug-free with it. I'm sure those C# features are nice, but it turns out Java already has a vast array of alternatives (some see this as an advantage, some as a disadvantage) and the features you speak of are significant for small projects but aren't a significant part of the code-base for *massive* projects.
In short,
Don't forget, all of Oracle's customers use Java (like it or not, it is the leading enterprise development language/platform) - and they have a lot of investment in hardware and software that can't be transitioned to Windows (the Java apps can be, but the big-iron hardware often cannot).
Apparently the Serbians and Republika Serbska (Bosnia) used decoys a great deal when they were under air attack from NATO. From the Serbians I talk to (over TeamSpeak when playing LockOn Flaming Cliffs 2 - greatest combat flight sim out there, and the DCS series is awesome) it seems to be a matter of great pride that they duped NATO and much of their real equipment surived while the decoys got the complete hammering.
I hope the DRDO does better than their previous projects. For example, the Arjun tank has not been a good use of Indian taxpayer money, but internal politics seem to keep it and similar projects alive: http://en.wikipedia.org/wiki/Arjun_MBT
Yeah, worked on systems for semiconductor fabrication where the penalty was US$1,000,000/hour. But then the "chain of blame" was no use, better to get good systems (that I'd tested) and keep'em running.
Meh. Sounds like you're in an organization that isn't doing much innovative with their gear.
In less staid places you can test stuff yourself and check that it works and then maybe install it if it passes the criteria appropriate for "your" organization (not whether some sales or procurement dude thinks). Using on certified stuff is good if you want a "chain of blame" for when things go bad. However, lately I've found Ubuntu better than Windows in this regard (for the stuff I've tested), so relying on that "chain of blame" is not so necessary.
I'd rather have a cluster of *up-to-date* working systems (that I've tested myself) than cover my career with out-of-date stuff (and heaven knows, things Nvidia drivers need to be as up-to-date as possible, the WHQL certified ones are often relatively out of date and thus have all sorts of gripes that "uncertified" ones fix).
Kia Ora Amigo! :)
I'm at the other (southern) end of the same unnamed country's island. Even JAFA cops have a sense of humour.
Thanks for explaining. Maybe that'd apply to "different" companies in NZ, but then once a complaint came in they'd still investigate. Plus, even if there was no legal resolution we have a TV show called "Fair Go" that looks at consumer-unfriendly behaviour and puts it out in the public eye (with only 4.3 million people you can't peeve your market too much).
On the other hand the US has a written constitution, bill of rights, and Miranda etc. We don't have that - but then our cops won't shoot you on sight unless you're shooting at them.
In New Zealand it is *illegal* to advertise one price and then charge another when the customer is in the store. Shame the US is so pwned by corporate interests that you have every right to murder each other with unlicensed automatic weapons (people can legitimately buy 50 caliber M2 machine guns, wtf!?) but have nothing protects customers from rip-off "bait n' switch" with a something akin to the Kiwi "Consumer Guarantees Act" and "Fair Trading Act"s.
Well, if someone proposes a law and if it includes a "think of the children" aspect no matter how whacky or egregious the rest of it, then it is likely to get passed.
A politician can't stand against it since the proponents of the law simply have to ask, "so, you agree with child pron/molestation/pedophilia/organized crime/drugs/terrorism [take your pick] then?".
This also happens in regular political circles (eg. conservative US, Lebanon, Iran etc) where the "holier than thou" crowd can easily stiffle debate by their opponents by introducing a moral dimension to an otherwise repugnant law. It it often too polically dangerous to vote against such things - which is why laws can become more extreme over time.
Crazy stuff, eh? As they say, "The Law is an ass". It doesn't have to make sense, it's just a bunch of rules.
:)]).
Just wait until the US foists a treay on you where they slip in defences again 'seriously immoral' stuff and making drinking under 21 illegal (like Texas etc).
Thanks for checking the facts of the case/UK law. Keep that in mind the next time police and the media bandy around the "child pr0n"/"predator" aspect. Also, I'd also like to clarify that the real child predators, pronsters, and molesters etc are disgusting. Just be careful that the Law's definition of "child" might not match your own point-of-view (hell, when I was a younger fella I'd have gone to jail these days for what we did with our girlfriends - and that was all mild compared to what young folk get up to now [both on and off my lawn
Ooooh the scary words "child pr0n" where people lose all their reason (sure it is a terrible thing, but don't stop thinking, k?). A "child" in this case could be his 17 year old girlfriend that sent him a clothed but "lascivious" picture for example.