Bugzilla – Bug 4617
OpenSSL need to be upgraded
Last modified: 2008-08-11 13:55:25
You need to log in before you can comment on or make changes to this bug.
Hello, As I think you know, I work on building the VDT, and we include Globus. Right now we are trying to finish up VDT 1.3.11, which includes Globus 4.0.2. GT 4.0.2 includes OpenSSL 0.9.7d (along with two patches, documented in openssl_gpt/CHANGES.gpt). There are unfortunately bugs in OpenSSL 0.9.7d that are affecting us: it segfaults when we build on Fedora Core 4/x86-64. I have lots of documentation in our tracking system: http://vdt.cs.wisc.edu/rt/index.html?user=guest&pass=guest&q=1931 But I'll summarize it here: When we build programs like UberFTP and MyProxy as non-debug binaries, they use OpenSSL's assembly code and they crash in bn_add_words()--assembly code from OpenSSL. When we build as debug binaries, they use OpenSSL's C code and they don't crash. I built OpenSSL 0.9.7d and 0.9.7j by hand, and I was able to replicate this crash in the test suite: 0.9.7d crashes and 0.9.7j does not crash. Something interesting to note: after 0.9.7d was released, a change was made to this code to make it "gcc4 savvy". You can see it here: http://cvs.openssl.org/rlog?f=openssl/crypto/bn/asm/x86_64-gcc.c It's interesting to note that when we build it on x86-64 with gcc 4 it crashes, and when we build it on x86-64 with gcc 3.2.3, it does not crash. So I would like to request that Globus update to OpenSSL 0.9.7j for Globus 4.0.3, so that we can avoid this serious crashing bug. I think that it is safe to make this in the GT 4.0.x series, because I don't think that any API changes were made. What do you think? Alain Roy VDT Team
Just my $.02: That this seems reasonable.
So, in the past Sam would've worked on this, but obviously I'm not sure that applies anymore. Does anyone in the security team have the hours to devote to this? If so, I'd also like to have a discussion about how to handle the openssl builds in HEAD, not just 4.0.x.
Hi, Any updates on this? I'm still very interested in it, because it will solve a big problem for us: that of being unable to build a working, non-debug OpenSSL on x86-64 with gcc4. In addition, there has recently been quite a bit of talk about an OpenSSL vulnerability. It seems likely that it isn't affecting VDT users, but at the same time, we want to be 100% certain that it won't affect VDT users. Upgrading OpenSSL would be the best way to do that. You can see the note about the vulnerability: http://www.openssl.org/news/secadv_20060905.txt If the Globus project is unable to help upgrade OpenSSL in the near future, can you give me some guidance on how I would do it in our VDT builds? I'm not sure what changes you had to make to get it to build within the Globus framework. By the way, I'm most interested in having this in the GT 4.0.x series and not the GT 4.1.x or 4.2.x series. That's because we are likely to stay with GT 4.0.x for a while yet. Thanks, -alain
Hi Alain - Regarding the x86-64 non-dbg builds, I believe the fastest solution to that particular problem would be to update the assembly code in the version we use to the newer assembly code used in 0.9.7j. In July I looked into building 0.9.7j with no patches for use in the globus_4_0_branch. However, in the 0.9.7e->0.9.7f upgrade, the following change occured: From the openssl CHANGES at http://cvs.openssl.org/getfile?f=openssl/CHANGES *) Make an explicit check during certificate validation to see that the CA setting in each certificate on the chain is correct. As a side effect always do the following basic checks on extensions, not just when there's an associated purpose to the check: - if there is an unhandled critical extension (unless the user has chosen to ignore this fault) - if the path length has been exceeded (if one is set at all) - that certain extensions fit the associated purpose (if one has been given) [Richard Levitte] This results in our proxy validation code failing because the preverify step now does now dies with an "unhandled critical extension" error. That preverification failure results in verification failure. The environment variable OPENSSL_ALLOW_PROXY_CERTS does not affect the behavior that I could see. In particular, I believe the function globus_i_gsi_callback_cred_verify is the one responsible for dealing with this preverify failure - at the very least, it's the one that sees the preverify variable set to 0 and throwing the error. As such, the 0.9.7j upgrade is stalled waiting on developer time to rewrite the proxy verification routine. I'm personally interested in seeing the openssl code go unpatched if possible, though we'll need input from Joe Bester on whether he needs the new version to continue building on ARM embedded platforms.
Just a note to remind whoever does the update to ensure the following openssl bug is fixed. http://www.openssl.org/news/secadv_20060905.txt
Subject: Re: OpenSSL need to be upgraded Thanks for the detailed answer, Charles, I appreciate it! It's good to have an idea of the problems facing you. >As such, the 0.9.7j upgrade is stalled waiting on developer time to >rewrite the proxy verification routine. Do you have a feeling for how long it will be stalled for? If I want to advocate for it, who should I talk to? The people on this ticket? Someone else? Thanks, -alain
Sure - I'm sorry that I hadn't updated the bug status with that information closer to the time that I had gained it, but I thought the backup plan of updating the assembly code would be easy enough, and was thinking the full upgrade would wait for the 4.2 timeframe, but events have since shown that we shouldn't wait that long. I think the power-3 rsa key vulnerability means it will get going sooner than it would have otherwise, but I still don't have a sense for how long it would take. I'm not sure who else you would talk to besides me and Stu, but whoever advocates it internally would benefit from having the details recorded in this bug.
I believe we have another candidate platform that needs this: On powerpc64 (ppc64) we get grid-proxy-init failure. This was just reported on the Teragrid at IU, and in searching for details I found an older report of the same failure on an FC5 machine on powerpc64 also. The problem is that grid-proxy-init will keep printing "......" forever: """ [jorgee@js21n1 .globus]$ grid-proxy-init Your identity: /O=Grid/OU=CEPBA/OU=UPC/OU=cepba.upc.es/CN=Jorge Ejarque Enter GRID pass phrase for this identity: Creating proxy .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. [jorgee@js21n1 .globus]$ I 've killed the execution because it never stopped. """ The user identified a workaround, which is why I assume we didn't get a bug report about it: """ If I make the softlinks libcrypto_gcc64dbg.so.0.0.0 -> /lib64/libcrypto.so.0.9.8a and libssl_gcc64dbg.so.0.0.0 -> /lib64/libssl.so.0.9.8a, then it runs [jorgee@js21n1 ~]$grid-proxy-init Your identity: /O=Grid/OU=CEPBA/OU=UPC/OU=cepba.upc.es/CN=Jorge Ejarque Enter GRID pass phrase for this identity: Creating proxy ................................................ Done Your proxy is valid until: Tue May 30 04:03:52 2006 """ So it seems the problem is related to an outdated version of openssl. So we can add Teragrid to the affected communities list for this bug also.
Subject: Re: OpenSSL need to be upgraded What is the state of the OpenSSL update? I'm working on building Globus 4.0.3 for the VDT, and I need to figure out how to work around or fix this problem. I'm wondering if I can use your update, or if I have to deal with it myself. Thanks, -alain
Any update on the status of this? Thanks!
Please look at http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=4743. Code changes to GSI to make it work with the latest version openssl has been committed to openssl_upgrade branch. Charles is working on GPT packaging the latest version of openssl.
> - if there is an unhandled critical extension (unless the user > has chosen to ignore this fault) How to ignore the fault in SSL application?
Can you try building GT4 using the instructions at http://dev.globus.org/wiki/C_Security:_Vendor_OpenSSL to see if this fixes your issue? Joe
Subject: Re: OpenSSL need to be upgraded > Can you try building GT4 using the instructions at > http://dev.globus.org/wiki/C_Security:_Vendor_OpenSSL to see if > this fixes your > issue? Thanks Joe! I'll certainly try the build soon, probably early next week. I'll prefer to build with a set of patches, instead of a set of new GPT packages. A couple of weeks ago, Charles gave me a link to figure out the patches, so I'll try that. Actually, it will take me a little while to generate the patches: is it easy for you to generate this as a patch set? Thanks, -alain
Added the patches to the same wiki page (can't attach to bugzilla anymore).
All of the patches to support the new OpenSSL is now committed to 4.0 branch and trunk. The 4.0.x installation still uses on the gpt-packaged openssl. The trunk uses the external openssl code.
