Hi,
> > | +static inline uschar *
> > | +get_challenge_unistr(SPAAuthChallenge * challenge, SPAStrHeader * hdr)
> > | +{
> > | +int off = IVAL(&hdr->offset, 0);
> > | +int len = SVAL(&hdr->len, 0);
> > | +return off + len < sizeof(SPAAuthChallenge)
> > | + ? US unicodeToString(CS challenge + off, len/2) : US"";
> > | +}
>
> So: Assuming that int is 32 bit, 'off' is 32 bit signed, IVAL() returns an
> attacker-controlled 32 bit unsigned value, so via usual
> implementation-defined behaviour, the attacker can make 'off' negative, and
> then, if len is large enough to trigger undefined behaviour in the
> addition, can usually cause off + len to be positive again, and, if smaller
> than sizeof(SPAAuthChallenge), can thus pass the bounds check, which thus
> can be used to read up to 64 KiB before SPAAuthChallenge.
Erm ... obviously (or so you'd think), that's nonsense. I mean, the attack
isn't, but there is no undefined behaviour in that addition in that
scenario.
But of course, the attacker can *also* trigger undefined behaviour in that
addition ... though that's probably usually harmless because the generated
code probably usually would just trigger the bounds check. But then, it's
probably not a good idea to have undefined behaviour anyway ...
Regards, Florian
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
