Page MenuHomePhabricator

PHP warnings on bad session_id cookie input with error_reporting(E_ALL)
Closed, DeclinedPublic

Description

Author: nickpj

Description:

This CURL command:

curl --silent --include \
--cookie 'wikidb_session=../../../../../../../etc/passwd ; select user_name
from user;'\
-F 'wpName'='XXX'\
-F 'wpPassword'='YYY'\

'192.168.0.64/wiki/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto=small'

(Or like this for the Wikipedia, where errors are being logged so there won't be

anything in the HTML output):

curl --silent --include \
--cookie 'enwiki_session=../../../../../../../etc/passwd ; select user_name
from user;'\
-F 'wpName'='XXX'\
-F 'wpPassword'='YYY'\

'en.wikipedia.org/w/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto=small'

Gives output that includes these PHP warnings at the end (on a current SVN wiki

with E_ALL enabled):

<br />
<b>Warning</b>: Unknown: The session id contains illegal characters, valid
characters are a-z, A-Z, 0-9 and '-,' in <b>Unknown</b> on line <b>0</b><br />
<br />
<b>Warning</b>: Unknown: Failed to write session data (files). Please verify
that the current setting of session.save_path is correct (/var/lib/php5) in

<b>Unknown</b> on line <b>0</b><br />

Online at http://nickj.org/MediaWiki as Parser51, althought actually a more
accurate name would be non-parser51 ;-) Not sure if this can be fixed, but
probably best to log it anyway.


Version: 1.7.x
Severity: minor
Platform: PC

Details

Reference
bz6538

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:17 PM
bzimport set Reference to bz6538.
bzimport added a subscriber: Unknown Object (MLST).

nickpj wrote:

I think this _may_ be fixed upstream in PHP by
http://bugs.php.net/bug.php?id=38224 ; However I don't have PHP >= 5.1.5
installed to run this test against a wiki with E_ALL enabled, so can't be sure.

Haven't had any luck with the curl test here; lighttpd returns a 417
error.

nickpj wrote:

Bugzilla ate some of the whitespace in the original test (specifically the
spaces at the start of each line), maybe that stuffed it up?

Here's the test with the whitespace hopefully okay. This was run against Apache,
with PHP 5.1.2, and on a wiki where the cookie prefix is "wikidb", and where all
E_ALL warnings are enabled :

curl --silent --include --globoff \
--cookie 'wikidb_session=&#124;90928345' \
-F 'wpName'='nickj' \
-F 'wpPassword'='&#0000060' \
-F 'wpRemember'='XXX' \

'localhost/wiki/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto='

For me returns this output:

HTTP/1.1 200 OK
Date: Wed, 04 Oct 2006 00:09:16 GMT
Server: Apache
Set-Cookie: wikidb_session=&#124; path=/
Content-language: en
Vary: Accept-Encoding,User-Agent
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

<!DOCTYPE html PUBLIC "-W3CDTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

[ ... snip page content ... ]

</div>
<!-- Served by bling in 0.211 secs. --></body></html>
<br />
<b>Warning</b>: Unknown: The session id contains illegal characters, valid
characters are a-z, A-Z, 0-9 and '-,' in <b>Unknown</b> on line <b>0</b><br />
<br />
<b>Warning</b>: Unknown: Failed to write session data (files). Please verify
that the current setting of session.save_path is correct (/var/lib/php5) in

<b>Unknown</b> on line <b>0</b><br />

Equivalent for the Wikipedia if you want to tail -f the apache error log and the

see if it barfs there:

curl --silent --include --globoff \
--cookie 'enwiki_session=&#124;90928345' \
-F 'wpName'='XXX' \
-F 'wpPassword'='YYY' \
-F 'wpRemember'='XXX' \

'en.wikipedia.org/w/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto='

However if neither of those tests works for you then it's probably just
something specific to my system, and this bug should be closed as WORKSFORME.

I haven't been able to reproduce it either with 5.2.0RC4 or 5.1.2 under Apache.
Still get the 417 responses under lighty.

Going to go ahead and WORKSFORME it since the issue's allegedly fixed upstream.