In university I ran a Drupal website for an undergraduate student body. The university had a single-sign-on system called “Raven”, and happily someone had already had written a Drupal 5 module to allow using Raven authentication, called “ucamraven“.
When Drupal 6 came out, I dutifully wrote a Drupal 6 version of ucamraven but got stuck with an issue verifying the signature returned by Raven after a redirect.
Well it turned out that the original code did the following, spread out across multiple lines:
$data = # data about user returned from SSO
$r_sig = # Signature of $data using SSO's private key
$sig = custom_decode($r_sig)
if(openssl_verify($data, custom_decode($sig), $pubkey) != -1 {
# login successfully as user described by $data
}
# login failure
However openssl_verify returns 0 on a bad signature (-1 is for other errors), so the module would allow forged SSO responses, so long as the signature had the correct structure.
The code has a second error – the signature was decoded twice. Presumably this bug was why the author ended up with the incorrect openssl_verify check.
With this bug fixed we released a Drupal 6 version with the security issue patched. I reached out to owners of sites using the vulnerable module so that they could upgrade. @tfgg2 also backported the fix for the Drupal 5 module.
Lessons
- Test both positive and negative cases
- Prefer checking for the desired response value over checking for the lack of an error response.
Leave a Reply