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"";
> | +}
>
> 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,
> which isn't detected by the bounds check, and thus can be used to read data
> that's stored before 'challenge'.
>
> Undefined behaviour results if 'off' is INT_MAX and 'len' is non-zero.
> Usually, that'll lead to overflow in the addition, also resulting in a
> negative value that passes the bounds check, thus allowing to read data
> roughly INT_MAX behind 'challenge', which presumably would be a different
> location with 64 bit pointers.
Just in case anyone hasn't noticed yet: That was a bit of a brain fart,
apparently I overlooked that sizeof gives a size_t or something ...
But it's still correct that the bounds check doesn't work, just the
explanation is somewhere between confusing and incorrect.
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.
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/
