I received an email yesterday that brought up a frequent concern about my Secure XML-RPC proposal – that it might be vulnerable to a length extension attack:
In [XMLRPCS_Profile.php], the hash is calculated with SHA-256, which has so called length-extension “feature”, which means an adversary can append his own data at the end of the payload (without knowing the key).
This isn’t the first time someone has raised this concern. I want to take some time to briefly explain what’s going on here and why the code isn’t actually vulnerable to such an attack.
Length Extension Attack
A length extension attack is one that primarily targets message signature with algorithms that take the form [cci]Hash( salt + message )[/cci]. The attacker is able to append data to a known message and generate a valid signature without necessarily knowing the secret salt used to generate the original signature.
I won’t get too much into the details of how this attack is implemented – if you’re curious, read the example on Wikipedia. The Cliff Notes version is that you take the original message, append some calculable amount of padding, then append your intended attack string.
The purpose of the attack, is simple – to append some desired content to the end of a known (validated) message and trick the server into accepting your corrupted payload. With messages in GET and POST requests (i.e. query strings), this is a significant vulnerability since hackers can essentially override valid values with whatever they want and convince your server it’s seeing a completely valid message.
If you’re using method signing to validate this form of data, be sure to use something like HMAC to generate your signatures instead.
Secure XML-RPC
My proposed WordPress security extension – currently coded as a plugin – uses a simple SHA-256 hash to generate message signatures. It builds the signature with the following PHP code:
[cc lang=”php]$calculated = hash( ‘sha256’, $secret . $body );[/cc]
This code takes the exact format I explain above that is vulnerable to length extension – but the implementation here isn’t broken. The thing you need to keep in mind here is what the content of the message body looks like.
We’re dealing with XML-RPC, so the body of the message must be a well-formed XML document. Since a length extension attack only allows you to append content to an existing (signed) message, this means you can only append your attack string after the close of the otherwise valid XML document (producing in turn an invalid XML-RPC request).
If we were signing, say, an [cci]application/x-www-form-urlencoded[/cci] POST message I would be concerned about length extension. Since we’re signing a complete XML document, I’m not worried about someone trying to append data to the end. All the appended data will do is kick out an error in the parsing of the message and cause the system to fail – it’s secure enough as-is that we don’t need to use a more sophisticated (slower) hashing algorithm.