> The explanation misses a lot of details.
Here's my understanding (only from the article, YMMV):
0. Assume that there is an "admin" account with special power, and that
the attacker has created an "admin99" account.
1. The attacker successfully logs in via a form, and the server sends her
the cookie "admin99|20080601|DEADBEEF". (Assume that md5
("admin9920080601secret") == "DEADBEEF".)
2. On subsequent requests the attacker presents the above cookie. The
server notices that the cookie is valid (because md5
("admin9920080601secret") == "DEADBEEF"), that this is user "admin99",
and that the session has not yet expired (it's still May 2008). Fine!
3. But now the attacker sends the following doctored cookie: "admin|
9920080601|DEADBEEF". This still checks out as valid because md5
("admin9920080601secret") == "DEADBEEF"), the session is for some
reason[1] still not considered expired, so the attacker now has the
identity of user "admin".
[1] IMO not validating the expiration date format is one of the main
errors here. Or does WP strive to be Y10K compliant??
Cryptographic splicing makes for a Wordpress vulnerability
Posted May 16, 2008 13:37 UTC (Fri) by jake (editor, #205)
[Link]
> IMO not validating the expiration date format is one of the main
> errors here. Or does WP strive to be Y10K compliant??
In the article, I was trying to steer clear of providing complete, exploitable details while
still giving more details than the advisory. I believe the expiration is actually the number
of seconds since the epoch, which may be easier to exploit and still validate as a reasonable
expiration.
jake