oss-sec mailing list archives
Re: CVE request: MediaWiki 1.22.5 login csrf
From: Chris Steipp <csteipp () wikimedia org>
Date: Fri, 28 Mar 2014 12:01:56 -0700
On Fri, Mar 28, 2014 at 11:13 AM, Florent Daigniere < florent.daigniere () trustmatta com> wrote:
On Fri, 2014-03-28 at 10:25 -0700, Chris Steipp wrote:On Fri, Mar 28, 2014 at 8:56 AM, Florent Daigniere < florent.daigniere () trustmatta com> wrote:On Fri, 2014-03-28 at 08:33 -0700, Chris Steipp wrote:On Mar 28, 2014 7:54 AM, "Florent Daigniere" < florent.daigniere () trustmatta com> wrote:Sorry to be thick here but it still doesn't make any sense to me... The session-id should be renewed upon login AND anycredential/privilegechange (that includes password changes). This protects againstsessionfixation attacks (where the attacker coerce a user into using asessionhe controls). On these pages, there's usually no need for anti-CSRF protection astheytend to require credentials (something the attacker, by definition, doesn't have).Slightly different attack. The attacker (who knows their ownpassword andchooses the reset-to password) was able to cause a logged out user(victim)to login with the attacker's account via the change password form.That is the textbook example of a session-fixation attack. The "end state" is that the victim uses a session the attacker can control.Except that it has very little to do with the user's session. We can (and do) refresh the user's session id as part of the login process. We could refresh the user's session every time the user visits that form, and the PoC on the bug would still work. The PoC on the bug shows that a non mediawiki domain can make a POST tothemediawiki domain to login an anonymous user as the attacker. Using the definition from owasp, "CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she iscurrentlyauthenticated" this satisfies the part that an attacker is takingunwantedaction on behalf of the victim. If you want to argue that "logging in" is inherently an action by an unauthenticated user and so it doesn't meetthey"in which he/she is currently authenticated" then I'm happy to not call this CSRF. However we did call the same attack a "login CSRF" for the nearly identical issue CVE-2010-1150 and a very similar CVE-2012-5394.Well, it's not because mistakes were made in the past that we should use them to justify perpetrating them.
No, I'm not saying we should. I was merely pointing out that is how this issue was classified in the past, in case the explanation for those assignments was more clear than I'm presenting it. If those are wrong, they should be fixed.
Why do you call that a vulnerability again? The attacker forfeits his credentials; the target ends up logged in as the attacker with a session the attacker has no control over... and the user is made aware (through the UI) that he's logged in as someone else. No trust boundary breached -> no vulnerability. After "forced logouts" welcome "forced logins" ;)
Right, this goes back to my example of user-supplied javascript executing when that user logs in, so for MediaWiki, I would argue this is a vulnerability. However, I'm more than happy to say this is specific to MediaWiki (and many sites do implement anti-csrf tokens on their login forms), so if it's not considered an issue, then no cve needs to be assigned.
This attack is somewhat specific to mediawiki since we allow users to define JavaScript that will be loaded on pages they visit whileloggedin... So the victim in this case would run the attacker's personal JavaScript.It still doesn't make sense. Anti-CSRF tokens are only useful if the "malicious script" is not running with the same origin!I think I threw you off here-- this is just one reason why an attacker might want to do this. It's tangential to the actual flaw we fixed.If mediawiki really allows users to define javascript that will be loaded on pages they visit, that's a vulnerability... There's no way to do that securely if the "content" and "application" data are served from the same FQDN. Regards, Florent
Current thread:
- CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 27)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Jann Horn (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 29)
- Re: CVE request: MediaWiki 1.22.5 login csrf Jann Horn (Mar 29)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)