Re: [openssl-project] Fwd: New Defects reported by Coverity Scan for openssl/openssl
Matt, I wasn't aware that I can register for coverity reports (which I just did). If no one else has done it yet, I can look into the three drbg issues mentioned in your mail. Matthias BTW: isn't beta release 3 (pre5) due today? There was no announcement of a code freeze yet. Am 16.04.2018 um 19:47 schrieb Matt Caswell: > Can anyone enlighten me as to why I can't find half of these defects in > the coverity dashboard? None of the reported defects in the test cases > seem to exist any more (and I'm fairly sure we didn't fix them). > Actually I didn't think we scanned the tests at all, so I'm a little > confused. > > Matt > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Constant time by default
I was actually going to file a ticket somewhere and never got around to it... In BoringSSL, we've instead gone the route of removing BN_FLG_CONSTTIME altogether. Rather call sites which need a particular function call that function directly. I think this is much less error-prone (as the various problems here show). Of course, OpenSSL can't fully get rid of BN_FLG_CONSTTIME until 1.2.0, but it could arrange for the library to no longer rely on it internally. In a crypto library, "modular exponentiation" is not a complete API contract. Rather, you need contracts like "modular exponentiation with secret fully-reduced base and public exponent" or "modular exponentiation with secret fully-reduced base and secret exponent publicly bounded by such-and-such". Cast in that light, I think it becomes much clearer that they should be separate functions. You could even imagine embedding secrecy into the type (either for safety or to take advantage of some future compiler annotations), in which case separate functions is necessary. This also aligns with the guidelines here: https://github.com/HACS-workshop/spectre-mitigations/blob/master/crypto_guidelines.md#2-avoid-indirect-branches-in-constant-time-code On Mon, Apr 16, 2018 at 1:09 PM Salz, Rich wrote: > I think this is a great idea, but that it is way too late for this > release. We really should be concentrating on testing and fixes, and open > PR's and other release criteria. Ideally the release goes out in a month > (IETF RFC editor willing) > > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Fwd: New Defects reported by Coverity Scan for openssl/openssl
Can anyone enlighten me as to why I can't find half of these defects in
the coverity dashboard? None of the reported defects in the test cases
seem to exist any more (and I'm fairly sure we didn't fix them).
Actually I didn't think we scanned the tests at all, so I'm a little
confused.
Matt
Forwarded Message
Subject: New Defects reported by Coverity Scan for openssl/openssl
Date: Sun, 15 Apr 2018 07:51:06 + (UTC)
From: scan-ad...@coverity.com
To: m...@openssl.org
Hi,
Please find the latest report on new defect(s) introduced to
openssl/openssl found with Coverity Scan.
5 new defect(s) introduced to openssl/openssl found with Coverity Scan.
4 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 5 of 5 defect(s)
** CID 1434551: Code maintainability issues (SIZEOF_MISMATCH)
/test/sslapitest.c: 3831 in create_new_vfile()
*** CID 1434551: Code maintainability issues (SIZEOF_MISMATCH)
/test/sslapitest.c: 3831 in create_new_vfile()
3825 return ret;
3826 }
3827 3828 static int create_new_vfile(char *userid, char
*password, const char *filename)
3829 {
3830 char *gNid = NULL;
>>> CID 1434551: Code maintainability issues (SIZEOF_MISMATCH)
>>> Passing argument "56UL /* sizeof (row) * (6 + 1) */" to function
>>> "CRYPTO_zalloc" and then casting the return value to "OPENSSL_STRING *" is
>>> suspicious. In this particular case "sizeof (OPENSSL_STRING *)" happens to
>>> be equal to "sizeof (OPENSSL_STRING)", but this is not a portable
>>> assumption.
3831 OPENSSL_STRING *row = OPENSSL_zalloc(sizeof(row) *
(DB_NUMBER + 1));
3832 TXT_DB *db = NULL;
3833 int ret = 0;
3834 BIO *out = NULL, *dummy = BIO_new_mem_buf("", 0);
3835 size_t i;
3836
** CID 1434550:(RESOURCE_LEAK)
/crypto/srp/srp_vfy.c: 73 in t_fromb64()
/crypto/srp/srp_vfy.c: 97 in t_fromb64()
*** CID 1434550:(RESOURCE_LEAK)
/crypto/srp/srp_vfy.c: 73 in t_fromb64()
67 * 2 bytes unencoded = 3 bytes encoded
68 * 3 bytes unencoded = 4 bytes encoded
69 * 4 bytes unencoded = 6 bytes encoded
70 * etc
71 */
72 if (padsize == 3)
>>> CID 1434550:(RESOURCE_LEAK)
>>> Variable "ctx" going out of scope leaks the storage it points to.
73 return -1;
74 75 /* Valid padsize values are now 0, 1 or 2 */
76 77 EVP_DecodeInit(ctx);
78 evp_encode_ctx_set_flags(ctx, EVP_ENCODE_CTX_USE_SRP_ALPHABET);
/crypto/srp/srp_vfy.c: 97 in t_fromb64()
91 EVP_DecodeFinal(ctx, a + outl, &outl2);
92 outl += outl2;
93 94 /* Strip off the leading padding */
95 if (padsize != 0) {
96 if ((int)padsize >= outl)
>>> CID 1434550:(RESOURCE_LEAK)
>>> Variable "ctx" going out of scope leaks the storage it points to.
97 return -1;
98 /*
99 * If we added 1 byte of padding prior to encoding then
we have 2 bytes
100 * of "real" data which gets spread across 4 encoded
bytes like this:
101 * (6 bits pad)(2 bits pad | 4 bits data)(6 bits
data)(6 bits data)
102 * So 1 byte of pre-encoding padding results in 1 full
byte of encoded
** CID 1434549: Error handling issues (CHECKED_RETURN)
/test/evp_test.c: 1553 in encode_test_run()
*** CID 1434549: Error handling issues (CHECKED_RETURN)
/test/evp_test.c: 1553 in encode_test_run()
1547 if (!TEST_ptr(encode_ctx = EVP_ENCODE_CTX_new())
1548 || !TEST_ptr(encode_out =
1549
OPENSSL_malloc(EVP_ENCODE_LENGTH(expected->input_len
1550 goto err;
1551 1552 EVP_EncodeInit(encode_ctx);
>>> CID 1434549: Error handling issues (CHECKED_RETURN)
>>> Calling "EVP_EncodeUpdate" without checking return value (as is done
>>> elsewhere 4 out of 5 times).
1553 EVP_EncodeUpdate(encode_ctx, encode_out, &chunk_len,
1554 expected->input, expected->input_len);
1555 output_len = chunk_len;
1556 1557 EVP_EncodeFinal(encode_ctx, encode_out +
chunk_len, &chunk_len);
1558 output_len += chunk_len;
** CID 1434548: Error handling issues (CHECKED_RETURN)
/test/drbgtest.c: 800 in run_multi_thread_test()
*** CID 1434548: Error handling issues (CHECKED_RETURN)
/test/drbgtest.c: 800 in run_multi_thread_test()
794 private = RAND_DRBG_get0_pri
Re: [openssl-project] Constant time by default
I think this is a great idea, but that it is way too late for this release. We really should be concentrating on testing and fixes, and open PR's and other release criteria. Ideally the release goes out in a month (IETF RFC editor willing) ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Constant time by default
I'd like to draw everyone's attention to PR #5969 Given CVE-2018-0737, and the fact that this is far from the first time this has happened I think we should change the default so that we always use the constant time implementation unless specifically flagged otherwise. E.g see these issues: 54f007a (CVE-2018-0737) 8db7946 e913d11 6364475 6364475 3de81a5 47ae05b 033dc8f 3999446 (CVE-2016-2178) As I say in the PR (marked as WIP) I am seeking feedback as to whether this is something we should pursue now (i.e. for 1.1.1) or later (post 1.1.1) or not at all. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [16 Apr 2018] Cache timing vulnerability in RSA Key Generation (CVE-2018-0737) Severity: Low The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a cache timing side channel attack. An attacker with sufficient access to mount cache timing attacks during the RSA key generation process could recover the private key. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i and OpenSSL 1.0.2p when they become available. The fix is also available in commit 6939eab03 (for 1.1.0) and commit 349a41da1 (for 1.0.2) in the OpenSSL git repository. This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia. The fix was developed by Billy Brumley. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20180416.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJa1MKgAAoJENnE0m0OYESRKOoIAKmRnj0YtE1y89WnRiCjMk8l Z7XAsPk6nkEa8dlrEvEsUhS90CFSf9OcYliAlfjD/+RVZXXeK4AHn8/g7HxAdDcK 62biQiHbxICBqnrE6DCe6GrMXEy3MWuefSWnoTyd/x8W1grjdhkrlmIqe68DP0iv WItmStRVOpx4mQDcrYqw6ZKhhu1Lv007khyAornJP+S6NSlK6brdNQyRNmp3+HO4 irqPi6xQWGcaAtrdpWi8mDnomld75j5m+G98N/gCqaCAIn7Zau+kAAW1+1dO5S4L tsQ0CifVnRfUTz0cCL51L8G3a3RWYs34AXRZvSRi3q88AiZ1L6FCF2cHZJu1KuE= =+TYO -END PGP SIGNATURE- ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
> On Apr 16, 2018, at 6:00 AM, Matt Caswell wrote: > > That's not entirely true. This works: > > $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0 > $ openssl s_client -no_tls1_3 -cipher ALL@SECLEVEL=0 > > This doesn't: > > $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0 > $ openssl s_client -cipher ALL@SECLEVEL=0 > > 139667082474432:error:14201076:SSL routines:tls_choose_sigalg:no > suitable signature algorithm:ssl/t1_lib.c:2484: > > We do not allow DSA certs in TLSv1.3. It is largely time we did not allow them in TLS 1.2 either, nobody uses them, but perhaps "nobody" == USG? -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
On 15/04/18 17:18, Viktor Dukhovni wrote: > > >> On Apr 15, 2018, at 2:24 AM, Bernd Edlinger >> wrote: >> >> One possible example of application failure that I am aware of is #5743: >> A certificate that is incompatible with TLS1.3 but works with TLS1.2. >> Admittedly that I did come up with that scenario only because I saw >> a possible issue per code inspection. > > [ Repeating in part my response to Richar's mesage also in this thread ] > > This is a bug that needs to be fixed, the point format for TLS does not > have any provenance over X.509. There's no such thing as a certificate > not compatible with TLS 1.3 (that is compatible with TLS 1.2). > That's not entirely true. This works: $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0 $ openssl s_client -no_tls1_3 -cipher ALL@SECLEVEL=0 This doesn't: $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0 $ openssl s_client -cipher ALL@SECLEVEL=0 139667082474432:error:14201076:SSL routines:tls_choose_sigalg:no suitable signature algorithm:ssl/t1_lib.c:2484: We do not allow DSA certs in TLSv1.3. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
