LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityCryptographic splicing makes for a Wordpress vulnerability Authentication bypass vulnerabilities are particularly painful because they allow an attacker to access and potentially modify things that should be off-limits. It is important to ensure that when fixing that kind of bug, one does not introduce a different, but equally potent, hole. A recent Wordpress vulnerability clearly demonstrates the care that needs to be taken. The problem started in November 2007, when Steven Murdoch reported a problem with Wordpress authentication cookies. Essentially, the cookie that Wordpress used was an MD5 hash calculated using a value stored in the database's user table. Any attacker that could get read access to the database, via a SQL injection or looking inside a database backup for example, could generate a cookie value that would allow them access as that user. The password itself was not stored in the database as plaintext, but the value used in the cookie was just a simple MD5 of the stored value. So, the value stored was MD5(password) and the cookie value was MD5(MD5(password)). Murdoch released his advisory in advance of a fix, because the vulnerability was being actively exploited. It was entered as bug #5367 into the Wordpress bug tracking system and a long conversation about how to properly fix it ensued. As part of that discussion, Murdoch suggested that a paper entitled "Dos and Don'ts of Client Authentication on the Web" [PDF] be consulted. The paper covers various issues regarding cookies and the kinds of attacks that can be made against them. Some, but not all, of its recommendations were followed. The new cookie scheme was released at the end of March as part of the Wordpress 2.5 release. Authentication cookie values were now calculated using the following (with the '.' operator representing concatenation):
USERNAME . "|" . EXPIRATION . "|" . MD5(USERNAME . EXPIRATION . secret)
This took into account the hazards of a straightforward hash of a stored
value and added an expiration to the cookie, but it failed to protect
against a cryptographic splicing attack.
When calculating the hash of the concatenation of the username and expiration (along with a secret known by the server), no delimiter was used between the two. This means that the hash for username "foobar" with expiration "20080507" is the same as the hash for username "foo" with expiration "bar20080507". This allows anyone with a username that begins the same as another username, to generate a legitimate cookie for that other user. Using the example above, user "foobar" could create valid cookies for a user "foo" (or any other prefix substring). Many Wordpress weblogs allow new users to create an account with any name they choose, so long as it is not already taken. By choosing one that starts with the administrator's username, an attacker can generate a cookie for themselves, modify it slightly, and have a valid cookie to access the administrator account. No password cracking is required, nor is any access to the database needed. Wordpress 2.5.1 has been released to address this problem. Earlier versions could disable the registration feature and delete or suspend any user accounts with suspicious usernames as a workaround. Though if those suspicious accounts exist, it would not be surprising to find that the real administrator no longer knows the proper password for that account. The paper that Murdoch referenced clearly indicated the danger from cryptographic splicing, but the Wordpress implementers must have missed it. Cookie authentication schemes are a necessary evil for web applications—it would be nearly unusable to have to authenticate on each page—but they are difficult to get right. A careful reading of the paper will help, as will using already vetted libraries or frameworks. It is one of those things that is hard to get right and extremely important to do so.
New vulnerabilities b2evolution: cross-site scripting
emacs: insecure temp files
kernel: several vulnerabilities
kernel: unspecified vulnerability
kernel: memory corruption
kernel: race condition
kernel: denial of service
kernel: Xen-based denial of service
wordpress: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||