Re: McAfee Claims TLS Vulnerability
On Sun, Apr 29, 2012 at 5:40 PM, Mike Hoy mho...@gmail.com wrote: We use McAfee to scan our website for vulnerabilities. They claim the following: Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available. I ran #openssl version and it says we are using OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008. Do we need to upgrade our OpenSSL to upgrade our TLS/SSL server? Sorry if the question is way off-base but I am not a system administrator normally. This is new to me. We use CentOS and #yum install openssl claims it is already at the higest version. Any suggestions appreciated. Use a SSL/TLS scanner to verify SSL is not available; and TLS ciphers are available. Since you are using a FIPS build, MD5 and lesser friends should not be available. You can use openssl from the command line, or a tool such as http://sourceforge.net/projects/sslscan/ or http://code.google.com/p/sslyze/. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1b released, invalid tar file!
In the past, I have had issues with tar files where the block size wasn't specified, and the file was a multiple of 512 but not of 10240. My solution was to pad out to a multiple of 10240. On 30 April 2012 13:22, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of jb-open...@wisemo.com Sent: Thursday, 26 April, 2012 19:37 On 26-04-2012 15:05, Thomas J. Hruska wrote: ... This archive under 7-Zip 9.20 (latest stable) displays a There are no trailing zero-filled records error dialog but then proceeds to work just fine. ... This is not limited to 7-Zip, see also the post by Mr. Bergeron of IBM. I didn't see that one, but a few more data points: Ancient Solaris (5.)8 says tar: read error: unexpected EOF but has in fact extracted or listed last file (VMS/WISHLIST.TXT) okay. Ancient AIX 4.3 goes into an apparently infinite loop on the last 8 files (!) but seems to have extracted/listed okay. Of the downloads I have at hand (about a year), the others with less than 2x512 zero at the end are 0.9.8q and 1.0.0-beta4 . 0.9.8q produces same symptoms but 1.0.0-beta4 does not. Blech. WinZip 12 is happy. As is gnu tar 1.13.19 1.14 1.15.1. I'm not startled by that; gnu programs in general usually tolerate slight nonstandardness, and often not-so-slight. This may be exchange for the nonstandardness they create. I have looked closer at the tar.gz file (my download matches the checksums and digital signature from Dr. Henson), and the file is not valid according to the tar file format specifications that I have looked at. According to the basic tar specification, each file is prefixed by a 512 byte header with filename, size etc. and zero padded to a multiple of 512 bytes, and the last file is followed by at least 2x512 bytes of all-zero bytes to indicate end of file. ... But the tar file inside the gzip file openssl-1.0.1b.tar.gz lacks those last 1024 bytes of zeroes. ... -- Christopher Vance __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect expiration of server certification
In many cases, errors about no longer valid certificates (expired, revoked, bad signature etc.) are checked only by the other end, so the *client* would show errors about a bad server cert and the server would show errors about bad client certs. While some server applications may contain extra code to check their own certificate before using it, not all do. In your own server code, you can check the servers own certificate by explicitly verifying it with X509 functions before using it with the SSL functions, thus not relying on the SSL code checking that the certificates you give it are valid. Look at the sample source code for the openssl verify command for examples of how this can be done (You obviously won't have to load the certificate an extra time as you are loading it anyway, and you need to check it against the root certificate in your own server certificate chain, not the collection of root certificates you trust for client certificates). On 4/30/2012 7:04 AM, 谷口康規 wrote: Hi. Help me please. I'm beginner. I'm tring to print message of expiration of server certificate on the side of SSL server.(server authentication) But, I can't find how to get the alert from error code. I think SSL_AD_CERTIFICATE_EXPIRED or SSL3_AD_CERTIFICATE_EXPIRED is the error code. However, the above code is only found in error-verification-function(?) (ssl_verify_alarm_type() and so on). In addition, when expiration of certificate happen ? During SSL_accept, SSL_read and so on, Does it ? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ECDH vs. ECDHE
Hello, I'm trying to make sense out of the various abbrevations used for the SSL cipher suites listed by openssl ciphers. I've googled, but found no explanation of what ECDHE is and how it compares to ECDH. I'm aware that ECDH stands for elliptic curve diffie hellman key exchange (and I'm also - cryptographically - aware what that means - perfect forward secrecy and such). What is ECDHE, is it better than just ECDH and what's the difference? Yours, -- Hanno Böck mail/jabber: ha...@hboeck.de GPG: BBB51E42 http://www.hboeck.de/ signature.asc Description: PGP signature
Re: McAfee Claims TLS Vulnerability
On Sun, Apr 29, 2012, Mike Hoy wrote: We use McAfee to scan our website for vulnerabilities. They claim the following: Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available. I ran #openssl version and it says we are using OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008. Do we need to upgrade our OpenSSL to upgrade our TLS/SSL server? Sorry if the question is way off-base but I am not a system administrator normally. This is new to me. We use CentOS and #yum install openssl claims it is already at the higest version. Any suggestions appreciated. FYI: this is most likely the BEAST attack it is referring to. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1b released, invalid tar file!
quick update (sorry I was on a 3 days weekend) the tar which was causing me this problem is the one on AIX 6.1 TL6 SP6 GNU tar 1.26 is working and being used as a workaround. Yannick Bergeron 450 534-7711 yaber...@ca.ibm.com Advisory IT Specialist From: Christopher Vance cjsva...@gmail.com To: openssl-users@openssl.org Date: 2012-04-30 04:33 Subject:Re: OpenSSL 1.0.1b released, invalid tar file! Sent by:owner-openssl-us...@openssl.org In the past, I have had issues with tar files where the block size wasn't specified, and the file was a multiple of 512 but not of 10240. My solution was to pad out to a multiple of 10240. On 30 April 2012 13:22, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of jb-open...@wisemo.com Sent: Thursday, 26 April, 2012 19:37 On 26-04-2012 15:05, Thomas J. Hruska wrote: ... This archive under 7-Zip 9.20 (latest stable) displays a There are no trailing zero-filled records error dialog but then proceeds to work just fine. ... This is not limited to 7-Zip, see also the post by Mr. Bergeron of IBM. I didn't see that one, but a few more data points: Ancient Solaris (5.)8 says tar: read error: unexpected EOF but has in fact extracted or listed last file (VMS/WISHLIST.TXT) okay. Ancient AIX 4.3 goes into an apparently infinite loop on the last 8 files (!) but seems to have extracted/listed okay. Of the downloads I have at hand (about a year), the others with less than 2x512 zero at the end are 0.9.8q and 1.0.0-beta4 . 0.9.8q produces same symptoms but 1.0.0-beta4 does not. Blech. WinZip 12 is happy. As is gnu tar 1.13.19 1.14 1.15.1. I'm not startled by that; gnu programs in general usually tolerate slight nonstandardness, and often not-so-slight. This may be exchange for the nonstandardness they create. I have looked closer at the tar.gz file (my download matches the checksums and digital signature from Dr. Henson), and the file is not valid according to the tar file format specifications that I have looked at. According to the basic tar specification, each file is prefixed by a 512 byte header with filename, size etc. and zero padded to a multiple of 512 bytes, and the last file is followed by at least 2x512 bytes of all-zero bytes to indicate end of file. ... But the tar file inside the gzip file openssl-1.0.1b.tar.gz lacks those last 1024 bytes of zeroes. ... -- Christopher Vance __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect expiration of server certification
Just try to connect with openssl_client to the server and you would see the message Rgds Aravamudan On Mon, Apr 30, 2012 at 10:34 AM, 谷口康規 taniguchi.y...@jp.fujitsu.comwrote: Hi. Help me please. I'm beginner. I'm tring to print message of expiration of server certificate on the side of SSL server.(server authentication) But, I can't find how to get the alert from error code. I think SSL_AD_CERTIFICATE_EXPIRED or SSL3_AD_CERTIFICATE_EXPIRED is the error code. However, the above code is only found in error-verification-function(?) (ssl_verify_alarm_type() and so on). In addition, when expiration of certificate happen ? During SSL_accept, SSL_read and so on, Does it ? Regards, bobyt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1b released, invalid tar file!
On 4/27/2012 9:43 AM, Dr. David Kirkby wrote: On 04/27/12 02:29 AM, Dr. Stephen Henson wrote: Hmm never seen any error messages myself, using GNU tar 1.25. The distribution tarballs are always created by doing: make -f Makefile.org dist from any source tree. As you can see from the files this makes use of tar and tardy. The tar version I used was GNU tar 1.25 and tardy version 1.20.D001. If someone can sugest alternative versions or options that will avoid this in future I'll incorporate them into the distrubution. Steve. I know GNU tar sometimes produces archives the Sun version of tar can't open. Yes, but that difference is about variations deeper inside the format, not the end-of-file record which is the same for all the tar variants implemented by GNU tar. The GNU tar documentation http://www.gnu.org/software/tar/manual/tar.html#SEC130 makes for interesting reading. Note this bit. The default format for GNU tar is defined at compilation time. You may check it by running tar --help, and examining the last lines of its output. Usually, GNU tar is configured to create archives in ‘gnu’ format, however, future version will switch to ‘posix’. All the forms that GNU tar supports as output have the terminating all 0 2x512 bytes. See also http://www.gnu.org/software/tar/manual/html_section/Portability.html I also know that Joerg Schilling http://en.wikipedia.org/wiki/J%C3%B6rg_Schilling the author of cdrecord and mkisofs has been very critical of GNU tar. See for ftp://ftp.berlios.de/pub/star/README.otherbugs He has developed star http://developer.berlios.de/projects/star which he has said produces POSIX compliant tar files. Mr. Schilling can be quite a difficult man to work with and sometimes perpetuates old information beyond its relevancy. That said, his list of GNU tar bugs does seem to include one that is halfway the bug in tardy modified GNU tar output we are looking at. (Mr. Schilling reports that an unidentified old version of GNU tar sometimes only outputs 1x512 bytes of zeroes). So if someone is running a non Linux system, it does not surprise me the GNU tar is not working for them. Given the POSIX standard has been out over a decade, perhaps you using the option for posix, which GNU apparently intends using one day, might help. But this topic does seem a bit of a can of worms. Note that the hard test for good tar archives that I have been using is not to run it through some known to complain tar unpacker and look for the error message, but to simply run the following pipe zcat openssl-1.0.1b.tar.gz | tail -c 10752 | od -A x -t x1z A valid tar file should show that this includes a 0x200 aligned sequence of at least 0x400 all 0 bytes followed by arbitrary junk (preferable any bytes after those 0x400 bytes are 0 too, but this is not mandatory). The openssl-1.0.1b.tar.gz had NONE of the required 0 bytes. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl0.9.8{v,w} return signal 4 Illegal instruction on cpu amd geode-lx and VIA Nehemiah
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Good evening, I have a some problem with openssl {v,w} and cpu via
Nehemiah, the version t work fine.
thank you
- --
Corrado Roberto
Key ID: 0x6D7865E1 (c/o keyringservers)
Fingerprint: A743 2BB6 7E75 C26A 3BD5 0E22 5953 A82F 6D78 65E1
root@gatto:/tmp# gdb -c core /usr/bin/openssl
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as i486-slackware-linux.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/openssl...(no debugging symbols
found)...done.
[New LWP 11782]
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need set solib-search-path or set sysroot?
Core was generated by openssl version'.
Program terminated with signal 4, Illegal instruction.
#0 0xb76bc1f3 in _init () from /usr/lib/libcrypto.so.0
(gdb) disassemble
Dump of assembler code for function _init:
0xb76bc1d0 +0: push %ebx
0xb76bc1d1 +1: sub$0x8,%esp
0xb76bc1d4 +4: call 0xb76bc840
0xb76bc1d9 +9: add$0x12c697,%ebx
0xb76bc1df +15:mov-0x220(%ebx),%eax
0xb76bc1e5 +21:test %eax,%eax
0xb76bc1e7 +23:je 0xb76bc1ee _init+30
0xb76bc1e9 +25:call 0xb76bc4d0 __gmon_start__@plt
0xb76bc1ee +30:call 0xb76bc970
= 0xb76bc1f3 +35:nopw %cs:0x0(%eax,%eax,1)
0xb76bc1fd +45:nopl (%eax)
0xb76bc200 +48:call 0xb76bcc10 OPENSSL_cpuid_setup
0xb76bc205 +53:jmp0xb76bc210 _init+64
0xb76bc207 +55:mov%esi,%esi
0xb76bc209 +57:lea0x0(%edi,%eiz,1),%edi
0xb76bc210 +64:call 0xb7797110
0xb76bc215 +69:add$0x8,%esp
0xb76bc218 +72:pop%ebx
0xb76bc219 +73:ret
End of assembler dump.
(gdb)
root@gatto:/tmp# file /usr/bin/openssl
/usr/bin/openssl: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), stripped
root@gatto:/tmp# ldd /usr/bin/openssl
linux-gate.so.1 (0xe000)
libssl.so.0 = /usr/lib/libssl.so.0 (0xb7833000)
libcrypto.so.0 = /usr/lib/libcrypto.so.0 (0xb76be000)
libdl.so.2 = /lib/libdl.so.2 (0xb76a6000)
libc.so.6 = /lib/libc.so.6 (0xb7524000)
/lib/ld-linux.so.2 (0xb7883000)
root@gatto:/tmp# ls -la /usr/lib/libssl.so.0
lrwxrwxrwx 1 root root 15 apr 26 23:10 /usr/lib/libssl.so.0 -
libssl.so.0.9.8*
root@gatto:/tmp# ls -la /usr/lib/libcrypto.so.0
lrwxrwxrwx 1 root root 18 apr 26 23:10 /usr/lib/libcrypto.so.0 -
libcrypto.so.0.9.8*
root@gatto:/tmp# ls -la /lib/libdl.so.2
lrwxrwxrwx 1 root root 13 apr 9 11:15 /lib/libdl.so.2 -
libdl-2.15.so*
root@gatto:/tmp# ls -la /lib/libc.so.6
lrwxrwxrwx 1 root root 12 apr 9 11:15 /lib/libc.so.6 -
libc-2.15.so*
root@gatto:/tmp# ls -la /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 10 apr 9 11:15 /lib/ld-linux.so.2 -
ld-2.15.so*
root@gatto:/tmp# ulimit -c unlimited ; openssl version
Istruzione non consentita (core dumped)
root@gatto:/tmp# md5sum /usr/lib/libssl.so.0.9.8
9ce231061b4d81ec05900b78ae5a21d5 /usr/lib/libssl.so.0.9.8
root@gatto:/tmp# md5sum /usr/lib/libcrypto.so.0.9.8
60ae97ce913640c14185dc36043ad489 /usr/lib/libcrypto.so.0.9.8
root@gatto:/tmp# md5sum /lib/libdl.so.2
3e618dde429137a1c664f7fcf2dd0be4 /lib/libdl.so.2
root@gatto:/tmp# md5sum /lib/libc.so.6
5f9228c7986feb91d0793cefe81cd151 /lib/libc.so.6
root@gatto:/var/named/internet# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping: 8
cpu MHz : 1000.377
cache size : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx
fxsr sse rng rng_en ace ace_en
bogomips: 2000.75
clflush size: 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.6 OE plugin - Corrado Roberto
iD8DBQFPmxIwWVOoL214ZeERAlZRAKCFzFg5jhvB8wrOHobXL/Xh1e/FxgCfSeM8
Xzn5zPVUC87bD4eNXCAWnCU=
=leSc
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: McAfee Claims TLS Vulnerability
On Sun, Apr 29, 2012 at 10:40 PM, Mike Hoy mho...@gmail.com wrote: We use McAfee to scan our website for vulnerabilities. They claim the following: Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available. What kind of crazy advice is this? I ran #openssl version and it says we are using OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008. Do we need to upgrade our OpenSSL to upgrade our TLS/SSL server? Sorry if the question is way off-base but I am not a system administrator normally. This is new to me. We use CentOS and #yum install openssl claims it is already at the higest version. Any suggestions appreciated. Thanks, -- Mike Hoy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: McAfee Claims TLS Vulnerability
Perhaps it's related to CVE-2011-4576: https://kc.mcafee.com/corporate/index?page=contentid=KB75138actp=LIST and http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4576 The SSL 3.0 implementation in OpenSSL before 0.9.8s and 1.x before 1.0.0f does not properly initialize data structures for block cipher padding, which might allow remote attackers to obtain sensitive information by decrypting the padding data sent by an SSL peer. Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 | paul.suh...@quantum.com Preserving the World's Most Important Data. Yours.T -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ben Laurie Sent: Monday, April 30, 2012 1:32 AM To: openssl-users@openssl.org Subject: Re: McAfee Claims TLS Vulnerability On Sun, Apr 29, 2012 at 10:40 PM, Mike Hoy mho...@gmail.com wrote: We use McAfee to scan our website for vulnerabilities. They claim the following: Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available. What kind of crazy advice is this? -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDH vs. ECDHE
ECDHE is the E=Ephemeral version where you get a distinct DH key for every handshake. ECDH has a fixed DH key; one side of the handshake doesn't change from one instance to the next. ECDHE gives you forward secrecy; ECDH does not. ECDHE is less efficient than ECDH; it requires more crypto operations. They also differ in how the handshake gets authenticated. (ECDH is sort of implicit and ECDHE explicit.) Note that unless you explicitly tell it not to, OpenSSL will reuse DH keys anyway in ECDHE for performance reasons. This may or may not be a problem for you depending on how your application is being launched. BBB On Mon, Apr 30, 2012 at 3:27 AM, Hanno Böck ha...@hboeck.de wrote: Hello, I'm trying to make sense out of the various abbrevations used for the SSL cipher suites listed by openssl ciphers. I've googled, but found no explanation of what ECDHE is and how it compares to ECDH. I'm aware that ECDH stands for elliptic curve diffie hellman key exchange (and I'm also - cryptographically - aware what that means - perfect forward secrecy and such). What is ECDHE, is it better than just ECDH and what's the difference? Yours, -- Hanno Böck mail/jabber: ha...@hboeck.de GPG: BBB51E42 http://www.hboeck.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl0.9.8{v,w} return signal 4 Illegal instruction on cpu amd geode-lx and VIA Nehemiah
On 30-04-2012 17:40, Roberto Corrado wrote:
Good evening, I have a some problem with openssl {v,w} and cpu via
Nehemiah, the version t work fine.
root@gatto:/tmp# gdb -c core /usr/bin/openssl
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as i486-slackware-linux.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/openssl...(no debugging symbols
found)...done.
[New LWP 11782]
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need set solib-search-path or set sysroot?
Core was generated by openssl version'.
Program terminated with signal 4, Illegal instruction.
#0 0xb76bc1f3 in _init () from /usr/lib/libcrypto.so.0
(gdb) disassemble
Dump of assembler code for function _init:
0xb76bc1d0+0: push %ebx
0xb76bc1d1+1: sub$0x8,%esp
0xb76bc1d4+4: call 0xb76bc840
0xb76bc1d9+9: add$0x12c697,%ebx
0xb76bc1df+15:mov-0x220(%ebx),%eax
0xb76bc1e5+21:test %eax,%eax
0xb76bc1e7+23:je 0xb76bc1ee_init+30
0xb76bc1e9+25:call 0xb76bc4d0__gmon_start__@plt
0xb76bc1ee+30:call 0xb76bc970
= 0xb76bc1f3+35:nopw %cs:0x0(%eax,%eax,1)
0xb76bc1fd+45:nopl (%eax)
0xb76bc200+48:call 0xb76bcc10OPENSSL_cpuid_setup
0xb76bc205+53:jmp0xb76bc210_init+64
0xb76bc207+55:mov%esi,%esi
0xb76bc209+57:lea0x0(%edi,%eiz,1),%edi
0xb76bc210+64:call 0xb7797110
0xb76bc215+69:add$0x8,%esp
0xb76bc218+72:pop%ebx
0xb76bc219+73:ret
End of assembler dump.
(gdb)
For clarity, could you please add the following info:
1. Actual 12 hex code bytes from 0xb76bc1f3 to 0xb76bc1ff inclusive.
2. Arguments passed to the openssl build scripts, including any
environment variables
3. The versions of gcc and libc used when building the failing copy of
openssl.
4. If any of those were different for your compile of 0.9.8t
As this failure happens in compiler/libc init code, I strongly suspect
#4 is the problem.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
