* Don't echo (unsanitized) OTP/NONCE values back to client when
sending error codes. Reported by Paul van Empelen.
Resolving this problem protects (arguably buggy) clients against
an attack. Prior versions of the Yubico C and PHP clients do not
appear to exhibit this bug. We provide an analysis of the issue
below so that you can review client implementations for the
problem. Note that you do not have to fix clients if you are
using this server version (or later), although we recommend it
anyway.
If the client sends a OTP value that ends with '%0astatus=OK' the
server output will contain a line 'status=ok' before the real
status code status=MISSING_PARAMETER. Note lower-casing of the
injected status code, so that it doesn't match a correct
'status=OK' response. Note also that the OTP value would fail
normal input validation checks in the client.
If the client sends a NONCE value that ends with '%0astatus=OK'
the output will contain a line consisting of 'status=OK' before
the correct status=MISSING_PARAMETER. However, the NONCE value is
generated by client code internally and does not come from any
untrusted source, thus the impact here is limited -- if an
attacker is able to trick a client into sending a crafted NONCE
value the attacker is normally able to modify the client code
somehow, and can thus trick the client in other ways as well.
Similar issues apply to the ID field, which is normally also under
control of the trusted client code and not something an attacker
could influence.
Thus, this server-side fix solve a client-side issue that we
believe would only occur when both of these conditions are true:
1) the client does not do proper input validation of the OTP, and
2) the client incorrectly parses 'status=ok' as 'status=OK'.
or when the following condition is true
A) the client can be tricked into sending a crafted NONCE or ID
value.