Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2019-15846: Unauthenticated Remote Command Execution Flaw Disclosed for Exim #1313

Open
drwetter opened this issue Sep 8, 2019 · 6 comments

Comments

@drwetter
Copy link
Owner

commented Sep 8, 2019

See https://exim.org/static/doc/security/CVE-2019-15846.txt

The vulnerability is exploitable by sending a SNI ending in a backslash-null sequence during the initial TLS handshake. The exploit exists as a POC.

For more details see doc/doc-txt/cve-2019-15846/ in the source code
repository.

(Tenable also claims a crafted client certificate would trigger the bug, see https://de.tenable.com/blog/cve-2019-15846-unauthenticated-remote-command-execution-flaw-disclosed-for-exim)

Task: Try to develop a check. Problem: No PoC available for now,unclear what ist suppose to happen when sending \\0 (Mitigation is filtering for \\).

Anybody more input? Pls speak up!

@drwetter drwetter added this to the 3.0 milestone Sep 10, 2019
@guettli

This comment has been minimized.

Copy link

commented Sep 11, 2019

I friend of mine just created this test for this CVE:

Exim/exim@dc46d79#diff-6284caef169c0a3f3bec20e66c70aca0

@HeikoSchlittermann

This comment has been minimized.

Copy link

commented Sep 11, 2019

I'm the author of the above regression test (and of the bugfix for this CVE). IMHO there is no way to tell if the bug is fixed or unfixed - beside doing a test similar to the regression test.

And - of course - having success with an exploit would be a clear indication of an vulnerable Exim version :)

Some installations may have added a ACL check for bad SNI or DNs. These installations will drop or deny the connection in response to the MAIL command. But, not being dropped or denied doesn't indicate anything.

openssl s_client -servername 'foo\' -connect ssl.schlittermann.de:25 -starttls smtp
...
250 HELP
MAIL FROM:<>
550-Invalid SNI: foo\
...

But again, this doesn't give you any information whether the bug is present or not.

@drwetter

This comment has been minimized.

Copy link
Owner Author

commented Sep 11, 2019

Hi @HeikoSchlittermann ,

thanks. But I am not sure I understand in depth what you were saying.

Your regression tests hat in L13 -tls_peerdn example.com\ -- the trailing slash. What would be the result for fixed/not fixed?

I read the idea how to exploit this from qualys (https://git.exim.org/exim.git/blob/2600301ba6dbac5c9d640c87007a07ee6dcea1f4:/doc/doc-txt/cve-2019-15846/qualys.mbx?fbclid=IwAR0s-RT6VFL7bbXKeTsu9QWiTEpz_Bu-NkCKXwhV4EtCsWSRmuVOK-smOf0). In fact that would be too much for testssl.sh. An indicator would suffice (after at least a rough check for the smtp banner whether the server runs exim).

In fact openssl s_client -servername 'foo\' -connect localhost:25 -starttls smtp and the subsequent handshake isn't rejected with a 550 on a patched system but returns 250 OK (same on a vulnerable system). Only the logfile on the latter gives a possible clue (TLS packet with unexpected length was received.)

Cheers, Dirk

PS: The HTML part of github's mails seem to swallow the backslash instead of escaping it :-)

@HeikoSchlittermann

This comment has been minimized.

Copy link

commented Sep 11, 2019

@drwetter

This comment has been minimized.

Copy link
Owner Author

commented Sep 11, 2019

Sure that this is related to your check?

no. All checks from testssl.sh are external. Logfiles are not. I was just taking this as a hint for myself, that's what I mean by using the word "only". But it seems I didn't read the sentence before your SMTP handshake correctly.

As the issue arises when reading the spooled data, I suppose, the TLS handshake isn't affected, on patched and on unpatched systems.

makes sense when reading the qualys mails. But it would suffice to use SMTP commands over the TLS connection.

I think I need to look closer at the regression test.

@HeikoSchlittermann

This comment has been minimized.

Copy link

commented Sep 11, 2019

@drwetter drwetter removed this from the 3.0 milestone Sep 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.