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.
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.
Not really. China has a lot of intel presence in the region, and unlike US it will likely be less secure because it's not intel about THEIR OWN important operations.
So it makes a lot of sense to go after China's data on US Afghan operations.
That's certainly true, if you think that a reverse-engineer's time is free.
There have been successful reverse-engineering projects, of course, but nowadays it's pretty much out of most people's realm unless there's EXTREME interest in doing so. By the same token, you could say that you could "just" reverse-engineer Windows and it's as simple as that. Not quite. You could "just" reverse-engineer Steam, too, but that's not really been done either.
Modern software projects are HUGE compared to even 10 years ago. A 50Mb executable barely raises eyebrows anymore, and that's not even getting all the associated libraries and DLL's. Of course it's possible, but it's far from viable unless you have some extreme impetus to do so and are willing to spend years.
It took something like 5 years to "reverse engineer" Transport Tycoon (the OpenTTD project is from a reverse-engineering of the original DOS executables by ludde, I believe, the same guy who started ScummVM by reverse-engineering the SCUMM-engine games) - and that used lots of modern tools on a tiny, ancient DOS executable for a game that used well-known standard languages of the time and still took years to do. To my knowledge, still nobody knows how to defeat the copy-protection on the original Master of Orion properly (GoG.com just give you a copy of the protection sheet as a PDF).
Now think about any decent size modern software project and the chances are that it would take either a VERY dedicated team years, or a particular individual decades to get close to reverse-engineering it (in which time, they could quite literally just write an equivalent themselves anyway). VMWare is hardly a simple piece of software, probably one of the most complicated you can make, what with having to have intimate and perfect knowledge of the machine you're on and the one you're emulating and dealing with all the middle-layers in-between to ensure it works. You probably couldn't reverse-engineer it (certainly not "clean-room" standard) for less than the time/price it would cost to just build your own.
There was a time when you could just throw an executable through simple utilities to get equivalent C source and then work from there to add detail so that you end up with C source that compiles back to the original (or equivalent) and that can be understood by your average programmer. You still can, in fact. But it's not an Sunday afternoon job. And now it's orders-of-magnitude more complex than it used to be back in the hey-day of reverse-engineering executables.
The chances of any modern program being manually reverse-engineered (honestly - this isn't something that can be done automatically and the results understood enough to actually do anything useful with) are slim just because of the sheer extent of the effort involved and the complexity of modern software. You know how people complain that a Hello World is now a 1Mb executable? Multiply that up by something like VMWare's complexity.
And above all that, reverse-engineering is one of THE most difficult things to do on a piece of software. The majority of programmers would never be able to do it. Why do you think there's no "free" program that can connect to Skype (which we have DOZENS of executables for and not one open-source reimplementation), or why Pidgin can't do video over most of the protocols it supports (that DO support video in the official client), or why ReactOS just barely runs and Wine has taken years to get to the point where it can only just run most things after HUGE investment of time and money from thousands of programmers when all it needed to "know" was the public API that everyone was programming against anyway, not even how Windows implements it?
It's technically correct. I wouldn't rely on a program to hold some "secret" way of connecting to somewhere. But unless someone huge (government or corporate) has a really vested interested in breaking your program, reverse-engineering is probably never going to happen.