Why oh why did openssl097 get uploaded UNPATCHED when there were known security issues with this version, with the fix even linked to in the bug?
This software was removed from Gutsy for a reason, if its going to be added back it should ATLEASTE be patched, as it stands right now anyone who installs vmware-server via Canonical’s Partner Repository is remote exploitable and it was known prior to the upload, is this a case of $$ from VMware means more than security? I’m sorry but this is simply not acceptable from Canonical as far as I’m concerned. It isnt a case where VMware is distributing it, its us, or atleaste Canonical distributing it to STABLE releases.
At this point a patch to fix the issue will simply not be enough, I want to know why this happened. And whats going to be done to ensure the Distribution I spend many hours for volunteering isnt going to allow this to happen again.
I Love Ubuntu and hate to see things like this happen, lets ensure they dont.
/* annoyed */
Says:
December 2nd, 2007 at 6:03 am
Come join Debian instead!
Says:
December 2nd, 2007 at 6:59 am
These kinds of things should really be dealt with in private. It’s not nice to call out on fabbione like that.
Says:
December 2nd, 2007 at 7:21 am
OMG! Can’t you just call fabbione in private an tell him everything you feel like to say?
This Planet Ubuntu post is completely unnecessary and inappropriate, it is not supposed to discuss development issues with other members, for this reason there is IRC, Mailing Lists, email, and many other methods that can be used.
This blog post shows that you do not fully understand the Ubuntu CoC.
Regards.
Says:
December 2nd, 2007 at 7:43 am
Oh come on… you and all your Code of Conduct crap…
You REALLY didn’t realized that the decisional process in Canonical is *all* about money?
I’m not saying that this is evil, it is quite normal, what is evil is all that “we are the good guys, and we advocate the freesoftware and we well give back to the FS community” that are only words (let’s get a look on the _real_ contribution to Debian…)
Says:
December 2nd, 2007 at 10:29 am
I agree, I don’t think the planet is the right place for this. Why not contact the packager and get it fixed instead of publicly making a scene about it? Fix the problem instead of making ubuntu and the packager look bad–doesn’t solve anything.
Says:
December 2nd, 2007 at 10:57 am
I am happy seeing the post on the planet. I might not have seen this if it was done in private, and the planet is to keep everyone in the loop on ubuntu happenings. Good post.
Says:
December 2nd, 2007 at 11:33 am
I’d say the person that uploaded it succeed in making Ubuntu look bad all by themselves. Keeping problems (particularly ones that cause security issues) secret doesn’t help anyone.
It’s particularly problematic because the Ubuntu community has no control over what happens in partner. It’s unfortunate that LP displays the partner repository as somehow part of Ubuntu, it’s really not. It’s a commercial offering that happens to be by the same sponsor and uses the same infrastructure.
Says:
December 2nd, 2007 at 4:02 pm
Uh, nothing in the linked documents hints in the direction that this could have been intentional. It probably just was an oversight and has nothing to do with $$. But it’s nice to have this public nonetheless. Just the accusatory tone is unnecessary.
Says:
December 2nd, 2007 at 4:25 pm
@Francesco:
LOL, are you for real?
Personally, I like Ubuntu because it’s Linux minus headache. I tried Debian before and it’s very good (one could say it is *the* linux distro), except I didn’t feel like configuring a million little things that I know nothing about (which is entirely my fault, but I was new in Un*x land at the time).
Says:
December 2nd, 2007 at 4:29 pm
Ubuntu is a nice distro but the support from launchpad annoyed me very much….
Most of the MOTUs are either lazy or have instructions from Cannonical i guess in order not to update packages…. ( to make $$$ from support or to reduce bandwindth? imagine a 20mb weekly package being downloaded as an update by millions of ubuntu/kubuntu etc users).
I swear I will become a MOTU an replace some of the lazy ones if possible!
(they don’t want to update pidgin… the new package has no new features or dependencies, only bug fixes… same with blender… gimp it’s an RC version FFS… that’s not even professional!)
Says:
December 2nd, 2007 at 5:08 pm
@Dread Knight
I think you have the totaly wrong idea, MOTU are not instructed by Canonical to /not/ update something, but once a release has been made changes should be made through SRU’s ( you can find the process for Standard Release Updates on the wiki ) and as far as I can tell non of the items you mention fall into a SRU worthy category.
Says:
December 2nd, 2007 at 5:11 pm
hi, I’m the author of debian’s vmware-package package. (since debian is not able to negotiate an ubuntu-like distribution license for ethical reasons (DFSG #7), the vmware-package package is a script which generates packages from vmware tarballs, similar to what the java-package package does. we cannot distribute vmware products directly from non-free.)
vmware server 1.x is a binary-only (in userland), i386-only distribution. the binaries are dynamically linked, but vmware ships a set of supplemental libraries that will be used if not present on the system, including libssl/libcrypto 0.9.7. these are i386 binaries of openssl 0.9.7i, which may not have been updated since the vmware server betas.
without the debian libssl0.9.7 package installed on etch, I get this when vmware-server is running:
# pmap `pgrep vm` | egrep “(ssl|crypto)” | awk ‘{print$4}’ | sort -u
/usr/lib/vmware-server/lib/libcrypto.so.0.9.7/libcrypto.so.0.9.7
/usr/lib/vmware-server/lib/libssl.so.0.9.7/libssl.so.0.9.7
with libssl0.9.7 installed on etch/i386:
# pmap `pgrep vm` | egrep “(ssl|crypto)” | awk ‘{print$4}’ | sort -u
/usr/lib/i686/cmov/libcrypto.so.0.9.7
/usr/lib/i686/cmov/libssl.so.0.9.7
on etch/amd64 *with* libssl0.9.7 installed, you of course get the first output, because the binaries (specifically, vmware-serverd and vmware-vmx) are i386. so, even with a fully-patched openssl097 source package, you’ll still need some way of installing the i386 version of libssl0.9.7 on amd64.
indeed, the ubuntu vmware-server debian/rules mentions:
# On amd64 boxes, we’ll use our own libs, plus the system’s ia32 libs.
# TODO: Is libssl0.9.7 really needed here? It’ll be amd64, right?
ARCH_DEPS=ia32-libs (>= 0.2), ia32-libs-gtk, libc6-i386 (>= 2.3.4-1), libssl0.9.7
if you want to distribute vmware-server-mui, there is a further wrinkle:
# pmap `pidof httpd.vmware` | egrep “(ssl|crypto)” | awk ‘{print$4}’ | sort -u
/usr/lib/vmware-mui/lib/libcrypto.so.4
/usr/lib/vmware-mui/lib/libssl.so.4
# ldd /usr/lib/vmware-mui/apache/bin/httpd.vmware | egrep “(ssl|crypto)”
libssl.so.4 => not found
libcrypto.so.4 => not found
# objdump -p /usr/lib/vmware-mui/lib/lib{ssl,crypto}.so.4 | grep SONAME
SONAME libssl.so.0.9.7
SONAME libcrypto.so.0.9.7
I’m not sure where they came up with such a silly file name / SONAME inconsistency, but it looks like another i386 copy of openssl 0.9.7i.
I have downloaded the vmware server 2 beta and it looks increasingly harder to package. (I do not think I will support the final version of vmware server 2 in vmware-package unless major changes are made.) build 63231 includes private copies of the sun JRE 1.5.0_07 and apache tomcat 5.5.17, which themselves have security implications. on the plus side, vmware server 2 beta includes native amd64 support, but their supplemental openssl libraries are only up to version 0.9.7j.
it would be useful to have vmware, inc. clarify whether the openssl libraries they ship with strings “0.9.7i”, “0.9.7j” correspond to unpatched upstream openssl releases, or if vmware applies additional patches. based on the relative infrequency of vmware releases, I’d bet on the former.
Says:
December 2nd, 2007 at 5:14 pm
Besides, Pidgin and GIMP are in main, so MOTUs can’t have anything to do with them.
Says:
December 2nd, 2007 at 5:20 pm
@ Christer Edwards
It solves a couple things, If you look closely none but Canonical + VMware can fix this in Partner, because VMware’s binary would need to be recompiled against a newer openssl.
Also if this was not done on planet it would not have been brought to light in such a large audience, Mailing Lists and IRC ( with irclogs.ubuntu.com ) are just as public, so its not a case of “Praise in public, Scorn in Private” and since I would like a Public response from Canonical about why this was allowed, a public question is only right.
P.S. I also feel Planet is not the place for Tutorials ( quote: “Planet Ubuntu is a window into the world, work and lives of Ubuntu developers” ) either but alas we all have opinions.
Says:
December 2nd, 2007 at 5:34 pm
imbrandon, vmware, inc. does not need to recompile anything so long as ubuntu can provide up to date versions of an i386 libssl0.9.7 on i386/amd64. that is the point of shared libraries and SONAMEs.
Says:
December 2nd, 2007 at 5:38 pm
@edmonds
Yea one OR the other would need to happen, thanks :)
Says:
December 2nd, 2007 at 7:59 pm
“Most of the MOTUs are either lazy or have instructions from Canonical i guess in order not to update packages”
Like transmission?
Says:
December 3rd, 2007 at 8:23 am
imbrandon, Ubuntu doesn’t provide libssl0.9.7 at all. It’s not in gutsy.
Says:
December 3rd, 2007 at 8:28 am
@Ante Karamatic
Correct it was removed for this very reason, this was uploaded to the Canonical Partner Repository ( http://archive.canonical.com/dists/gutsy/Release )
Says:
December 3rd, 2007 at 9:38 am
Francesco: Explain again how one could make money by having a vulnerable ssl library in one’s distribution?
Says:
December 3rd, 2007 at 9:40 am
Disappointed to see a lot of comments wanting this covered behind closed doors and hushed up. Transparency in the decision-making that results in this kind-of outcome would be the far better option in my opinion. As someone who observes Ubuntu from the other side of the fence, I much prefer the bickering and flaming that the Debian community is infamous for than randomness like this.
Says:
December 3rd, 2007 at 10:32 am
I am glad that you posted this on the planet. I totally agree about transparency being an advantage of open source development. This bug is especially important because it is a security issue. Ubuntu/Canonical needs to hold the highest standards for security or they will not be accepted into the enterprise market.
There is also the positive element of peer pressure, which holds us to a higher standard since development is done out in the open. This rant by Brandon was informative without personally attacking anyone. If we are running into these kinds of issues, we need to see more posts like this.
Says:
December 3rd, 2007 at 3:09 pm
People are missing a point here, and Brandon should be more correct when writing this news.
1) vmware-server is not part of Ubuntu (it’s non free, remember?)
2) vurnable SSL is not part of Ubuntu (check it out)
3) company XYZ creates it’s own deb archive with vurnable SSL (actually, this is related to Ubuntu as much as to Debian or any other .deb based distribution :)
Looking at 1, 2 and 3, please, explain, how is this Ubuntu problem?
I repeat, this has nothing to do with Ubuntu. Please, make distinction between Ubuntu and Canonical archives. Ubuntu archives are, well, Ubuntu archives. Canonical archives are archives of Canonical company, used for their partners.
Says:
December 3rd, 2007 at 5:14 pm
@ Ante Karamatic
While I kinda agree with you, that is not entirely true:
1) Canoncial repo is included ( abet commented out ) in the default Ubuntu sources.list and
2) When looking in LP the packages say “in Ubuntu”
now while both of these are bugs and have open bugs on LP about them, the meantime they DO “look” like they come from Ubuntu.
on top of that it was from a Ubuntu Core Developer and intended to be used in Ubuntu that should have known better.
And finally I DID make the distention between the Canonical Partner Repo and Ubuntu in the original post.
Says:
December 4th, 2007 at 2:06 am
1) true, but there is also a bookmark to firefox plugins in firefox - does that make addons.mozilla.org part of Ubuntu? No, it’s an option you can use, but it’s not enabled by default. Canonical repo is called ‘Third-Party Software’ in software-properties.
2) true again, but those problems are launchpad bugs
Yes, you did make a distinction, I apologize. But your post was guided to create a perception and all the people that read it think there’s a problem in Ubuntu (check out comments), while that’s not true. If you work for Canonical, you should post this post on private Canonical planet or, if you don’t work for it, you should’ve take another approach. Asking ‘Why did XYZ get uploaded?’ or ‘XYZ was removed from Gutsy, and now is going to be added’ on planet.ubuntu.com directs everyone to think ‘OMG, XYZ is uploaded in Ubuntu!’.
Anyway, no hard feelings, but as you can see on comments, your post misguided some people :) And, it doesn’t have to by your fault, but you do have responsibility.