tree 74dd30fea130db4c9b244f09ce939804bd8dcded
parent 0f1e76b8eeec0b06a65bc88763aa6f28e8e4003b
author Maxim Dounin <mdounin@mdounin.ru> 1621383200 +0300
committer Maxim Dounin <mdounin@mdounin.ru> 1621383200 +0300

Mail: fixed s->arg_start clearing on invalid IMAP commands.

Previously, s->arg_start was left intact after invalid IMAP commands,
and this might result in an argument incorrectly added to the following
command.  Similarly, s->backslash was left intact as well, leading
to unneeded backslash removal.

For example (LFs from the client are explicitly shown as "<LF>"):

  S: * OK IMAP4 ready
  C: a01 login "\<LF>
  S: a01 BAD invalid command
  C: a0000000000\2 authenticate <LF>
  S: a00000000002 aBAD invalid command

The backslash followed by LF generates invalid command with s->arg_start
and s->backslash set, the following command incorrectly treats anything
from the old s->arg_start to the space after the command as an argument,
and removes the backslash from the tag.  If there is no space, s->arg_end
will be NULL.

Both things seem to be harmless though.  In particular:

- This can be used to provide an incorrect argument to a command without
  arguments.  The only command which seems to look at the single argument
  is AUTHENTICATE, and it checks the argument length before trying to
  access it.

- Backslash removal uses the "end" pointer, and stops due to "src < end"
  condition instead of scanning all the process memory if s->arg_end is
  NULL (and arg[0].len is huge).

- There should be no backslashes in unquoted strings.

An obvious fix is to clear s->arg_start and s->backslash on invalid commands,
similarly to how it is done in POP3 parsing (added in 810:e3aa8f305d21) and
SMTP parsing.

This, however, makes it clear that s->arg_start handling in the "done"
label is wrong: s->arg_start cannot be legitimately set there, as it
is expected to be cleared in all possible cases when the "done" label is
reached.  The relevant code is dead and will be removed by the following
change.