Slashdot Mirror
VMware Confirms Source Code Leak
Gunkerty Jeb writes "Purloined data and documents, including source code belonging to the U.S. software firm VMWare, continue to bubble up from the networks of a variety of compromised Chinese firms, according to 'Hardcore Charlie,' an anonymous hacker who has claimed responsibility for the hacks. In a statement on the VMWare Web site, Ian Mulholland, Director of VMWare's Security Response Center, said the company acknowledged that a source code file for its ESX product had been leaked online. In a phone interview, Mulholland told Threatpost the company was monitoring the situation and conducting an investigation into the incident."
Hmm, I wonder where the hackers are based, and if it is state sponsored. Software code is the bet industrial espionage, because you can re-implement it yourself. My prediction - keep an eye onn the market to see who's the first to release a VMware clone!
Talk about burying the lead!
This VMware source code reportedly was stolen from Chinese military contractor CEIEC, the China National Electronics Import-Export Corporation. VMware code wasn't the only target.
What was the the Chinese military contractor doing with the VMWare source code anyway? And what other software packages were affected?
Hackers hack, that's what they do. But Chinese military contractors with VMWare source code in hand seems a much bigger story if you ask me. Did they have a license to it? Can anyone get a license to it? And if so, why is this a big deal?
Vmware says:
VMware proactively shares its source code and interfaces with other industry participants to enable the broad virtualization ecosystem today.
They can't have it both ways, stating in the same memo that the code was stolen and also "proactively shared". What the heck does proactively shared mean any way? Sending out sensitive hyper-visor source code to foreign military contractors seems at best, ill advised, but then to turn around and act all surprised and defensive when someone steals it from them seems a bit of a stretch.
Sig Battery depleted. Reverting to safe mode.
"Hey, Chien, it costs waaaaay too much for these VMWare licenses. it's too bad we can't build our own."
"Well, they did give us the source code. But they'd get mad at us."
"Not if we tell them it was stolen."
So means that the code is already available if you wanted it bad enough. *yawn*.
I can see reasons for it to be shared, like when companies want to tightly integrate their products and the published API's aren't at a low enough level to do it. Other companies do this too.
Problem is that today's friends are often tomorrows enemies. ( just look at the OS/2 debacle between IBM and Microsoft .. )
---- Booth was a patriot ----
I am waiting for my " I told you so!" moment.
Chinese contractors, Non Us Citizen contractors. Yes yes the cheapest bidders! As long as everyone is making thier 10% on thier stocks everyone is happy right?
No matter how well you understand how a piece of software is implemented, it shouldn't expose any sort of vulnerability. If VMWare legitimately has cause for concern, they were doing it wrong from the start.
While they have probably had viable reason to keep it closed (ESXi did enjoy a pretty secure technical advantage), it's probably approaching time for them to open source the hypervisor since there is now pretty viable competition from KVM and Xen nowadays. They currently are trying to hold their core technology capabilities hostage to force upsell into their management stack (e.g. the many features that are disabled except through vCenter that aren't really inherently requiring vCenter), but that strategy doesn't work when the prospective customers can jump ship pretty easily to less restrictive technologies.
XML is like violence. If it doesn't solve the problem, use more.
There are some software applications that require a high degree of coordination and management to produce. Some types of software also require the cooperation of 3rd parties to ensure the system you are building will handle certain functionalities. You may even need to create a test bed to reproduce the security related issue. These types of things cost money. Why should anyone be expected to automatically open source their code before they have a chance to at least recoup the expenses incurred in the development process? And the "many eyes" security approach is laughable and naive in the extreme. How many developers actually posses the skills needed to analyze a complex application code base and spot security problems just by stepping through the code? I have seen a lot of bug fixes and new functionality in open sourced projects but I have not seen any conclusive examples of someone addressing a security related issue. I am sure there might actually be some instances of this happening but placing your faith on the "many eyes" approach is just bad advertising.
If you're serious you don't need source code anyway. Once you have the executable object code (as a paying customer or whatever), you can reverse engineer source code easily enough.
The original source code just makes it easier to understand how the object code works. And if the original source is sparsely commented, or the object code includes debugging info, the benefits are less.
Source code is most useful for situations where you don't have access to the object code, such as hosted services, embedded systems, etc.
torrent lik plz
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
I am quoting tfa from arstechnica:
the hacker Hardcore Charlie told Reuters earlier this month that he hacked into CEIEC seeking information on the US military campaign in Afghanistan
Apparently that hacker hacked into CEIEC - a Chinese military contractor, - looking for information on US military campaign in Afghanistan
It's like hacking into the system owned by Palestinians looking for information regarding Israelis military campaign
Makes a lot of sense, doesn't it?
Muchas Gracias, Señor Edward Snowden !
If you're dumb enough to give your source, or any other monetizable data to the Chinese, Indians, Pakistanis, etc. don't be surprised to find it suddenly (ahem) "stolen."
VMWare has nobody but it's naive, insular, overly trusting top management to blame. They have no effective legal recourse. What did they think would prevent this, a gentleman's' agreement?
Please do not read this sig. Thank you.
Well yes, VMware is still the market leader, but what would anyone do with this source code anyway? It's not as if VMware has anything left to teach the rest of the world about virtualization. The rest of the world has pretty much caught up and virtualization is a commodity now.
Tired of FB/Google censorship? Visit UNCENSORED!
On the other side of the coin, it's a lot easier to make money when your customers can't just download and compile your code.
Situations like this actually are a pretty good balance between keeping the source closed, but allowing customers to verify that it doesn't have any secret back doors or obvious security flaws. Many companies do this, and foreign governments and companies seem okay with the arrangement.
No matter how well you understand how a piece of software is implemented, it shouldn't expose any sort of vulnerability.
When you say, "in theory" you need to include psychology and sociology, not just computer science.
There's a reason people clean up code before they release it as open source.
there is now pretty viable competition from KVM and Xen nowadays
The difference is that Xen has been looked at by the good guys and the bad guys for years. Like it or not ESX is now open source (non-OSI definition), but only for the bad guys.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Making source available for everyone to view doesn't mean that you have to integrate any code changes that anyone else sends you.
I do feel quite insulted by the "only big customers see the source" model tho, source should be available to everyone on equal terms even if they release it under non open terms (eg you can build/view/modify internally, but not distribute it in any way).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Just because sourcecode is open, doesn't mean you can't make money from it. RedHat release most of their code and yet they are highly profitable.
There are plenty of people who are able to find security problems, even in binary applications... If you keep the source closed, then there is a high likelihood of it getting leaked anyway, and then you have a situation where the blackhats have an advantage over the whitehats who wouldnt want to associate themselves with leaked code.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
You can easily release the code under terms that prohibit use of the code without paying the appropriate fees.
It's also equally possible to just download and run the binaries without paying, this is generally called "piracy" or "warez".
The "balance" you talk of, is actually a pretty horrible imbalance, it provides an unfair advantage to larger companies and blackhats, while unfairly discriminating against smaller companies and independent whitehat researchers.
The BSDi approach was actually a much better one, as a paying customer (even a very small one) you got the sourcecode as part of the deal and could modify it to suit your needs internally, but you weren't allowed to redistribute it (or any modifications you made) to third parties.
Releasing your source under such terms doesn't make you worse off, but does make things better for many of the customers and may even bring in new customers. Also although the customers are not allowed to distribute their changes to third parties, there is nothing stopping them contributing bugfixes etc back to the original supplier, so you might actually get some free development out of your users.
Speaking of which, something i utterly detest is software with onerous license enforcement code, that is code which tries to verify that you are in compliance with the license terms and then inhibits functionality (ie causes a denial of service) if it believes you are not. Such software provides NO benefit to the customer, but it does bring a significantly increased risk - there have been many cases of license enforcement code incorrectly triggering and causing all kinds of unnecessary problems for paying customers (i believe vmware had such a problem a couple of years ago for instance).
Non paying customers, eg pirates, run cracked versions where this code is removed and thus generally have a more stable product.
I think such functions should simply not exist, they are entirely detrimental to paying customers. By all means implement a feature which verifies license compliance and displays or logs a warning if a problem is detected, that is actually useful to help companies ensure they are in compliance, but under no circumstances should the software take intentional acts to disrupt the users.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
...how any company thinks placing industrial secrets on a World-facing node can in any way be described as a smart decision?
Or was it done deliberately?
Operation Guillotine is in effect.
Passwords/public key encryption etc. are all "security by obscurity" as well... sure open source software allows the community to see exploitable bugs, but it doesn't mean the community will notice or fix them. You can, however, be sure at least one community member will be able to remove any license checks and one will release an exploit - that wouldn't have been able to had they not seen the source.
The only valid argument you can use to counter this is that anyone who has the means and motive will get access to the source anyway... but thats pretty weak.
Deffence in depth. VMWare has a large team of staff who review code changes and do regression tests against the software... the community is probably of little value now and having closed source adds another layer.
120 characters ought to be enough for anyone
Passwords/public key encryption etc. are all "security by obscurity" as well...
No they're not. Sure, you have to keep them secret, but the key thing is that the security of the whole system doesn't pivotally depend on just your password: if you suspect your password has been compromised, you can very quickly and easily change it, and the system is then no less secure than it was before (give or take any damage done while your password was known). On the other hand, if security depends on your source code not being available (because it does uber-secret stuff), and it then gets leaked, there's nothing you can do to put the genie back in the box, short of rewriting your entire software...
Need to type accents and special characters in Windows? Use FrKeys
Other VMs had source leaks, too.
Xen had a source leak.
Virtualbox had a source leak.
Even KVM had a source leak.
These VM people better get their act together!
Sure, passwords/keys can be changed - but I don't suspect many companies that release closed source software (that they release/make available to partners) are too concerned about their security being completely compromised to the point of needing to rewrite everything due to a source code leak. After all, source code can be patched and re-built... just like passwords and keys changed... and if you don't have the support to get the code changes completed and implimented, you'll still be affected by security related bugs weather the software is open or closed source. There is lots of out of dat open source software with major holes floating around in the wild...
120 characters ought to be enough for anyone
It's more of a risk thing. When you release the source to your crown jewel product, you're trusting the other side to abide by the terms of the license. If they're a big company, they'd want to because it's a lot easier to go after ONE big company that has money.
If they released it to all customers, then you're trusting that the person who asks for it will abide by the license. If it turns out to be some student who decided to share with his 1,000,000 "friends" over BitTorrent, you're possibly sunk - there's no way to recover any money from them and now it's spread.
That's the main reason. Plus if five of your customers have it and it leaks out, there's only 6 possible origins for the leak - you and the 5 companies. A lot easier than say, 100.
And yes, it extends to open-source as well - I'm sure there are tons of GPL violations out there, but it's so small scale and such that it goes unnoticed. The big open-source guys already respect the license, and the guys with money settle.
After all, source code can be patched and re-built... just like passwords and keys changed...
It can... but the difference is that, once I know my password is compromised, changing my password takes seconds—whereas analysing a code problem, coding a fix, testing it, distributing it to customers and having them deploy it can take months or even years.
and if you don't have the support to get the code changes completed and implimented, you'll still be affected by security related bugs weather the software is open or closed source. There is lots of out of dat open source software with major holes floating around in the wild...
I'm not really sure what you're saying. Sure, open and closed source software may both have security bugs - which may or may not get fixed. But this doesn't change the fact that there is a significant difference between security by obscurity and using passwords/keys.
Need to type accents and special characters in Windows? Use FrKeys
if (LANG ~= en_US){DEFINE USE_TSA_SPYCODES}else{/*Fuck it, we are TSA */RETURN=0};
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Never said it should be available for free, just that it should be available on equal terms for everyone. I would advocate that all paying customers receive (or have the right to receive) sourcecode, even if under non-open terms (ie no redistribution etc).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
You mean like trusting your customers to abide by the terms under which you distribute binaries to them?
Having the source spread is no worse than having the binaries spread. In either case pirates will redistribute it, and there are still customers who will pay. Most corporate customers for instance will not even consider using a pirate copy, and will buy your original no matter how widespread copies are on torrent sites.
Also most pirates won't care about the source, and will just continue pirating the binaries as they have done for years. People who are capable of compiling and/or modifying source are usually developers themselves and more likely to respect copyrights.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
From the confirmation on VMware site
Yesterday, April 23, 2012, our security team became aware of the public posting of a single file from the VMware ESX source code and the possibility that more files may be posted in the future. The posted code and associated commentary dates to the 2003 to 2004 timeframe.
So, they have an 8-9 year old version of the source code. That is ESX version 2/2.5, right? If that is the case, not much was lost and most of the code has changed. This is before hardware virtualization and even 64-bit support.
Unless the hacker posts something indicating a newer version, then there doesn't seem much to worry about.
I never said you cannot make money on open source software but this applies only to people or companies whose business model is centered around providing support and bug fixes. Redhat adopted a business model based on charging for support but that option is not universal. The original post on this thread intimated that all source code should be automatically open sourced from the first release.
"more likely" != "always", there are always exceptions.
And the fact that you pirate software for which you don't have the source just goes to show that releasing sourcecode isn't going to have any impact on piracy.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!