RE: CVE-2022-37454 SHA-3 buffer overflow
This is probably more difficult to exploit than I thought in my first read through. Workarounds The problem can be avoided by limiting the size of the partial input data (or partial output digest) below 2^32 - 200 bytes. Multiple calls to the queue system can be chained at a higher level to retain the original functionality. Alternatively, one can process the entire input (or produce the entire output) at once, avoiding the queuing functions altogether. From: Job Cacka Sent: Friday, October 21, 2022 11:33 AM To: 'openssl-users@openssl.org' Subject: CVE-2022-37454 SHA-3 buffer overflow I was reading that SHA-3 has a buffer overflow in the C implementation that is used by PHP and Python. https://nvd.nist.gov/vuln/detail/CVE-2022-37454 https://mouha.be/sha-3-buffer-overflow/ How does OpenSSL implement SHA-3 in the following algorithms? Is SHA3 only used in SHA3-224, SHA3-256, SHA3-384, and SHA3-512? root:/ openssl list -digest-algorithms RSA-MD4 => MD4 RSA-MD5 => MD5 RSA-MDC2 => MDC2 RSA-RIPEMD160 => RIPEMD160 RSA-SHA1 => SHA1 RSA-SHA1-2 => RSA-SHA1 RSA-SHA224 => SHA224 RSA-SHA256 => SHA256 RSA-SHA3-224 => SHA3-224 RSA-SHA3-256 => SHA3-256 RSA-SHA3-384 => SHA3-384 RSA-SHA3-512 => SHA3-512 RSA-SHA384 => SHA384 RSA-SHA512 => SHA512 RSA-SHA512/224 => SHA512-224 RSA-SHA512/256 => SHA512-256 RSA-SM3 => SM3 BLAKE2b512 BLAKE2s256 id-rsassa-pkcs1-v1_5-with-sha3-224 => SHA3-224 id-rsassa-pkcs1-v1_5-with-sha3-256 => SHA3-256 id-rsassa-pkcs1-v1_5-with-sha3-384 => SHA3-384 id-rsassa-pkcs1-v1_5-with-sha3-512 => SHA3-512 MD4 md4WithRSAEncryption => MD4 MD5 MD5-SHA1 md5WithRSAEncryption => MD5 MDC2 mdc2WithRSA => MDC2 ripemd => RIPEMD160 RIPEMD160 ripemd160WithRSA => RIPEMD160 rmd160 => RIPEMD160 SHA1 sha1WithRSAEncryption => SHA1 SHA224 sha224WithRSAEncryption => SHA224 SHA256 sha256WithRSAEncryption => SHA256 SHA3-224 SHA3-256 SHA3-384 SHA3-512 SHA384 sha384WithRSAEncryption => SHA384 SHA512 SHA512-224 sha512-224WithRSAEncryption => SHA512-224 SHA512-256 sha512-256WithRSAEncryption => SHA512-256 sha512WithRSAEncryption => SHA512 SHAKE128 SHAKE256 SM3 sm3WithRSAEncryption => SM3 ssl3-md5 => MD5 ssl3-sha1 => SHA1 whirlpool Thanks, Job
CVE-2022-37454 SHA-3 buffer overflow
I was reading that SHA-3 has a buffer overflow in the C implementation that is used by PHP and Python. https://nvd.nist.gov/vuln/detail/CVE-2022-37454 https://mouha.be/sha-3-buffer-overflow/ How does OpenSSL implement SHA-3 in the following algorithms? Is SHA3 only used in SHA3-224, SHA3-256, SHA3-384, and SHA3-512? root:/ openssl list -digest-algorithms RSA-MD4 => MD4 RSA-MD5 => MD5 RSA-MDC2 => MDC2 RSA-RIPEMD160 => RIPEMD160 RSA-SHA1 => SHA1 RSA-SHA1-2 => RSA-SHA1 RSA-SHA224 => SHA224 RSA-SHA256 => SHA256 RSA-SHA3-224 => SHA3-224 RSA-SHA3-256 => SHA3-256 RSA-SHA3-384 => SHA3-384 RSA-SHA3-512 => SHA3-512 RSA-SHA384 => SHA384 RSA-SHA512 => SHA512 RSA-SHA512/224 => SHA512-224 RSA-SHA512/256 => SHA512-256 RSA-SM3 => SM3 BLAKE2b512 BLAKE2s256 id-rsassa-pkcs1-v1_5-with-sha3-224 => SHA3-224 id-rsassa-pkcs1-v1_5-with-sha3-256 => SHA3-256 id-rsassa-pkcs1-v1_5-with-sha3-384 => SHA3-384 id-rsassa-pkcs1-v1_5-with-sha3-512 => SHA3-512 MD4 md4WithRSAEncryption => MD4 MD5 MD5-SHA1 md5WithRSAEncryption => MD5 MDC2 mdc2WithRSA => MDC2 ripemd => RIPEMD160 RIPEMD160 ripemd160WithRSA => RIPEMD160 rmd160 => RIPEMD160 SHA1 sha1WithRSAEncryption => SHA1 SHA224 sha224WithRSAEncryption => SHA224 SHA256 sha256WithRSAEncryption => SHA256 SHA3-224 SHA3-256 SHA3-384 SHA3-512 SHA384 sha384WithRSAEncryption => SHA384 SHA512 SHA512-224 sha512-224WithRSAEncryption => SHA512-224 SHA512-256 sha512-256WithRSAEncryption => SHA512-256 sha512WithRSAEncryption => SHA512 SHAKE128 SHAKE256 SM3 sm3WithRSAEncryption => SM3 ssl3-md5 => MD5 ssl3-sha1 => SHA1 whirlpool Thanks, Job
how to use session ticketing at client/server level
Dear Team, Please provide me the list of API's(or any sample programs) to be used at server/client side to process session ticketing. Currently we are in the process of migrating from session ID usage to session ticketing. Regards, Sethu V
RE: OpenSSL 1.1.1 Windows dependencies
> From: David Harris > Sent: Friday, 21 October, 2022 01:42 > > On 20 Oct 2022 at 20:04, Michael Wojcik wrote: > > > I think more plausible causes of this failure are things like OpenSSL > > configuration and interference from other software such as an endpoint > > firewall. Getting SYSCALL from SSL_accept *really* looks like > > network-stack-level interference, from a firewall or similar > > mechanism. > > That was my initial thought too, except that if it were firewall-related, the > initial port 587 connection would be blocked, and it isn't - the failure > doesn't > happen until after STARTTLS has been issued. Not necessarily. That's true for a first-generation port-blocking firewall, but not for a packet-inspecting one. There are organizations which use packet-inspecting firewalls to block STARTTLS because they enforce their own TLS termination, in order to inspect all incoming traffic for malicious content and outgoing traffic for exfiltration. > Furthermore, the OpenSSL > configuration is identical between the systems/combinations of OpenSSL that > work and those that don't. Do you know that for certain? There's no openssl.cnf from some other source being picked up on the non-working system? -- Michael Wojcik
Re: Fwd: Proper API usage with DTLS over custom net transport
On 20/10/2022 20:33, Павел Балашов wrote: So now the questions: (1) If we receive some dtls data at the line above with '' what should we do in terms of OpenSSL API calls ? I assume this dtls data could be a client's retransmission due to server's last flight was lost or this could be client receiving server's last flight duplicated (theoretically could happen as long as lower layer protocol is UDP) or this could be DTLS-encrypted real-app data or this could be DTLS-renegotiation, this also could be a DTLS shutdown alert and anything else DTSL-related. What is the supposed way of inferring and reacting to those different events with API ? Call SSL_read(). If it is app data it will be returned. If it is something else it will be handled. (2) Is the whole usage of OpenSSL even right for this scenario - maybe the structure and sequence of API calls should be rearranged somehow ? Seems approximately right except that BIO_s_mem() is not a good choice for DTLS. It does not respect packet semantics, so if you receive 2 packets and they both get pushed into the BIO_s_mem(), the reader will just get both packets together. Unfortunately there is no equivalent of BIO_s_mem() that respects packets in 3.0/1.1.1. There is in the master branch (what will become 3.2), where we have BIO_s_dgram_mem(). Also note that the only BIO that provides the various ctrls for querying the underlying MTU is BIO_s_dgram(). If you use something else that doesn't have those ctrls it will fallback to some worse case MTU. It might be possible to write a custom BIO equivalent of BIO_s_mem() that does the right thing with respect to packets and has the right MTU ctrls. On the server side you might want to consider whether DTLSv1_listen() should be used in your scenario, and whether you should set the cookie callback. You should check the return value from SSL_do_handshake() and use SSL_get_error() to interpret any failure return codes. (3) There is an option to pass custom info_callback with SSL_CTX_set_info_callback(). Would there be a proper usage of this kind of callback in this scenario ? Not sure what you're asking here. There is a man page for this function here: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_info_callback.html Matt Any other input, links to any kind of relevant supplemental material is really appreciated. Thanks a lot for reading, very special thanks to authors and maintainers for all the hard work on this project. --- Regards, Pavel.
Re: openssl-users Digest, Vol 95, Issue 27
Hi, - Why are you trying to build OpenSSL? My objective is to sign an 'image.bin' with RSA2048 and verify the signature. I managed to build OpenSSL on linux and test the signature and verification with RSA2048 (private & public keys). Now, I would like to port it to vxWorks 7. - Why did you clone the GitHub repository rather than downloading one of the released source tarballs? Did you read the instructions on www.openssl.org on how to download OpenSSL source releases? git clone https://github.com/openssl/openssl.git A: If there an l'ibOpenssl.a' static library for vxWorks, then there would be no reason to build the OpenSSL. Is there? A: If there was on option to use Only the verify signature module, then I would just compile this module and not the entire OpenSSL. Is there an option? - What platform do you want to build OpenSSL for? A: vxWorks-7, the toolchain is windows exe files (gcc,ar,ld), thus the only option I had in mind to build the OpenSSL is cygwin. - What toolchain do you want to use, and if that's not the default toolchain for that platform, why aren't you using the default? A: I have vxWorks toolchain, on windows platform. (It definitely be easier if I had the vxWorks toochain on Linux, but I don't) - Have you read the text files in the top-level directory of the OpenSSL source distribution? Please direct me to the relevant README on "how to build OpenSSL on vxWorks" (or similar platform, in which all is needed is to inject the relevant toochain i.e. perl Configure VxWorks) There may well be an easier way to accomplish whatever your goal is. OpenSSL may not even be a particularly good solution for you. You haven't given us enough information to go on. A: For the long run, I consider to use OpenSSL features on Linux and VxWorks בתאריך יום ה׳, 20 באוק׳ 2022 ב-8:27 מאת <openssl-users-requ...@openssl.org >: > Send openssl-users mailing list submissions to > openssl-users@openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-requ...@openssl.org > > You can reach the person managing the list at > openssl-users-ow...@openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > >1. RE: openssl-users Digest, Vol 95, Issue 24 (Michael Wojcik) >2. OpenSSL 1.1.1 Windows dependencies (David Harris) >3. libproviders.so file not found (Gahlot, Ashish Kumar) > > > -- > > Message: 1 > Date: Wed, 19 Oct 2022 20:30:07 + > From: Michael Wojcik > To: "openssl-users@openssl.org" > Subject: RE: openssl-users Digest, Vol 95, Issue 24 > Message-ID: > < > dm6pr18mb2700c12c0c4c8a7778312669f9...@dm6pr18mb2700.namprd18.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > > From: openssl-users On Behalf Of > ??? > > Sent: Tuesday, 18 October, 2022 11:58 > > > I have downloaded perl strawberry, but I have no clue how to get rid of > the > > built-in perl that comes in cygwin, and point cygwin to use the > strawberry perl. > > You don't have to remove the Cygwin version of perl, just change your > PATH. This is basic both to the various shells available under Cygwin and > to the Windows command line, so I'm getting the impression that you're not > very familiar with your operating environment. That's not an ideal place to > start from when trying to build, much less use, OpenSSL. > > I can't be more detailed because at this point I frankly don't understand > what you're trying to do. I suggest you try asking the right question, in a > useful manner. (See https://catb.org/esr/faqs/smart-questions for advice > in how to ask the right question.) > > In particular: > > - Why are you trying to build OpenSSL? > - Why did you clone the GitHub repository rather than downloading one of > the released source tarballs? Did you read the instructions on > www.openssl.org on how to download OpenSSL source releases? > - What platform do you want to build OpenSSL for? > - What toolchain do you want to use, and if that's not the default > toolchain for that platform, why aren't you using the default? > - Have you read the text files in the top-level directory of the OpenSSL > source distribution? > > There may well be an easier way to accomplish whatever your goal is. > OpenSSL may not even be a particularly good solution for you. You haven't > given us enough information to go on. > > -- > Michael Wojcik > > -- > > Message: 2 > Date: Thu, 20 Oct 2022 13:54:19 +1300 > From: "David Harris" > To: Openssl-users@openssl.org > Subject: OpenSSL 1.1.1 Windows dependencies > Message-ID: <63509c3b.16160.7ff05...@openssl.pmail.gen.nz> > Content-Type: text/plain; charset=US-ASCII > > Up front, I'd like to
Re: OpenSSL 1.1.1 Windows dependencies
On 21 Oct 2022 at 7:27, Richard Levitte wrote: > Let me ask you this: on what Windows version was your application > built? Common wisdom would be to build on the oldest version... My application is a very traditional Win32 application, and at the moment (and until circumstances *force* me to change) I build it in a Windows 7 SP2 VM. There's really no build-related reason why it shouldn't work on Server 2012, especially since the 1.1.1g build (which DOES work on the affected system) is built in exactly the same VM. It's a puzzle, for sure. Thanks for taking the time to look into this for me Richard. Cheers! -- David --
Re: OpenSSL 1.1.1 Windows dependencies
On 20 Oct 2022 at 20:04, Michael Wojcik wrote: > OpenSSL 1.1.1 uses Windows cryptographic routines in two areas I'm > aware of: rand_win.c and the CAPI engine. I don't offhand see a way > that a problem with the calls in rand_win.c would cause the particular > symptom you described. My guess is that you're not using the CAPI > engine, but you might check your OpenSSL configuration on the failing > system. For a variety of reasons to do with redistributables, I build OpenSSL as no-shared, and because of the compiler I prefer to use (an older build of Visual C), I have to compile with no-capi as well, so CAPI clearly isn't an issue in this case. But to be sure, I tried rebuilding OpenSSL with Visual C 2022 (using Visual C 2019 as the compile unit) and according to the customer, the result was the same. > I think more plausible causes of this failure are things like OpenSSL > configuration and interference from other software such as an endpoint > firewall. Getting SYSCALL from SSL_accept *really* looks like > network-stack-level interference, from a firewall or similar > mechanism. That was my initial thought too, except that if it were firewall-related, the initial port 587 connection would be blocked, and it isn't - the failure doesn't happen until after STARTTLS has been issued. Furthermore, the OpenSSL configuration is identical between the systems/combinations of OpenSSL that work and those that don't. > Personally, if I ran into this, I'd just build OpenSSL for debug and > debug into it. But I know that's not everyone's cup of tea. Unfortunately, I don't have that level of access to the customer's systems. I was really just wondering if the combination of factors rang any bells with anyone before I started digging much deeper; it's altogether possible that I might just have to write this one off to experience and tell the user to use a 1.1.1g build of OpenSSL (which I build exactly the same way, and which works correctly in the same setup). Thanks for the help - appreciated. Cheers! -- David --
