Re: stringprep() doesn't match documentation

[Simon Josefsson]

Thijs Alkemade <address@hidden> writes:

> Hi,
>
> The documentation for the stringprep() function states:
>
> "[I]ndicate how large the buffer holding the string is. This function will not
> _read_ or write to characters outside that size."
>
> Looking at the source, this is clearly not true: the maxlen argument to
> stringprep() is only used at the end to check whether the resulting string
> fits in the buffer. The stringprep_utf8_to_ucs4() call is not restricted to
> stay within any limits.
>
> This means that, if an attacker is able to inject invalid UTF-8 into the input
> buffer used for stringprep(), the lack of error checking by
> stringprep_utf8_to_ucs4() can be used to skip over the actual terminating
> NULL-byte, causing he stringprep call to read memory past the buffer it was
> supposed to not read outside of. Sure, this is the application's fault for not
> properly veryfing the input is UTF-8, but the mismatch between the
> documentation and the function makes this worse.

If the input string is valid UTF-8, I believe there is no problem.  Do
you agree?

Applications should not pass unvalidated strings to stringprep(), it
must be checked to be valid UTF-8 first.  If stringprep() receives
non-UTF8 inputs, I believe there are other similar serious things that
can happen.

Quoting the docstring:

 * Prepare the input zero terminated UTF-8 string according to the
 * stringprep profile, and write back the result to the input string.

Admittedly, the library could 1) provide functions for checking whether
a string is valid UTF-8, and/or 2) actually validate that inputs are
UTF-8 before using them.  The latter may cause a small performance
penalty, but probably not that much.  Further thinking or suggestions in
this direction is welcome.

/Simon

signature.asc
Description: PGP signature