1.0.1a build failure on OS X
I just tried building 1.0.1a on OS X (Lion, if it matters), and it failed with: Undefined symbols for architecture x86_64: _rc4_md5_enc, referenced from: _rc4_hmac_md5_cipher in libcrypto.a(e_rc4_hmac_md5.o) ld: symbol(s) not found for architecture x86_64 Looking through the CVS logs, I found: 2011-Nov-15 13:39 1.1.2.4 Check-in [21726] on branch OpenSSL_1_0_1-stable: e_rc4_hmac_md5.c: make it work on darwin64, which is configured with RC4_CHAR. By appro. (diff) and applying that patch appears to fix the problem, but it looks like it was reverted (possibly unintentionally?) in 1.1.2.4.2.1 and 1.1.2.5.__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Also - any idea if BBN is using OpenSSL? --Sandy From: owner-openssl-...@openssl.org [owner-openssl-...@openssl.org] on behalf of OpenSSL [open...@master.openssl.org] Sent: Thursday, April 19, 2012 9:04 AM To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL Security Advisory -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [19 Apr 2012] === ASN1 BIO vulnerability (CVE-2012-2110) === A potentially exploitable vulnerability has been discovered in the OpenSSL function asn1_d2i_read_bio. Any application which uses BIO or FILE based functions to read untrusted DER format data is vulnerable. Affected functions are of the form d2i_*_bio or d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp. Applications using the memory based ASN1 functions (d2i_X509, d2i_PKCS12 etc) are not affected. In particular the SSL/TLS code of OpenSSL is *not* affected. Applications only using the PEM routines are not affected. S/MIME or CMS applications using the built in MIME parser SMIME_read_PKCS7 or SMIME_read_CMS *are* affected. The OpenSSL command line utility is also affected if used to process untrusted data in DER format. Note: although an application using the SSL/TLS portions of OpenSSL is not automatically affected it might still call a function such as d2i_X509_bio on untrusted data and be vulnerable. Thanks to Tavis Ormandy, Google Security Team, for discovering this issue and to Adam Langley a...@chromium.org for fixing it. Affected users should upgrade to OpenSSL 1.0.1a, 1.0.0i or 0.9.8v. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20120419.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT5AJh6LSm3vylcdZAQII+Af/dPNEQrJZ6YHlytaMW6zvkG64pvYBLuoO BdJQnFBR3oWolOIQDyFD7byECly/czVHA5mTifsG+XyHeLHB5Zr2PsnLBLj3d6Su verXPt8JU/XQb+Rhn1P9F32qTMwhZkgNcjV3eOprpUBD7qNz+nQd1pJtlKX3asmK wtVYyX6Dbbe61GQ6nDxT4fLpAL6Yk/YJH3jRA/R4MW/0vyJzYCALKiCsFuAzp2Fl Ov5n3Gkn+Y+1jaaGpqNxdWv1F3OI8vieC4lN4CfbaDDkQxNCNBRwcucK/tBBKAxK 3gravlQDuqnGn3M6GOpVJ89hZaPscMvsKx80jUKZtn2kPBaC7NxYeQ== =91XR -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Compile error with MinGW-w64
On 16/04/2012 2:31 AM, Andy Polyakov wrote: What happens if you add wait; at the very end of crypto/asm/sha1-x86_64.pl? It just hangs. 'which perl'? If not /bin/perl, i.e. non-MSYS perl, then I'd suggest to complement MSYS installation with MSYS perl. It works with MSYS perl. Thanks. I was using Strawberry Perl and ActivePerl with MSYS and they didn't work. They work fine in Cygwin though and in MSYS with earlier OpenSSL versions. Strange. Regards, Jonathan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2794] [PATCH] Remove branch hint to improve crypto algorithms performance on Power
The not-taken branch hint in the assembly code causes performance degradation as the hardware always predict the specific branch that way. The branch hint is not necessary as the hardware prediction is very good and getting better. The patch attached removed the branch hint to let the hardware do the prediction. To see the performance improvements build with -mcpu=power7 (or whatever hardware it's running on), since the hints may get ignored if the compiler defaults to targeting an older version of the hardware (Power4). Below is the performance results built with -mcpu=power7. The positive number shows performance improvements percentage after the branch hint is removed. The performance test used openssl speed then calculate the percentage using the results from the branch hint removed and the results from the base (with branch hint). Percentage=(withoutHint/withHint) * 100 - 100 sha512 shows 32% performance improvements. sha256, sha1, md4, and md5 also benefit from this change. There are some negative numbers but they are very small (less than 1%). type 16bytes 64bytes 256bytes 1024bytes 8192bytes mdc2 1.57 0.43 0.07 0.030.01 md46.6 6.6 4.47 2.5 0.35 md56.9 5.65 3.68 1.440.23 hmac(md5) 0.35 0.01 0.42 0.120 sha1 7.29 6.46 4.35 2.210.42 sha256 18.35 10.99 5.05 1.640.24 sha512 31.85 32.08 13.72 4.950.67 whirlpool 0.69 0.66 0.44 0.330.31 rmd160 6.61 4.96 3.08 1.320.36 rc4-0.01 -0.02 -0.19 -0.14 -0.22 descbc 0.04 -00.02 0.070.04 desede3-0.02 0.01 0 -0 0.01 aes-1280.05 -0-0 0 0.01 aes-1920.04 -0.01 -0 0.010 aes-2560.08 -0.01 0 0.010.01 aes-1280.02 0.03 -0.01 -0.01 -0.1 aes-1920 0.01 0.02 0.01-0.08 aes-2560 0.02 0.01 -0 -0.07 ghash 0.51 0.36 0.06 0.02-0.01 camellia-128 -0.34 -0.03 -0.02 -0.18 -0.69 camellia-192 -0.26 0.22 0.11 0.07-0.26 camellia-256 -0.23 0.03 -0.01 -0.04 -0.32 idea 0.18 0.07 0.020 0.02 seed 0.02 0.06-0.040.040.06 rc20.04 0 -0 0 0.01 blowfish 0.26 0.09-0.09 -0.04-0 cast 0.14 0.040.020.01 0 Please let me know if you have any questions. Thanks, Ashley Lai diff -ur openssl-1.0.1/crypto/ppccpuid.pl openssl-1.0.1-wp/crypto/ppccpuid.pl --- openssl-1.0.1/crypto/ppccpuid.pl 2011-11-14 14:52:33.0 -0600 +++ openssl-1.0.1-wp/crypto/ppccpuid.pl 2012-04-18 16:47:53.098711478 -0500 @@ -105,7 +105,7 @@ Little: mtctr r4 stb r0,0(r3) addi r3,r3,1 - bdnz- \$-8 + bdnz \$-8 blr Lot: andi. r5,r3,3 beq Laligned @@ -118,7 +118,7 @@ mtctr r5 stw r0,0(r3) addi r3,r3,4 - bdnz- \$-8 + bdnz \$-8 andi. r4,r4,3 bne Little blr
Re: [openssl.org #2794] [PATCH] Remove branch hint to improve crypto algorithms performance on Power
The alignments of the performance results I did before sending it out did not come out right, my apologies. Please find my performance results spreadsheet attached. Regards, Ashley Lai On Wed, 2012-04-18 at 18:52 -0500, Ashley Lai wrote: The not-taken branch hint in the assembly code causes performance degradation as the hardware always predict the specific branch that way. The branch hint is not necessary as the hardware prediction is very good and getting better. The patch attached removed the branch hint to let the hardware do the prediction. To see the performance improvements build with -mcpu=power7 (or whatever hardware it's running on), since the hints may get ignored if the compiler defaults to targeting an older version of the hardware (Power4). Below is the performance results built with -mcpu=power7. The positive number shows performance improvements percentage after the branch hint is removed. The performance test used openssl speed then calculate the percentage using the results from the branch hint removed and the results from the base (with branch hint). Percentage=(withoutHint/withHint) * 100 - 100 sha512 shows 32% performance improvements. sha256, sha1, md4, and md5 also benefit from this change. There are some negative numbers but they are very small (less than 1%). type 16bytes 64bytes 256bytes 1024bytes 8192bytes mdc2 1.57 0.43 0.07 0.030.01 md4 6.6 6.6 4.47 2.5 0.35 md5 6.9 5.65 3.68 1.440.23 hmac(md5) 0.35 0.010.42 0.120 sha1 7.29 6.46 4.35 2.210.42 sha256 18.35 10.99 5.05 1.640.24 sha512 31.85 32.08 13.72 4.950.67 whirlpool 0.690.66 0.44 0.330.31 rmd160 6.61 4.96 3.08 1.320.36 rc4 -0.01 -0.02 -0.19 -0.14 -0.22 descbc 0.04 -00.02 0.070.04 desede3 -0.02 0.01 0 -0 0.01 aes-128 0.05 -0-0 0 0.01 aes-192 0.04 -0.01 -0 0.010 aes-256 0.08 -0.01 0 0.010.01 aes-128 0.02 0.03 -0.01 -0.01 -0.1 aes-192 0 0.01 0.02 0.01-0.08 aes-256 0 0.02 0.01 -0 -0.07 ghash0.51 0.36 0.06 0.02-0.01 camellia-128 -0.34 -0.03 -0.02 -0.18 -0.69 camellia-192 -0.26 0.22 0.11 0.07-0.26 camellia-256 -0.23 0.03 -0.01 -0.04 -0.32 idea 0.18 0.07 0.020 0.02 seed 0.02 0.06-0.040.040.06 rc2 0.04 0 -0 0 0.01 blowfish 0.260.09-0.09 -0.04-0 cast 0.14 0.040.020.01 0 Please let me know if you have any questions. Thanks, Ashley Lai opensslPerfRmHint.ods Description: application/vnd.oasis.opendocument.spreadsheet
[openssl.org #2795] openssl-1.0.1a - undefined symbol: OPENSSL_ia32cap_P with ultrasparc cpus (solution inside)
Hi,
i got following error, when building the new openssl-1.0.1a package on a Sun
Solaris 10 operation system with an UltraSPARC cpu:
make[3]: Entering directory `/home/df/openssl-1.0.1a'
[ -z ] || /opt/sunstudio/bin/cc -KPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra
-xarch=v9 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM -Iinclude \
-DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \
fips_premain.c fipscanister.o \
libcrypto.a -lsocket -lnsl -ldl -R/home/df/lib
make[4]: Entering directory `/home/df/openssl-1.0.1a'
make[5]: Entering directory `/home/df/openssl-1.0.1a'
Undefined first referenced
symbol in file
OPENSSL_ia32cap_P libcrypto.a(e_rc4_hmac_md5.o)
ld: warning: Symbol referencing errors
make[5]: Leaving directory `/home/df/openssl-1.0.1a'
make[5]: Entering directory `/home/df/openssl-1.0.1a'
I figured out that the bottom of
openssl-1.0.1-a/crypto/evp/e_rc4_hmac_md5.c was modified in 1.0.1a and
utilizes the non-existing OPENSSL_ia32cap_P.
I quickly looked into the code and made following patch:
--- openssl-1.0.1a-Original/crypto/evp/e_rc4_hmac_md5.c Wed Apr 18 17:51:33
2012
+++ openssl-1.0.1a-Modified/crypto/evp/e_rc4_hmac_md5.c Thu Apr 19 14:28:41
2012
@@ -289,8 +289,12 @@
const EVP_CIPHER *EVP_rc4_hmac_md5(void)
{
+#if defined(STITCHED_CALL)
extern unsigned int OPENSSL_ia32cap_P[];
/* RC4_CHAR flag v */
return(OPENSSL_ia32cap_P[0](120) ? NULL : r4_hmac_md5_cipher);
+#else
+ return(r4_hmac_md5_cipher);
+#endif
}
#endif
This fixed the compilation issue on Non-Intel/AMD cpus
Kind regards,
Daniel Flinkmann
http://www.Flinkmann.de/
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
--- openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c Wed Apr 18 17:51:33 2012
+++ /tmp/e_rc4_hmac_md5.c Thu Apr 19 14:28:41 2012
@@ -289,8 +289,12 @@
const EVP_CIPHER *EVP_rc4_hmac_md5(void)
{
+#if defined(STITCHED_CALL)
extern unsigned int OPENSSL_ia32cap_P[];
/* RC4_CHAR flag v */
return(OPENSSL_ia32cap_P[0](120) ? NULL : r4_hmac_md5_cipher);
+#else
+ return(r4_hmac_md5_cipher);
+#endif
}
#endif
[openssl.org #2796] fix for build problems with openssl 1.0.1a
Hi,
Attached is a patch that fixes OpenSSL 1.0.1a build problems on a non x86
platform (Sparc).
--
Leena Heino University of Tampere / Computer Centre
( liinu at uta.fi ) ( http://www.uta.fi/laitokset/tkk )
diff -Naur openssl-1.0.1a.orig/crypto/evp/e_rc4_hmac_md5.c
openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c
--- openssl-1.0.1a.orig/crypto/evp/e_rc4_hmac_md5.c 2012-04-18
20:51:33.0 +0300
+++ openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c 2012-04-19 17:27:26.974380650
+0300
@@ -289,8 +289,14 @@
const EVP_CIPHER *EVP_rc4_hmac_md5(void)
{
+#ifdefined(__i386) || defined(__i386__) || defined(_M_IX86) || \
+ defined(__INTEL__) || \
+ defined(__x86_64) || defined(__x86_64__) || defined(_M_AMD64) ||
defined(_M_X64)
extern unsigned int OPENSSL_ia32cap_P[];
/* RC4_CHAR flag v */
return(OPENSSL_ia32cap_P[0](120) ? NULL : r4_hmac_md5_cipher);
+#else
+ return(r4_hmac_md5_cipher);
+#endif
}
#endif
[openssl.org #2797] 1.0.1a build failure on OS X
I just tried building 1.0.1a on OS X (Lion, if it matters), and it failed with: Undefined symbols for architecture x86_64: _rc4_md5_enc, referenced from: _rc4_hmac_md5_cipher in libcrypto.a(e_rc4_hmac_md5.o) ld: symbol(s) not found for architecture x86_64 Looking through the CVS logs, I found: 2011-Nov-15 13:39 1.1.2.4 Check-in [21726] on branch OpenSSL_1_0_1-stable: e_rc4_hmac_md5.c: make it work on darwin64, which is configured with RC4_CHAR. By appro. (diff) and applying that patch appears to fix the problem, but it looks like it was reverted (possibly unintentionally?) in 1.1.2.4.2.1 and 1.1.2.5. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2798] compilation of openssl-1.0.1a fails on my solaris-10 box
just tried to compile openssl-1.0.1a on my solaris 10 box, using studio 12.1 compiler, but after ./Configure solaris-sparcv9-cc shared compilation of openssl-1.0.1a fails (openssl-1.0.1 went ok): linking of openssl fails with the error: Undefined symbol OPENSSL_ia32cap_P first referenced in file ../libcrypto.so the undefined symbol comes from crypto/evp/e_rc4_hmac_md5.c, which now in 1.0.1a has at the end in EVP_rc4_hmac_md5(): extern unsigned int OPENSSL_ia32cap_P[]; return(OPENSSL_ia32cap_P[0](120) ? NULL : r4_hmac_md5_cipher) after looking at other files in the crypto dir, i guess these lines should somehow be #ifdef'ed... kind regards -- Friedrich Haubensak h...@fli-leibniz.de | Science is true! Leibniz Institute for Age Research| Don't be mislead by facts. - Fritz Lipmann Institute -+- Beutenbergstrasse 11, D-07745 Jena | Tel. +49-3641-65-6202 | Fax -6210 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: ENGINE reference leak using FIPS-capable OpenSSL
Hi Steve, thank you very much, that fixed it!
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Dr. Stephen Henson
Sent: Thursday, April 19, 2012 8:10 PM
To: openssl-dev@openssl.org
Subject: Re: ENGINE reference leak using FIPS-capable OpenSSL
On Fri, Apr 20, 2012, Roumen Petrov wrote:
Dr. Stephen Henson wrote:
On Wed, Apr 18, 2012, Erik Tkal wrote:
Any takers? Should I be able to build a FIPS-capable OpenSSL and have some
of the implementation be provided via an ENGINE (e.g. let's say I have a
hardware module to perform AES) but some by the OpenSSL FIPS canister? Or
is it truly all or nothing?
Yes the FIPS capable OpenSSL should behave in a manner similar to
non-FIPS capable OpenSSL when not in FIPS mode, though it currently
use the algorithm implementations in the FIPS module even when not in FIPS
mode.
I'll look into it.
Openssl test start to fail after only call FIPS_cipherinit in FIPS
mode - 1.0.{1|2}_stable fips build:
aes-128-cbc
Error setting cipher AES-128-CBC
Error setting cipher AES-128-CBC
cmp: EOF on ./p.aes-128-cbc.clear
Ooops! This should fix it:
http://cvs.openssl.org/chngview?cn=22456
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
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Static analysis?
On Tue, 17 Apr 2012, Lubomír Sedlář wrote: I would like to ask if any static analysis tool was ever used to detect possible problems in OpenSSL source code. Is some tool used regularly? I tried running Clang Static Analyzer [1] on the source of OpenSSL. Julia Lawall a écrit : A few years ago, we did some experiments on finding problems in error handling in OpenSSL using Coccinelle: Finding Error Handling Bugs in OpenSSL using Coccinelle http://coccinelle.lip6.fr/papers/edcc10.pdf It's a bit surprising if none of those tools could identify the badness of the code involved in the just published memory corruption vulnerability. I fail to see anything subtle in that vulnerability. Now, the trouble might be in the eye of the reviewer who'd assume way too easily that the downcasting of a long is OK. I think it would be really interesting to understand *why* this wasn't seen earlier, and check all the rest of the code for potentially similar problem. Or similar case of assuming that doing this is not very clean but won't hurt us instead of cleaning the code to do things properly. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Static analysis?
On Fri, 20 Apr 2012, Jean-Marc Desperrier wrote: On Tue, 17 Apr 2012, Lubomír Sedlář wrote: I would like to ask if any static analysis tool was ever used to detect possible problems in OpenSSL source code. Is some tool used regularly? I tried running Clang Static Analyzer [1] on the source of OpenSSL. Julia Lawall a écrit : A few years ago, we did some experiments on finding problems in error handling in OpenSSL using Coccinelle: Finding Error Handling Bugs in OpenSSL using Coccinelle http://coccinelle.lip6.fr/papers/edcc10.pdf It's a bit surprising if none of those tools could identify the badness of the code involved in the just published memory corruption vulnerability. I fail to see anything subtle in that vulnerability. Now, the trouble might be in the eye of the reviewer who'd assume way too easily that the downcasting of a long is OK. I think it would be really interesting to understand *why* this wasn't seen earlier, and check all the rest of the code for potentially similar problem. Or similar case of assuming that doing this is not very clean but won't hurt us instead of cleaning the code to do things properly. Coccinelle is not a static analysis tool, but a scripting language for letting you search for whatever pattern you are interested in. I don't remember the pattern in question, but it didn't find the problem because I wasn't looking for it. On the other hand, a tool like clang static analyzer is promising to find all of the problems in one's code. So it would be more reasonable to expect it to find it. I didn't make enough note of the vulnerability that is referred to. Could you send me a link? Perhaps it is possible with Coccinelle to find other similar cases. julia
Re: Static analysis?
On Tue, Apr 17, 2012 at 9:46 PM, Lubomír Sedlář lubomir.sed...@gmail.comwrote: Hello, I would like to ask if any static analysis tool was ever used to detect possible problems in OpenSSL source code. Is some tool used regularly? I tried running Clang Static Analyzer [1] on the source of OpenSSL. It found 222 possible bugs. You can see the full list here [2]. At least 65 of them are false positives. Most of the ones that seem valid to me are classified as Dead Code. However, even some dead assignments look like real problems. Some examples follow: http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-JxXj0g.html#EndPath The variable 'al' is never read. The goto should probably jump to 'f_err' in order not to lose the alert. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-6OKYC8.html#EndPath The assignment to 'ret' is either useless or goto should jump to 'err'. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-117dnV.html#EndPath http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-rT4fgM.html#EndPath Duplicit assignment to 'ret' and 'saved_state.epoch', respectively. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-xy1iZT.html#EndPath 'qbits' gets assigned the same value in following condition again. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-IG0Qez.html#EndPath The 'E', 'e', 'G', 'g' cases don't seem to do anything. Is there some missing functionality? Missing but not missed, I suspect :-) http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-euj1zH.html#EndPath Default port is assigned twice, on line 234. Would you be interested in some patches? How and where should I submit them? Interesting bugs. I would be happy to work with you to get these fixed. I like static analysis :-) Regards, Lubomír Sedlář [1]: http://clang-analyzer.llvm.org/ [2]: http://www.fi.muni.cz/~xsedlar3/openssl-analysis/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Static analysis?
On Fri, Apr 20, 2012 at 4:53 PM, Jean-Marc Desperrier jmd...@free.frwrote: On Tue, 17 Apr 2012, Lubomír Sedlář wrote: I would like to ask if any static analysis tool was ever used to detect possible problems in OpenSSL source code. Is some tool used regularly? I tried running Clang Static Analyzer [1] on the source of OpenSSL. Julia Lawall a écrit : A few years ago, we did some experiments on finding problems in error handling in OpenSSL using Coccinelle: Finding Error Handling Bugs in OpenSSL using Coccinelle http://coccinelle.lip6.fr/**papers/edcc10.pdfhttp://coccinelle.lip6.fr/papers/edcc10.pdf It's a bit surprising if none of those tools could identify the badness of the code involved in the just published memory corruption vulnerability. Every now and then I look at trying to eliminate the possibility of this kind of bug. Its really hard. I'd be interested if Clang could be persuaded to spot the bug ... even more interested if it could find conversion bugs generically. I fail to see anything subtle in that vulnerability. Now, the trouble might be in the eye of the reviewer who'd assume way too easily that the downcasting of a long is OK. I think it would be really interesting to understand *why* this wasn't seen earlier, and check all the rest of the code for potentially similar problem. Or similar case of assuming that doing this is not very clean but won't hurt us instead of cleaning the code to do things properly. The core problem is that the language doesn't do things properly :-) But seriously, this is an important problem that crops up all the time, but is hard to deal with. I've long suspected that a combination of static analysis, good idioms and annotation could go a long way towards making things better, but haven't really had time/energy to do more than speculate__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Static analysis?
On Tue, Apr 17, 2012, Lubomr Sedl?? wrote: Some examples follow: http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-JxXj0g.html#EndPath The variable 'al' is never read. The goto should probably jump to 'f_err' in order not to lose the alert. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-6OKYC8.html#EndPath The assignment to 'ret' is either useless or goto should jump to 'err'. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-117dnV.html#EndPath http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-rT4fgM.html#EndPath Duplicit assignment to 'ret' and 'saved_state.epoch', respectively. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-xy1iZT.html#EndPath 'qbits' gets assigned the same value in following condition again. http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-IG0Qez.html#EndPath The 'E', 'e', 'G', 'g' cases don't seem to do anything. Is there some missing functionality? http://www.fi.muni.cz/~xsedlar3/openssl-analysis/report-euj1zH.html#EndPath Default port is assigned twice, on line 234. Would you be interested in some patches? How and where should I submit them? Bug reports should go to the request tracker, that way someone can claim them, their history can be tracked and they're less likely to get overlooked. Just email to r...@openssl.org to do that. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
