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