| Summary: | mail-mta/exim: STARTTLS response injection (buffering) (CVE-2021-38371) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | John Helmert III <ajak> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | IN_PROGRESS --- | ||
| Severity: | minor | CC: | grobian, hanno, jaco, jasmin+gentoo |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://nostarttls.secvuln.info | ||
| Whiteboard: | B4 [upstream] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 807352 | ||
|
Description
John Helmert III
2021-08-10 20:37:59 UTC
@hanno: do you know if there's any news on this? No, except that we recently got a request to re-check this and could confirm that it was still present in exim 4.95. I have to say during our research this wasn't a main focus of us. We mostly looked into mail client to server communication and kinda looked on the server to server part only briefly as we already had the tools ready. We reported issues, but didn't really follow up (also generally people have less expectation of s2s connections to be secure). Hello one and all. Are there any news on this? There is an 4.96 ebuild in portage but it's mask. Couldn't find a related bug entry with the reason. Something about SPF? cheers, t. grobian, is there an upstream bug for the issue that led to the mask? I communicated with upstream about the issue, even provided a buildanimal for them, but they simply didn't care, Gentoo is not a supported platform for them. I upstream has a fix, they usually keep it under embargo, only allowing package managers like Debian to build a new binary without exposing the codepatch. So we always have to wait until they release. There is no exim-4.96+fixes, exim-4.95+fixes only contains a build-fix (which we already use), and exim-4.94.2+fixes doesn't seem to contain anything that would suggest to fix this issue. If there is an upstream bug for it, it's likely under embargo too. Oh wow, thanks. FWIW there's some stuff at https://sources.debian.org/patches/exim4/4.96-12/ including an SPF fix, but no idea if it's useful (see also https://metadata.ftp-master.debian.org/changelogs//main/e/exim4/exim4_4.96-12_changelog). buster and bullseye both run 4.94.2 (like us), I don't see any patches in https://sources.debian.org/patches/exim4/4.94.2-7/ or https://sources.debian.org/patches/exim4/4.94.2-7~bpo10%2B1/ that would hint at fixing this issue. The SPF patch is just plugging a memleak in SPF, which cannot be STARTTLS response injection, AFAICT. Sorry, I was referring to the reason for the package.mask (crash) w/ SPF. Thanks to Sam, who did a little bit more digging on this CVE, there is a little more info to this. CentOS 8 reported not to be vulnerable using 4.94.2: https://lists.exim.org/lurker/message/20220104.160144.9dc599ce.pl.html But Hanno (one of the original authors of the research on the vulnerability) in comment #2 claims it is still vulnerable. So, I ran the tool on our Gentoo 4.94.2-r12 Exim: % python3 command-injection-tester --smtp localhost /export/gentoo/working-repos/command-injection-tester/command-injection-tester:291: DeprecationWarning: ssl.SSLContext() without protocol argument is deprecated. context = ssl.SSLContext() /export/gentoo/working-repos/command-injection-tester/command-injection-tester:291: DeprecationWarning: ssl.PROTOCOL_TLS is deprecated context = ssl.SSLContext() SMTP: 2023-01-06 10:00:06 - INFO - Testing SMTP server at localhost:587 SMTP: 2023-01-06 10:00:06 - DEBUG - Logdir: ./logs, Comment: commandinjectiontester, Timeout: 2 SMTP: 2023-01-06 10:00:06 - INFO - Sanity test... SMTP: 2023-01-06 10:00:08 - TRACE - S: 220 MAILSERVER ESMTP Exim 4.94.2 Fri, 06 Jan 2023 10:00:06 +0100 SMTP: 2023-01-06 10:00:08 - TRACE - C: EHLO commandinjectiontester SMTP: 2023-01-06 10:00:10 - TRACE - S: 250-MAILSERVER Hello commandinjectiontester [::1] SMTP: 2023-01-06 10:00:10 - TRACE - S: 250-SIZE 134217728 SMTP: 2023-01-06 10:00:10 - TRACE - S: 250-8BITMIME SMTP: 2023-01-06 10:00:10 - TRACE - S: 250-PIPELINING SMTP: 2023-01-06 10:00:10 - TRACE - S: 250-PIPE_CONNECT SMTP: 2023-01-06 10:00:10 - TRACE - S: 250-CHUNKING SMTP: 2023-01-06 10:00:10 - TRACE - S: 250-STARTTLS SMTP: 2023-01-06 10:00:10 - TRACE - S: 250 HELP SMTP: 2023-01-06 10:00:10 - TRACE - C: NOOP SMTP: 2023-01-06 10:00:12 - TRACE - S: 250 OK SMTP: 2023-01-06 10:00:12 - TRACE - C: STARTTLS SMTP: 2023-01-06 10:00:14 - TRACE - S: 220 TLS go ahead SMTP: 2023-01-06 10:00:14 - DEBUG - <----- TLS Handshake -----> SMTP: 2023-01-06 10:00:14 - TRACE - C: QUIT SMTP: 2023-01-06 10:00:14 - TRACE - S: 221 MAILSERVER closing connection SMTP: 2023-01-06 10:00:14 - INFO - Sanity test done SMTP: 2023-01-06 10:00:14 - INFO - Testing for command injection... SMTP: 2023-01-06 10:00:16 - TRACE - S: 220 MAILSERVER ESMTP Exim 4.94.2 Fri, 06 Jan 2023 10:00:14 +0100 SMTP: 2023-01-06 10:00:16 - TRACE - C: EHLO commandinjectiontester SMTP: 2023-01-06 10:00:18 - TRACE - S: 250-MAILSERVER Hello commandinjectiontester [::1] SMTP: 2023-01-06 10:00:18 - TRACE - S: 250-SIZE 134217728 SMTP: 2023-01-06 10:00:18 - TRACE - S: 250-8BITMIME SMTP: 2023-01-06 10:00:18 - TRACE - S: 250-PIPELINING SMTP: 2023-01-06 10:00:18 - TRACE - S: 250-PIPE_CONNECT SMTP: 2023-01-06 10:00:18 - TRACE - S: 250-CHUNKING SMTP: 2023-01-06 10:00:18 - TRACE - S: 250-STARTTLS SMTP: 2023-01-06 10:00:18 - TRACE - S: 250 HELP SMTP: 2023-01-06 10:00:18 - TRACE - C: STARTTLS SMTP: 2023-01-06 10:00:18 - TRACE - C: EHLO commandinjectiontester SMTP: 2023-01-06 10:00:20 - TRACE - S: 220 TLS go ahead SMTP: 2023-01-06 10:00:20 - DEBUG - <----- TLS Handshake -----> SMTP: 2023-01-06 10:00:22 - DEBUG - No response in encrypted context, trying real command now ... SMTP: 2023-01-06 10:00:22 - TRACE - C: FAKE commandinjectiontester SMTP: 2023-01-06 10:00:24 - TRACE - S: 500 unrecognized command SMTP: 2023-01-06 10:00:24 - INFO - Probably no command injection here! Which leads me to come to the same conclusion as for CentOS 8, that our Exim is NOT vulnerable. @hanno, can you provide a little more details as to what you tested, and how you conclude a vulnerability here? Thanks! @fabian: This type of vulnerability can happen both on the sending and the receiving side of the mail server. The vulnerability in exim is on the sending side. The command-injection-tester script tests this only for the receiving side. Testing the sending side is a bit more involved and requires setting up a malicious receiving server and doing some manual inspection. The code to do this is here: https://github.com/Email-Analysis-Toolkit/fake-mail-server Unfortunately this is not super-well documented (check the buffering examples in the imap testcases for some description). But I can definitely confirm that we last checked this for 4.95 and verified the bug is still there. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8c4214e226e909b4f237b55be0c7b935d60c3d78 commit 8c4214e226e909b4f237b55be0c7b935d60c3d78 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2023-06-02 07:00:05 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2023-06-02 07:00:05 +0000 profiles/package.mask: drop exim-4.96 mask Latest revision has a bulk of patches from upstream that seem to fix the previously observed crashes and problems. Bug: https://bugs.gentoo.org/807619 Signed-off-by: Fabian Groffen <grobian@gentoo.org> profiles/package.mask | 5 ----- 1 file changed, 5 deletions(-) |