Bug 4617 - OpenSSL need to be upgraded
: OpenSSL need to be upgraded
Status: RESOLVED FIXED
: GSI C
Credentials and Proxies
: 4.0.2
: PC Windows XP
: P3 major
: ---
Assigned To:
:
:
: 4743
: 6192
  Show dependency treegraph
 
Reported: 2006-07-25 12:55 by
Modified: 2008-08-11 13:55 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-07-25 12:55:59
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
------- Comment #1 From 2006-07-26 13:22:55 -------
Just my $.02: That this seems reasonable.
------- Comment #2 From 2006-07-27 10:19:49 -------
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.
------- Comment #3 From 2006-09-07 09:40:00 -------
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
------- Comment #4 From 2006-09-07 11:26:41 -------
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.  
------- Comment #5 From 2006-09-07 12:47:33 -------
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
------- Comment #6 From 2006-09-07 13:35:03 -------
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
------- Comment #7 From 2006-09-07 13:49:50 -------
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.
------- Comment #8 From 2006-09-18 15:41:24 -------
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.
------- Comment #9 From 2006-10-03 11:00:03 -------
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
------- Comment #10 From 2006-11-21 16:43:19 -------
Any update on the status of this?

Thanks!
------- Comment #11 From 2006-11-21 18:58:33 -------
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.
------- Comment #12 From 2007-06-08 03:51:39 -------
>       - if there is an unhandled critical extension (unless the user
>         has chosen to ignore this fault)

How to ignore the fault in SSL application?
------- Comment #13 From 2007-12-06 15:16:07 -------
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
------- Comment #14 From 2007-12-06 17:30:03 -------
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
------- Comment #15 From 2007-12-07 09:28:32 -------
Added the patches to the same wiki page (can't attach to bugzilla anymore).
------- Comment #16 From 2008-02-26 14:15:50 -------
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.