Page MenuHomePhabricator

I'm editing in Widar under some else his/her account using oauth
Closed, ResolvedPublic

Description

We seem to have a security issue here in the Oauth implementation of Widar. I'm able to edit under some else his/her account see https://www.wikidata.org/w/index.php?title=Q22135494&type=revision&diff=293822691&oldid=293822124 for an example. I didn't do anything to compromise this other account, it just happened.

This should be handled as a security incident.

Event Timeline

Multichill updated the task description. (Show Details)
Multichill raised the priority of this task from to High.
Multichill added a subscriber: Multichill.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 20 2016, 8:48 PM
csteipp set Security to Software security bug.Jan 20 2016, 8:51 PM
Restricted Application changed the visibility from "Public (No Login Required)" to "Custom Policy". · View Herald TranscriptJan 20 2016, 8:51 PM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript
Restricted Application added a project: Security. · View Herald Transcript

@Multichill, thanks for the report.

I'm not very familiar with how Widar handles it's sessions, @Magnus, are the authorization tokens kept on the server? Or in the user's session?

Adding @Anomie too, in case this is a possible side effect from the sessionmanager update that was recently released.

hoo added a subscriber: hoo.Jan 20 2016, 9:08 PM

I disabled Widar Oauth on Wikidata. My intention was to just do it for myself to not get my account compromised, but this might be for everyone? https://www.wikidata.org/wiki/Special:OAuthListConsumers?name=&publisher=&stage=4

Widar [1.1] (details)

Publisher: Magnus Manske

Description: Wikidata remote editor

Applicable project: All projects on this site

Status: disabled

The current version of Widar is https://www.wikidata.org/wiki/Special:OAuthListConsumers/view/e096baf9fd24cfe180275b52518d7403, still enabled. If we can't find the issue in the next few minutes, I'll disable that one too.

greg added a subscriber: greg.Jan 20 2016, 9:28 PM

I have not changed anything in WiDaR relating to this for many months. Smells like an upstream issue to me.

Well, I make a new consumer version a few days back. But I can't see how that would trigger a bug in WiDaR either.

It looks like this was probably related to a session change in MediaWiki. We're working through that right now. In the meantime, I agree, doesn't seem like Widar is at fault for this.

Although it does look like widar's authentication isn't setting cookies correctly-- tokenKey and tokenSecret are set with path=0, so never get sent back...

Restarted WiDaR webservice. Trying to reproduce the issue by reloading quick_statements. So far, only correct logins. Trying two different user accounts with different browsers from the same machine in case of IP issue, but works fine so far.

Anomie closed this task as Resolved.Jan 20 2016, 10:06 PM
Anomie claimed this task.
Anomie changed the visibility from "Custom Policy" to "Public (No Login Required)".
Anomie changed the edit policy from "Custom Policy" to "All Users".
Restricted Application changed the visibility from "Public (No Login Required)" to "Custom Policy". · View Herald TranscriptJan 20 2016, 10:06 PM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript
Restricted Application added a subscriber: Luke081515. · View Herald Transcript
Anomie changed the visibility from "Custom Policy" to "Public (No Login Required)".Jan 20 2016, 10:07 PM
Anomie changed the edit policy from "Custom Policy" to "All Users".
Anomie changed Security from Software security bug to None.

Fixed with https://gerrit.wikimedia.org/r/#/c/265400/ and deployed.

For the record, the problem was that OAuth's auto-detected flag to tell it to look up central IDs wasn't getting auto-detected before SessionManager tried to load the session, so it was using the user with local ID matching central ID stored in the OAuth authorization. The fix was to do the auto-detecting earlier.

Restarted WiDaR webservice. Trying to reproduce the issue by reloading quick_statements. So far, only correct logins. Trying two different user accounts with different browsers from the same machine in case of IP issue, but works fine so far.

FYI, it was working there probably because group 1 wikis (which include wikidata) were rolled back to wmf.10 at 21:32 UTC.

jayvdb added a subscriber: jayvdb.Jan 21 2016, 2:14 PM
Restricted Application added a subscriber: Malyacko. · View Herald TranscriptJun 27 2016, 8:28 PM