Koozali.org: home of the SME Server
Other Languages => Italiano => Topic started by: acamapixtli on May 09, 2020, 05:16:49 PM
-
Buon pomeriggio,
ho un serverino su cui gira, ormai da un bel po', Koozali 9.2, il quale mi "raccoglie" la posta da vari account esterni e la smista ai vari componenti della famiglia; da un paio giorni, ad ogni frazione di tempo in cui il server fa la "raccolta", ricevo un'errore da startmail del seguente tono:
"3077908204:error:1411B041:SSL routines:SSL3_GET_NEW_SESSION_TICKET:malloc failure:s3_clnt.c:2169:".
Ho preventivamente cercato nel forum e successivamente sull'intera rete, ma non sono stato capace di trovare una soluzione.
Qualcuno sa dirmi da cosa può dipendere ed, eventualmente, come ovviare ?
-
I found this indicating this is a bug in openssl: CVE-2015-1791 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1791).
According to that CVE, there is a race condition in openssl-1.0.1 "before 1.0.1n".
My up-to-date SME 9.2 server has 1.0.1e:
# rpm -qa openssl
openssl-1.0.1e-58.el6_10.x86_64
...when used for a multi-threaded client, allows remote attackers to cause a denial of service (double free and application crash) or possibly have unspecified other impact by providing a NewSessionTicket during an attempt to reuse a ticket that had been obtained earlier.
So... either you are under attack, or you are seeing an "unspecified other impact".
You could open a bug; I don't know if SME 9.2/Centos 6.9 can be easily upgraded to a later version of openssl.
-
Where do see the error? In your logs? Which log?
If the error is in startmail, then that is fetchmail I guess.
So I imagine it is an issue with mail collection with the upstream server?
You can enable verbosity on fetchmail to have a look further. I think it is like this.
config setprop fetchmail Verbosity enabled
signal-event email-update
Can you also paste the output of /etc/fetchmail with sensitive information removed.
Note also:
https://wiki.contribs.org/SSL_Settings
https://wiki.contribs.org/Fetchmail_secure_connection_troubles
https://www.fetchmail.info/fetchmail-man.html (see -sslproto)
I wonder if it is defaulting to sslproto 'auto' and is trying SSL and the far end rejects it?
There is no current way to fix say TLS but it is possible to amend the template.
You can manually edit the /etc/fetchmail file and then test run it to see.
You could open a bug; I don't know if SME 9.2/Centos 6.9 can be easily upgraded to a later version of openssl.
No I don't believe it can be. But I am note sure that is the cause of the issue.
-
No I don't believe it can be. But I am note sure that is the cause of the issue.
Indeed, the changelog for openssl on SME implies that the bug I found has been addressed:
* Mon Jul 01 2019 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-58
- fix CVE-2019-1559 - 0-byte record padding oracle
...
* Tue Jun 23 2015 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-42
- fix regression caused by mistake in fix for CVE-2015-1791
* Thu Jun 11 2015 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-41
- improved fix for CVE-2015-1791
- add missing parts of CVE-2015-0209 fix for corectness although unexploitable
* Tue Jun 09 2015 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-40
- fix CVE-2014-8176 - invalid free in DTLS buffering code
- fix CVE-2015-1789 - out-of-bounds read in X509_cmp_time
- fix CVE-2015-1790 - PKCS7 crash with missing EncryptedContent
- fix CVE-2015-1791 - race condition handling NewSessionTicket
- fix CVE-2015-1792 - CMS verify infinite loop with unknown hash function
...
-
So the fix for that has apparently been backported to 1.0.1e that is used in SME. Cool.
I was thinking of the TLS versions that can be used - some stuff cannot be backported.
The original post suggested the error was during collection:
at every fraction of time in which the server makes the "collection", I receive an error from startmail of the following tone:
So that does not suggest he is under attack but there is an issue with fetchmail connecting to his provider (as far as I read it)
-
So that does not suggest he is under attack but there is an issue with fetchmail connecting to his provider (as far as I read it)
First of all, thanks to everyone answered to my help request and beg Your pardon for my english, as You see I'm not motherlanguage, that's why I posted my question in this part of the forum.
I discovered, trying to access every provider in the list of fetchmail, that the issue is due to yahoo mail, all others do their work normally; I don't know why, I tried also all the options in --sslproto, but it continues to give me that error.
So, i decided to redirect the mailbox on Yahoo on another email address that have no issue with fetchmail commands.
No more errors, no more pain. ;-)
-
Not a problem.
Yahoo are a consistent nightmare. Have they swapped to OAuth now perhaps?
They really all want you on webmail so they can fling you more ads I guess
Glad you are fixed.