Hi Phil, all,

> We will review the remaining commits tomorrow.

========================================================================
commit c5017adfb3d157cbaf12e91d693ea8c5ebc5b9fb

    SECURITY: fix SMTP verb option parsing

This fixes the vulnerability that we reported. This function is still
very fragile; if you wish to harden it further, the following lines must
make sure that they do not access or move a pointer out-of-bounds (i.e.,
below smtp_cmd_data):

uschar *v = smtp_cmd_data + Ustrlen(smtp_cmd_data) - 1;

while (isspace(*v)) v--;

  while(isalpha(n[-1])) n--;

Right now we are unable to exploit these because 1/ smtp_read_command()
strips spaces from smtp_cmd_data and 2/ we are unable to store an alpha
or a space at smtp_cmd_data[-1] (the last character of smtp_cmd_buffer).

For example, these two lines can read out-of-bounds (at
smtp_cmd_data[-1]) despite the fixes:

  while(isalpha(n[-1])) n--;

  if (!isspace(n[-1])) return FALSE;

The 2/ is pure luck, because smtp_cmd_data[-1] is the last character of
smtp_cmd_buffer, which is allocated with store_get_perm(), which is not
initialized: smtp_cmd_data[-1] could be anything, but we failed to store
an alpha or a space there (this does not mean it is impossible). So this
should probably be fixed at some point.

========================================================================
commit 4715403ea66aedcf1e0dde61ae483bf3ac3a071f

    SECURITY: rework BDAT receive function handling

This clearly simplifies the BDAT state/stack. Maybe add a
lwr_receive_getc == NULL check in bdat_pop_receive_functions() (and
LOG_PANIC_DIE if it is NULL) to avoid a NULL pointer dereference later
(in case BDAT gets confused somehow)?

========================================================================

Thank you very much! We are at your disposal for questions, comments,
and further discussions.

With best regards,

-- 
the Qualys Security Advisory team
