Re: [Dovecot] Dovecot LDA/LMTP vs postfix virtual delivery agent and the x-original-to header
Sadly, I guess not... I'm not sure what to make of this, seeing as both Wietse and Timo said it was almost a trivial thing to fix. On Fri Apr 12 2019 12:17:22 GMT-0400 (Eastern Standard Time), Tanstaafl via dovecot wrote: > I'm resurrecting this again because I'm getting pretty close to possibly > being ready to install a brand new dovecot server (finally), but I still > need for dovecots LMTP to add the x-original-to header. > > So... was this completed quietly, or is support for it still not there? > > Thanks, > > Charles
Re: pigeonhole tests crashing in deleteheader.svtest
On 4/12/19 12:48 AM, Stephan Bosch wrote: On 29/03/2019 10:23, Michal Hlavinka via dovecot wrote: On 3/28/19 6:41 PM, Aki Tuomi via dovecot wrote: On 28 March 2019 19:40 Michal Hlavinka via dovecot wrote: Hi, when trying to build dovecot 2.3.5.1 pigeonhole testsuite crashes in Which version of pigeonhole are you using? latest available - 0.5.5 Hmm, what platform are you compiling this on and what compiler are you using? Fedora Linux, x86_64, kernel 5.0.6, glibc 2.29.9000, gcc 9.0.1 Looking at the backtrace, it seems it's probably related to https://dovecot.org/pipermail/dovecot/2019-January/114494.html
Re: v2.3.5.2 released
> On 18 April 2019 14:40 Benny Pedersen via dovecot wrote: > > > Aki Tuomi via dovecot skrev den 2019-04-18 11:35: > > > * CVE-2019-10691: Trying to login with 8bit username containing > > invalid UTF8 input causes auth process to crash if auth policy is > > enabled. This could be used rather easily to cause a DoS. Similar > > crash also happens during mail delivery when using invalid UTF8 > > in > > From or Subject header when OX push notification driver is used. > > can this aswell crash dovecot policy service so check policy service on > postfix tempfails ? I am not sure what "dovecot policy service" you mean This bug only affects push notifications and auth policy (e.g. weakforced) connector, as they send out JSON. The crash isn't related to UTF-8 input handling as per such. Aki
Re: v2.3.5.2 released
Aki Tuomi via dovecot skrev den 2019-04-18 11:35: * CVE-2019-10691: Trying to login with 8bit username containing invalid UTF8 input causes auth process to crash if auth policy is enabled. This could be used rather easily to cause a DoS. Similar crash also happens during mail delivery when using invalid UTF8 in From or Subject header when OX push notification driver is used. can this aswell crash dovecot policy service so check policy service on postfix tempfails ?
Problems with auth connection
Hi, We are having some issues with the auth connection Version: 2.3.5.1, with MySQL and Postfix The server is working fine, and randomly after some days, Dovecot fails to auth: Apr 18 14:25:16 mail dovecot[25013]: auth: Warning: Event 0x126eba20 leaked (parent=0x126eb820): auth-request.c:89 Apr 18 14:25:16 mail dovecot[25013]: auth: Warning: Event 0x126eb420 leaked (parent=0x0): auth-client-connection.c:338 It's neccesary to restart dovecot, and once restarted the server start to work fine again and deliver emails What do you think i could do? Thank you, best regards Fernando
Re: ssl_verify_server_cert against SAN?
Aside from these two things they have really, I mean really a lot, issues in open state regarding ssl... Which maybe speaks for a more generous alternativ anyways On 18/04/2019 12:25, TG Servers wrote: Kostya, they have already a bug open on this as I saw now https://jira.mariadb.org/browse/MDEV-18131 and I also filed a bug on the TLS cipher string issue from yesterday. Depending on when this will be resolved I will have to consider alternatives anyway, yes Thanks for the hints! -- T On 18/04/2019 12:15, Kostya Vasilyev via dovecot wrote: Have you considered any alternatives? I'm thinking of IPSec to create a secured network encapsulation channel(s) "above" the TCP connection(s). This would provide encryption with control over cipher(s), and cert validation on both sides (if you used cert auth, not PSK). -- K On Thu, Apr 18, 2019, at 12:15 PM, TG Servers via dovecot wrote: Ok then it seems again a MariaDB issue, they don't check against IP in the SAN it seems, this has nothing to do with ssl_ca setting it seems host= port= dbname= user= ssl_verify_server_cert=yes ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= brings up this Connect failed to database (vmail): SSL connection error: SSL certificate validation failure host= port= dbname= user= ssl_verify_server_cert=no ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= is working contents from my.cnf : ssl_cert="/etc/ssl/certs/mysql.pem" ssl_key="/etc/ssl/certs/mysql.key" ssl_ca="/etc/ssl/certs/ca-bundle.crt" ssl_cipher="TLSv1.2" and from command line mysql --ssl --ssl-verify-server-cert --host brings up ERROR 2026 (HY000): SSL connection error: Validation of SSL server certificate failed while mysql --ssl --ss-verify-server-cert --host works TLS isn't really the domain of MariaDB, they have really a lot of crap going on there, a lot of, sadly... Thanks On 18/04/2019 10:52, Aki Tuomi via dovecot wrote: On 18 April 2019 11:34 TG Servers via dovecot wrote: Hi, when using ssl_verify_server_cert in mysql connection string, is the cert verified also against SAN (DNS and IP)? Because this doesn't seem to work. I get a certification verification error in handshake when connecting via IP. But the cert is good as the connection via IP (and IP in the SAN of the cert) works from other applications verifying. Thanks. Dovecot does consider SAN names too, but for MySQL driver, we use MYSQL_OPT_SSL_VERIFY_SERVER_CERT setting. Then you need to use ssl_ca or ssl_ca_path in the mysql driver config file to point to acceptable CAs. Aki
Re: ssl_verify_server_cert against SAN?
Kostya, they have already a bug open on this as I saw now https://jira.mariadb.org/browse/MDEV-18131 and I also filed a bug on the TLS cipher string issue from yesterday. Depending on when this will be resolved I will have to consider alternatives anyway, yes Thanks for the hints! -- T On 18/04/2019 12:15, Kostya Vasilyev via dovecot wrote: Have you considered any alternatives? I'm thinking of IPSec to create a secured network encapsulation channel(s) "above" the TCP connection(s). This would provide encryption with control over cipher(s), and cert validation on both sides (if you used cert auth, not PSK). -- K On Thu, Apr 18, 2019, at 12:15 PM, TG Servers via dovecot wrote: Ok then it seems again a MariaDB issue, they don't check against IP in the SAN it seems, this has nothing to do with ssl_ca setting it seems host= port= dbname= user= ssl_verify_server_cert=yes ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= brings up this Connect failed to database (vmail): SSL connection error: SSL certificate validation failure host= port= dbname= user= ssl_verify_server_cert=no ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= is working contents from my.cnf : ssl_cert="/etc/ssl/certs/mysql.pem" ssl_key="/etc/ssl/certs/mysql.key" ssl_ca="/etc/ssl/certs/ca-bundle.crt" ssl_cipher="TLSv1.2" and from command line mysql --ssl --ssl-verify-server-cert --host brings up ERROR 2026 (HY000): SSL connection error: Validation of SSL server certificate failed while mysql --ssl --ss-verify-server-cert --host works TLS isn't really the domain of MariaDB, they have really a lot of crap going on there, a lot of, sadly... Thanks On 18/04/2019 10:52, Aki Tuomi via dovecot wrote: On 18 April 2019 11:34 TG Servers via dovecot wrote: Hi, when using ssl_verify_server_cert in mysql connection string, is the cert verified also against SAN (DNS and IP)? Because this doesn't seem to work. I get a certification verification error in handshake when connecting via IP. But the cert is good as the connection via IP (and IP in the SAN of the cert) works from other applications verifying. Thanks. Dovecot does consider SAN names too, but for MySQL driver, we use MYSQL_OPT_SSL_VERIFY_SERVER_CERT setting. Then you need to use ssl_ca or ssl_ca_path in the mysql driver config file to point to acceptable CAs. Aki
Re: ssl_verify_server_cert against SAN?
Have you considered any alternatives? I'm thinking of IPSec to create a secured network encapsulation channel(s) "above" the TCP connection(s). This would provide encryption with control over cipher(s), and cert validation on both sides (if you used cert auth, not PSK). -- K On Thu, Apr 18, 2019, at 12:15 PM, TG Servers via dovecot wrote: > Ok then it seems again a MariaDB issue, they don't check against IP in the > SAN it seems, this has nothing to do with ssl_ca setting it seems > > host= port= dbname= user= ssl_verify_server_cert=yes > ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= > brings up this > *Connect failed to database (vmail): SSL connection error: SSL certificate > validation failure * > > host= port= dbname= user= ssl_verify_server_cert=no > ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= is > working > > contents from my.cnf : > ssl_cert="/etc/ssl/certs/mysql.pem" > ssl_key="/etc/ssl/certs/mysql.key" > ssl_ca="/etc/ssl/certs/ca-bundle.crt" > ssl_cipher="TLSv1.2" > > and from command line > mysql --ssl --ssl-verify-server-cert --host brings up > ERROR 2026 (HY000): SSL connection error: Validation of SSL server > certificate failed > while > mysql --ssl --ss-verify-server-cert --host works > > TLS isn't really the domain of MariaDB, they have really a lot of crap going > on there, a lot of, sadly... > > > Thanks > > > On 18/04/2019 10:52, Aki Tuomi via dovecot wrote: >> >>> On 18 April 2019 11:34 TG Servers via dovecot wrote: Hi, when using ssl_verify_server_cert in mysql connection string, is the cert verified also against SAN (DNS and IP)? Because this doesn't seem to work. I get a certification verification error in handshake when connecting via IP. But the cert is good as the connection via IP (and IP in the SAN of the cert) works from other applications verifying. Thanks. >>> >> Dovecot does consider SAN names too, but for MySQL driver, we use >> MYSQL_OPT_SSL_VERIFY_SERVER_CERT setting. Then you need to use ssl_ca or >> ssl_ca_path in the mysql driver config file to point to acceptable CAs. Aki >>
v2.3.5.2 released
Lets try again, put wrong changelog to the mail. Sorry about this. https://dovecot.org/releases/2.3/dovecot-2.3.5.2.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.5.2.tar.gz.sig Binary packages in https://repo.dovecot.org/ * CVE-2019-10691: Trying to login with 8bit username containing invalid UTF8 input causes auth process to crash if auth policy is enabled. This could be used rather easily to cause a DoS. Similar crash also happens during mail delivery when using invalid UTF8 in From or Subject header when OX push notification driver is used. --- Aki Tuomi Open-Xchange oy signature.asc Description: OpenPGP digital signature
Re: ssl_verify_server_cert against SAN?
Ok then it seems again a MariaDB issue, they don't check against IP in the SAN it seems, this has nothing to do with ssl_ca setting it seems host= port= dbname= user= ssl_verify_server_cert=yes ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= brings up this Connect failed to database (vmail): SSL connection error: SSL certificate validation failure host= port= dbname= user= ssl_verify_server_cert=no ssl_cipher=TLSv1.2 ssl_ca=/etc/ssl/certs/ca-bundle.crt password= is working contents from my.cnf : ssl_cert="/etc/ssl/certs/mysql.pem" ssl_key="/etc/ssl/certs/mysql.key" ssl_ca="/etc/ssl/certs/ca-bundle.crt" ssl_cipher="TLSv1.2" and from command line mysql --ssl --ssl-verify-server-cert --host brings up ERROR 2026 (HY000): SSL connection error: Validation of SSL server certificate failed while mysql --ssl --ss-verify-server-cert --host works TLS isn't really the domain of MariaDB, they have really a lot of crap going on there, a lot of, sadly... Thanks On 18/04/2019 10:52, Aki Tuomi via dovecot wrote: On 18 April 2019 11:34 TG Servers via dovecot wrote: Hi, when using ssl_verify_server_cert in mysql connection string, is the cert verified also against SAN (DNS and IP)? Because this doesn't seem to work. I get a certification verification error in handshake when connecting via IP. But the cert is good as the connection via IP (and IP in the SAN of the cert) works from other applications verifying. Thanks. Dovecot does consider SAN names too, but for MySQL driver, we use MYSQL_OPT_SSL_VERIFY_SERVER_CERT setting. Then you need to use ssl_ca or ssl_ca_path in the mysql driver config file to point to acceptable CAs. Aki
CVE-2019-10691: JSON encoder in Dovecot 2.3 incorrecty assert-crashes when encountering invalid UTF-8 characters.
Dear subscribers, we're sharing our latest advisory with you and would like to thank everyone who contributed in finding and solving those vulnerabilities. Feel free to join our bug bounty programs (open-xchange, dovecot, powerdns) at HackerOne. You can find binary packages at https://repo.dovecot.org/ Yours sincerely, Aki Tuomi Open-Xchange Oy Open-Xchange Security Advisory 2019-04-18 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOV-3173 (Bug ID) Vulnerability type: CWE-176 Vulnerable version: 2.3.0 - 2.3.5.1 Vulnerable component: json encoder Report confidence: Confirmed Researcher credits: cPanel L.L.C. Solution status: Fixed by Vendor Fixed version: 2.3.5.2 Vendor notification: 2019-04-02 Solution date: 2019-04-11 Public disclosure: 2019-04-18 CVE reference: CVE-2019-10691 CVSS: 7.5 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Vulnerability Details: JSON encoder in Dovecot 2.3 incorrecty assert-crashes when encountering invalid UTF-8 characters. This can be used to crash dovecot in two ways. Attacker can repeatedly crash Dovecot authentication process by logging in using invalid UTF-8 sequence in username. This requires that auth policy is enabled. Crash can also occur if OX push notification driver is enabled and an email is delivered with invalid UTF-8 sequence in From or Subject header. In 2.2, malformed UTF-8 sequences are forwarded "as-is", and thus do not cause problems in Dovecot itself. Target systems should be checked for possible problems in dealing with such sequences. See https://wiki.dovecot.org/Authentication/Policy for details on auth policy support. Risk: Determined attacker can prevent authentication process from staying up by keeping on attempting to log in with username containing invalid UTF-8 sequence. Steps to reproduce: Configure dovecot with auth_policy_server_url and auth_policy_hash_nonce set. Attempt to log in with username containing an invalid UTF-8 sequence Observe assert-crash in dovecot logs. Solution: Operators should update to the latest Patch Release or disable auth policy support. signature.asc Description: OpenPGP digital signature
v2.3.5.2 released
https://dovecot.org/releases/2.3/dovecot-2.3.5.2.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.5.2.tar.gz.sig Binary packages in https://repo.dovecot.org/ * CVE-2019-7524: Missing input buffer size validation leads into arbitrary buffer overflow when reading fts or pop3 uidl header from Dovecot index. Exploiting this requires direct write access to the index files. --- Aki Tuomi Open-Xchange oy signature.asc Description: OpenPGP digital signature
Re: ssl_verify_server_cert against SAN?
> On 18 April 2019 11:34 TG Servers via dovecot wrote: > > > Hi, > > when using ssl_verify_server_cert in mysql connection string, is the cert > verified also against SAN (DNS and IP)? > Because this doesn't seem to work. I get a certification verification error > in handshake when connecting via IP. > But the cert is good as the connection via IP (and IP in the SAN of the > cert) works from other applications verifying. > > Thanks. > Dovecot does consider SAN names too, but for MySQL driver, we use MYSQL_OPT_SSL_VERIFY_SERVER_CERT setting. Then you need to use ssl_ca or ssl_ca_path in the mysql driver config file to point to acceptable CAs. Aki
ssl_verify_server_cert against SAN?
Hi, when using ssl_verify_server_cert in mysql connection string, is the cert verified also against SAN (DNS and IP)? Because this doesn't seem to work. I get a certification verification error in handshake when connecting via IP. But the cert is good as the connection via IP (and IP in the SAN of the cert) works from other applications verifying. Thanks.