Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext
The demo program actually allocates a whole extra block for the output, so there should always be extra space available. Yes, which is why I said as for alleged buffer overruns in *your* program. I mean you said I discovered this [suspected buffer overrun] in my real code and as you didn't present it, I found it appropriate to remind that strlen-based allocations are prone to overruns, and if it would be case, it would be something for you to address. My real program uses manually padded, known-size binary packets Excellent! If you would have clarified this from beginning, we wouldn't have this digression :-) I've just re-tested, pasting the code in to both C and C++ netbeans projects (since that's what my main project uses) and fixing the C++ convert-from-const errors as well as adding aes.h. Both give the same valgrind issues for me. I'm using gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) and valgrind-3.10.0.SVN if that might make a difference. Experimentation shows that the magic length is 96 bytes - strlen()=94 works fine on my machine, strlen()=95 produces the valgrind complaints. That means input length of 96, since the code uses strlen()+1. What's magic about a 96 byte input size? (other than being 6 AES128 blocks) Since I have a new Fedora 20 virtual machine handy I have also run on that with the same result:Using OpenSSL version OpenSSL 1.0.1e-fips 11 Feb 2013 ==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ... ==2793== Conditional jump or move depends on uninitialised value(s) ==2793==at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2793==by 0x400FA1: main (in /home/digidev/test/a.out) ==2793== Uninitialised value was created by a stack allocation ==2793==at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) ... OK. Keyword here is that it's 1.0.1 (I was testing against development branch, master and 1.0.2). 1.0.1 is actually known to upset valgrind (see RT#2862), but it looks more like valgrind bug. Well, it's somewhat in between: one can argue that valgrind has formal right to complain, but at the same time aesni_cbc_encrypt doesn't actually violate ABI constrains. Latter means that result is always correct and code in question doesn't actually overrun any buffers nor uses uninitialized values. The reason for why I failed to initially reproduce it in master and 1.0.2 is that module in question was updated after 1.0.1 release to not rely on red zone (the thing valgrind is complaining about). But this was done for reason other than appeasing valgrind. In case you wonder why problem pops up with longer lengths. This is because with shorter lengths it's possible to keep everything in processor registers. And with longer length it has to spill one value to stack. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. The API we offer in Qt isn't tied to openssl so we can't do that. We also support a Windows RT backend and a SecureTransport backend is under development too. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) That's partly due to the API naming conventions for enums. :-) Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Kurt Roeckx via RT r...@openssl.org wrote:
|On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
| set ssl-protocol=ALL,-SSLv2
|
| This results in the obvious problem that when they (get)
| upgrade(d) their OpenSSL library they will see a completely
| intransparent error message that no normal user will understand:
|
|It was actually my intention to keep supporting that, but I seem
|to have removed that line. I think the following patch should fix
|that:
|--- a/ssl/ssl_conf.c
|+++ b/ssl/ssl_conf.c
|@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
|const char *value)
|static const ssl_flag_tbl ssl_protocol_list[] =
|{
|SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
|+ SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
|SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
|SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
|SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),
Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know.
--steffen
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: | Richard Moore richmoor...@gmail.com wrote: ||On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org | wrote: || and finally i propose three new values for the Protocol slot of || SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. || ||In Qt we've added an enum value for TLS versions that is SecureProtocols | so ||that we could remove versions as required without requiring apps to be ||updated. It's an open question which is more likely to get updated - Qt | or ||the apps of course. For Qt 5.4 which is due out this week we've removed ||SSL3 from this enum so apps will silently get updated to drop support for ||it. | | I see. And i think this is the most impressive or, lesser | enthusiastic, important feature of the slow _CONF_ interface: that | users can use strings and that those are directly swallowed by the | OpenSSL library, so that neither recompilation nor understanding | is necessary on the program side in order to upgrade to a new | level of security. | |The API we offer in Qt isn't tied to openssl so we can't do that. We also |support a Windows RT backend and a SecureTransport backend is under |development too. Well, of course. Implementing a simple fixed-string wrapper isn't hard to do shall there be desire, however, i've done the mine in about two hours in 43 lines plus the mapping array and some testing (a n_strsep() already existed). And it can be hoped that other libraries follow with their interfaces, functions like SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption SocketProtectionLevel constants are really inflexible and hard to use. And result in ugly mail paragraph formatting. And do i think most of the time not really describe what is desired (a secure transport, or SecureProtocols in your QT world). But not that i wouldn't prefer compile-checks in favour of intransparent strings. That makes me think that some prodding by you could possibly get the ball rolling. It needn't be _that_ flexible.. | (As a side note: SecureProtocols is such a Volvo wording... | Doesn't vulnerable energises a deeper feeling of insecurity? | I think Hitchcock would have used the naked and bare vulnerable.) | | |That's partly due to the API naming conventions for enums. :-) Yet that only describes the lesser part :) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] License compatibility: OpenSSL and Apache v2
Hello, Let's imagine someone develop extension module to OpenSSL, and release it under Apache v2 license. Do you see any possible issues with using this extension module as a part of OpenSSL? ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] License compatibility: OpenSSL and Apache v2
Let's imagine someone develop extension module to OpenSSL, and release it under Apache v2 license. Do you see any possible issues with using this extension module as a part of OpenSSL? Are you writing an extension that you are going to distribute, or is it something you want to contribute to OpenSSL? You cannot change the license on openssl files, and any work derived from them such as modifications to those source files, must have the same license. And if you want to to contribute it to the project, it is easiest for us if the license is the same. But if it is your own code, and you are distributing it, then you can do anything you want :) ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
