Last modified: 2012-01-20 16:37:21 UTC
Created attachment 9384 [details] Patch to hide page title on private wikis when curid parameter is passed On private MediaWiki installations, page title are exposed to the user (e.g. in the URL in the tab) when curid parameter is passed to index.php. It allows people to make a list of pages in wiki by making bacth requests.
oldid appears to allow a similar data-exposure attack; you'd have to iterate through more things but you could get a basic list of page titles along with the page & revision id numbers.
Under review with IAlex.
Created attachment 9399 [details] unconditionally show a badtitle and fix returnto links pointing to badtitle patch made with iAlex on IRC
Looks straightforward enough. Pinging Sam to see if we can get this into 1.18.
I am not sure what is the release process for security bugs :-( At the very minimal it needs to be reviewed and deployed live first. Might need a backport in 1.17 too and immediate release of 1.17.X.
Created attachment 9417 [details] stop exposing title and bump MW to version 1.17.1 patch against REL1_17: - does not update the returnto links - bump wgVersion to 1.17.1 - update RELEASE-NOTES
The RELEASE-NOTES entry is in the wrong section, it should be in "Changes since 1.17.0".
Tim is working on a security release now around this bug. We'll probably hold 1.18.0 final for this fix.
I applied the patch to trunk, and found that there were still two instances of the actual title in the page. I haven't tested the branches, but on the face of it, it seems to be insufficient. Maybe we should just do a redirect.
We can surely redirect the user to Special:Userlogin. The problem is that we will then loose all the various error messages logic which is handled in output page and just show a login page with no error message.
Created attachment 9530 [details] (trunk) hide Title in returnto when it is unknown to the user
I could not find any instances of the real title despite Tim said so. I tried using ?oldid=## and ?curid=## and the title never show up :-(
+ $this->context->setTitle( SpecialPage::getTitleFor( 'Badtitle' ) ); This only affects things that actually use RequestContext, you didn't set $wgTitle. I had an extension enabled which uses $wgTitle in a head script.
Created attachment 9539 [details] (trunk) hide Title in returnto and set wgTitle when it is unknown to the user and now setting wgTitle
Created attachment 9540 [details] (REL1_17) hides Title and wgTitle exposures. Bump MW to1.17.1 Patch for trunk applied to REL1_17
Created attachment 9542 [details] Updated patch for trunk Changes from Hashar's patch: * Rewrote the comments * The logic and comment in OutputPage.php didn't really make sense given that $this->getTitle() now returns Special:Badtitle for a private request, it doesn't return a private page title. Instead, unconditionally get the page title from the title parameter in the request. * Use Title::newFromURL() when processing the title parameter, for consistency with Wiki.php. * In SkinTemplate, fixed the returnto parameter in the login link, using similar code to OutputPage. It was pointing to Special:Badtitle. Still needs refactoring in a non-security commit, since the code is duplicated and $wgSecureLogin is (and was always) broken in OutputPage. * If there was no title in the WebRequest, don't send returntoquery without returnto. This is more consistent since nothing else in the chain supports returntoquery without returnto (LoginForm::successfulLogin(), OutputPage::returnToMain()).
Fixed in trunk with r104505, 1.17 in r104506, 1.18 in r104508 and 1.18wmf1 in r104509
For the record: does NOT affect 1.15, and the backported patch (in Debian’s package) does acutal harm. In 1.15 there is no information disclosure wrt. whether a page exists in this case.
1.15 is definitively affected by this, but it is not supported anymore, so the patch wasn't backported by us. What you are reporting concerns Debian’s package that we don't manage. Please contact the reponsible for that package, we can't do anything about this.
