VMware has confirmed that the source code for old versions of its ESX technology was leaked by hackers over the weekend - but played down the significance of the spill. The virtualisation giant said on Sunday that the exposed portions of its hypervisor date back to 2004, and the leak follows the disclosure of VMware source code …
The Bitter Sweet Truth ..... and there aint no doubt about it.
A person going by the name of Stun, who made the source code available, wrote: "It is the VMKernel from between 1998 and 2004, but as we all know, kernels don't change that much in programs, they get extended or adapted but some core functionality still stays the same."
Others would make so bold as to to say that most core functionality still stays the same, and that makes a virtual machine kernel leak practically impossible to plug.
Oh dear, what a shame. I wonder who is to blame? Although who really cares, for it doesn't really matter, does it.
I'd like to think that this doesn't pose any risk...
...since attackers have always had the code to read - this is just source code and so a whole lot easier and perhaps with some thought-provoking comments ("we do it like this to minimise the timing window for an exploit, but we can't eliminate it entirely")
Of course what I'd really like to think is that it's an adamantine gem of a system and that no amount of code reading will reveal a flaw because there aren't any. But of course there are (as the steady stream of VMWare security releases shows), so I'll get back to more realistic daydreams ("women crave me for my body")
What's their problem anyway?
There is plenty of software out there that doesn't rely on keeping the Source Code secret from its own users. Enough to do anything you're ever likely to want to do with a computer, for that matter.
One day -- perhaps within our lifetimes! -- the law of the land will change, and software vendors will be required to supply Source Code to end users as a matter of course (the way packaged foodstuffs have to be marked with their ingredients and nutritional breakdown).
Two major release cycles later, nobody will want to go back to the Bad Old Days.
Re: What's their problem anyway?
Food manufacturers don't have to post their recipe - an ingredients list / nutritional breakdown is hardly the same thing. I think there are major issues with software patents and so on, but I don't think a company being able to keep their source code private is one of them. Just because there are Open Source projects, doesn't mean everyone should have to be Open Source.
Sticking with the cooking analogy - lots of chefs release cookery books, and people share recipes online but it doesn't mean I have a right to know the full method / recipe for everything on a restaurant menu.
> an ingredients list / nutritional breakdown is hardly the same thing.
"This software is composed from both binary ones and zeros. To avoid indigestion serve multi-byte entities little-endian. Picture of running software is serving suggestion only. Happy user is not included in this packaging. Caution! may contain trace amounts of WTF!"
Re: What's their problem anyway?
Food manufacturers don't have to post their recipe - an ingredients list / nutritional breakdown is hardly the same thing.
Install Size about 20 GB (binary)
Install Per Download about 3
Amount Per Install
Disk Space 20 GB - Disk Space from Bloat 18 GB
RAM 2 GB - 50%
Swap File 4 GB
*May contain legacy code, DRM, and uncompiled Java
*Requires DirectX-9 graphics Card
"Mulholland said customers who apply the latest product updates and patches, in addition to following system hardening guidelines, ought to be protected against attacks developed in the wake of the code leak."
So you've not got very much faith in the security of the released versions of your software then? I realise there are always bugs in software but that's not very comforting when a bod from the company says things like that!