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
