Re: [PATCH] imap-send: use xsnprintf to format command

[Jeff King <peff@peff.net>]

On Wed, Apr 03, 2024 at 11:25:42AM +0200, René Scharfe wrote:

> From reading the code I assumed the static buffer is there to stay
> within some IMAP limit.  RFC 9051 mentions the distinction between
> synchronizing and non-synchronizing literals.  The latter have a maximum
> length of 4096 bytes.
> 
> But those are transferred after the command, so have no relevance for
> the command buffer size.  I see no other limits, and I don't see us
> respecting that non-synchronizing literals limit, either.  I guess that
> means messages longer than 4096 bytes could be rejected by a conforming
> IMAP server?  Hmm.

It can also just be a quoted string, which likewise has no limit defined
in that section. That's what we send for LOGIN (you have to go back to
the imap_exec() command which uses a format string). It also looks like
that would barf completely on a username or password that contains a
double-quote. Yup:

  $ git format-patch -1 --stdout |
    git -c imap.user='my"user"' -c imap.pass=foo imap-send --no-curl
  [...]
  IMAP command 'LOGIN <user> <pass>' returned response (BAD) - Invalid characters in atom
  IMAP error: LOGIN failed

> > Likewise imap-send's nfvasprintf() is basically xstrfmt(), except it
> > takes a va_list. So it would have to be replaced by strbuf_vaddf().
> 
> Looking closer I notice that the result of the single nfvasprintf() call
> is fed into the 1024 bytes buffer.  So we could replace it with
> strbuf_vaddf() or xstrvfmt() and still stay within that strange limit,
> as it's enforced later.

Oh, I forgot we had xstrvfmt(). That would obviously be the right match.

> Its own 8192 buffer shields us from huge allocations e.g. due to long
> usernames or paths, but we probably don't need this protection as such
> and "attack" would originate and be felt only locally.

Yeah, I think all of the data here is user controlled. Even if you
didn't trust the patch itself, this is all username, mailbox name, etc.

> > I wouldn't be surprised if there are other opportunities for string
> > cleanup, but I generally hoped that if we waited long enough imap-send
> > would just go away. ;) Either because we could get rid of the tool
> > entirely (though from a recent-ish search, there did not seem to be a
> > lot of good other tools) or because we'd just drop the old code and rely
> > on curl to do the heavy lifting.
> 
> Oh, my build uses curl, so my earlier test run was even worth less than
> I thought.

Heh.

-Peff