Bug 88018 - openssl update 2003:101-15 incompatible with ubsec hwcrypto?
openssl update 2003:101-15 incompatible with ubsec hwcrypto?
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: openssl (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-04 12:46 EST by Rich Graves
Modified: 2007-04-18 12:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-04 11:03:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rich Graves 2003-04-04 12:46:02 EST
Description of problem:
After updating from openssl-0.9.6b-31 to openssl-0.9.6b-33, all applications
linked with OpenSSL fail all RSA operations. OpenSSH, Apache, imapd. Reverting
to openssl-0.9.6b-31 restores service.

Version-Release number of selected component (if applicable):
openssl-0.9.6b-33

How reproducible:
Always

Steps to Reproduce:
1. Get a box with a bcm5820 SSL accelerator card
2. Edit /usr/share/ssl/openssl.cnf to set [engine] default = ubsec
3. Update to openssl-0.9.6b-33

Additional info:

I'm running kernel 2.4.18-19.8.0smp (I have updated further but have not
rebooted), openssl-0.9.6b-33, bcm5820 Cryptonet driver (Dell-OEM Broadcom SSL
accelerator).

/usr/share/ssl/openssl.cnf has

[ engine ]
default = ubsec

I will try the obvious troubleshooting steps of rebooting with new kernel and
removing the "default = ubsec" when I can schedule the downtime, but am posting
this early in case anyone else has input. I do not have a surplus test machine
with an SSL accelerator card.
Comment 1 Kevin M. Myer 2003-04-11 07:53:23 EDT
I got bit by this as well, only I'm still running RedHat 7.3.  I'm running
openssl-0.9.6b-32.7 and that appears to broken with respect to hwcrypto. 
Earlier versions of openssl worked and I'm also running
kernel-smp-2.4.18-27.7.x.  The crypto card is an BroadCom card and simply
stopping the bcm5820 service caused the problem to go away.

Recompiling the hwcrypto package didn't seem to help any.  I haven't modified my
openssl.cnf file (default is still set to openssl) but as I understand it,
openssl will use the card if its available so I think we're running basically
the same config.
Comment 2 Ireneusz Nowak 2003-04-16 06:15:27 EDT
redhat linux 7.3

openssl-0.9.6b-32.7

the same with 0.9.6b-18 and  0.9.6b-30

[engine]
default=ubsec

Broadcom bcm5820
kernel /vmlinuz-2.4.18-27.7.xsmp


[iro@web1 ssl]$ /www/ssl/bin/openssl s_client -connect web2:443 -state -debug
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 08188710 [08188FB8] (142 bytes => 142 (0x8E))
0000 - 80 8c 01 03 01 00 63 00-00 00 20 00 00 39 00 00   ......c... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0   8..5............
0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 66 00   ..3..2../.....f.
0030 - 00 05 00 00 04 01 00 80-08 00 80 00 00 63 00 00   .............c..
0040 - 62 00 00 61 00 00 15 00-00 12 00 00 09 06 00 40   b..a...........@
0050 - 00 00 65 00 00 64 00 00-60 00 00 14 00 00 11 00   ..e..d..`.......
0060 - 00 08 00 00 06 04 00 80-00 00 03 02 00 80 54 f5   ..............T.
0070 - ad 5b 9c 6a fa 01 fe 12-24 a6 d7 e2 b7 bb 11 3a   .[.j....$......:
0080 - 6f 92 e9 07 86 33 bb 71-45 1f e4 4d 47 4c         o....3.qE..MGL
SSL_connect:SSLv2/v3 write client hello A
read from 08188710 [0818E518] (7 bytes => 0 (0x0))
22195:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:


service bcm5820 stop 

causes ssl services to run...

does it mean that I've bought something that is certified by linux and doesn't
work ?? (dell poweredge 2650)

best regards 

Ireneusz Nowak
Comment 3 Rich Graves 2003-04-18 19:56:17 EDT
I confirm version independence (affects 7.3 as well) and fact that stopping the
bcm5820 service fixes the problem. But this means you're not using the SSL
accelerator card at all.

I've cross-posted a message to

http://forums.us.dell.com/supportforums/board/message?board.id=pes_linux&message.id=1036
Comment 4 Kevin M. Myer 2003-05-01 12:45:08 EDT
Ok, I've done some research and testing on this since Red Hat still has this bug
marked as NEW.  It appears that what breaks the hardware acceleration is the
blinding patch that came out of the following advisory:

http://www.openssl.org/news/secadv_20030317.txt

Its not immediately clear to me just how widespread the impact is - the original
application that exhibited the vulnerability appears to be stunnel.  It would
seem to make more sense to leave blinding off by default and enable it on a
per-vulnerable application basis, rather than turning it on by default and
breaking non-vulnerable applications.  This assumes that Apache w/mod_ssl and
hardware accleration isn't vulnerable to this attack but I'm neither a
programmer or a cryptography expert so my assumption may be wrong.

Or maybe the bcm5820 module needs reworked to deal with blinding in a better
way.  I'm disappointed Red Hat hasn't at least acknowledged this bug - it
reminds me of several other show stoppers in the past that took a long time to
get acknowledged and resolved - the Apache/PHP/mm leaking semaphore problem and
the upgrade-glibc-and-break-remote-MySQL-connections problem.  I can get that
kind of support, stability, and upgrade quality-assurance from a vendor from
Redmond (of course I'd have to pay a lot more to get it ;)

For anyone having this problem, I'd propose, as a workaround, disabling the
openssl-sec3-blinding patch.  You'll have to recompile the RPM for this to take
effect obviously but being vulnerable to a blinding attack might be better than
having broken hardware encryption accelerator support.  The usual standard
disclaimers apply to that suggestion but thats the best I know to do at this point.
Comment 5 Kevin M. Myer 2003-05-01 12:50:07 EDT
I guess I have to eat crow - web servers are vulnerable, as stated in the
original research paper, which I just found at:

http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

So I guess the best approach is try and fix the bcm5820 module or modify OpenSSL
to do something different if HW crypto is being used...
Comment 6 Kevin M. Myer 2003-10-14 09:07:01 EDT
Hello?  Does anyone work at Red Hat anymore?  Has it dawned on Red Hat that this
bug has been setting at a status of "NEW" since April 4, 2003 with no Red Hat
response at all? What kind of noise does one have to make to actually get a bug
acknowledged, let alone fixed?  

For what its worth, it appears that the multithreading blinding patch fixes the
previous hardware crypto break introduced by the original blinding patch.  I'm
just disappointed that no one at Red Hat apparently even looked at this bug or
responded to it.  Thats poor customer service.

Comment 7 Mark J. Cox (Product Security) 2003-10-14 09:16:46 EDT
A ubsec fix was added in 0.9.6b-33.7 along with other blinding fixes, so does
the OpenSSL packages as part of this errata solve your problems? 

http://rhn.redhat.com/errata/RHSA-2003-291.html
Comment 8 Kevin M. Myer 2003-10-21 12:02:04 EDT
Yes, see my comment #6 - it appears to be fixed with that patch.  A note on this
bug when 33.7 was released would have been helpful and that omission is all I'm
trying to point out.

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