Project

General

Profile

Actions

Bug #29274

closed

Regression on session handling for security fix

Added by Ernesto Baschny over 12 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
Frontend
Target version:
Start date:
2011-08-26
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

After upgrading from 4.3.11 to 4.3.12, an embedded application (run as a TYPO3 extension) did not work anymore. After some research, I discovered it was due to the change introduced in #24456, which moved the call of "session_start()" from a place where it was only called on demand (when doing a challenge/response login) to a place where it is always being called (even on the frontend).

Two issues with this changes:

1) My embedded application for a misfortune also does a session_start. But it also includes lots of Objects into this session. The classes for this objects are loaded by the application before calling session_start(), so PHP can build the objects just fine.

But now when TYPO3 calls a session_start on every hit and very early: the classes of my applications are not loaded yet! Thus the session is filled with "__PHP_Incomplete_Class" objects! The application no longer works.

2) Another issue which happened after this change is that several customer sites began running over quota, simply because every FE hit (even from Google & Co) created new PHP session (files in phptmp). This was not so before and will cause annoyances for bigger sites, which are tuned for fast FE rendering explicitly without Cookies / Sessions.

In my situation the result is worse than the "security gain" obtained by this change. So please consider either reverting it again (also in 4.4 and 4.5) or apply it somewhere else.


Files

session-fix.diff (653 Bytes) session-fix.diff Helmut Hummel, 2011-08-31 23:13

Related issues 6 (0 open6 closed)

Related to TYPO3 Core - Bug #24456: Information disclosure during backend loginClosed2011-01-03

Actions
Related to TYPO3 Core - Bug #28900: All links have Parameter PHPSESSID at first load of website URLClosedManfred Langhammer2011-08-10

Actions
Related to TYPO3 Core - Feature #29750: Pre-Session Hook in t3lib_userauthRejected2011-09-13

Actions
Related to TYPO3 Core - Bug #28694: PHP Warning: session_start()Closed2011-08-03

Actions
Related to TYPO3 Core - Bug #29927: Remove occurences of session_start()Closed2011-09-17

Actions
Has duplicate TYPO3 Core - Bug #28948: Session is always startedClosed2011-08-12

Actions
Actions #1

Updated by Ingmar Schlecht over 12 years ago

  • Assignee set to Helmut Hummel
Actions #2

Updated by Ingmar Schlecht over 12 years ago

  • Status changed from New to Accepted
Actions #3

Updated by Helmut Hummel over 12 years ago

Please try the attached patch.

Actions #4

Updated by Frederic Gaus over 12 years ago

The Patch is working for me.

This solves the following error in conjunction with TypoGento:
Fatal error: Mage_Core_Model_Session_Abstract::getMessages() [<a href='mage-core-model-session-abstract.getmessages'>mage-core-model-session-abstract.getmessages</a>]: The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "Mage_Core_Model_Message_Collection" of the object you are trying to operate on was loaded before unserialize() gets called or provide a __autoload() function to load the class definition in XXX on line 215

Actions #5

Updated by Roland Hager over 12 years ago

We updated to 4.4.10 yesterday and run into exactly that issue. I would even consider it a severe vulnerability to a DoS attack. Since the network filesystem we are using for our multi server environment has a hard limit for the maximum number of files per directory our site was getting real slow after about two hours running the new version. A BE/FE-Login was not possible any more, because no new sessions could be made due to a filled up session directory.

It should be quite easy to generate loads of sessions on the serverside and depending on the filesystem used by the server causing issues related to quota or filesystemlimits. This way an attacker can prevent normal users from logging in to the BE and/or FE.

The good news: The provided patch seems to do the trick. No null-byte sessions per hit and the login still works -Thanks!

Actions #6

Updated by Christian Opitz over 12 years ago

I wrote an extension that is a middleware between Zend Framework and TYPO3 - since the call to session_start mentioned above, a later call to Zend_Session::start() rightly leads to this exception:

session has already been started by session.auto-start or session_start()

Zend_Session_Exception thrown in file
[...]Zend/Session.php in line 462.

The patch makes that this exception is not thrown when nobody is logged in but when someone is trying to log in it's there again. Could you pleeaase wrap the call to session_start() in a protected function so that it's possible to override it from a XCLASS? I provide a patch if you like...

Actions #7

Updated by Helmut Hummel over 12 years ago

The problem with the information disclosure was, that if a valid user was found the session_start() (which also sends headers) was called before noCacheHeaders are sent, while in all other situations (invalid username) session_start() is called after noCacheHeaders are sent.

In the initial approach (#24456) we made sure that the order was always the same by starting the session always before sending the noCacheHeaders.

As this obviously caused a lot of problems I now suggest to do it the other way around and send the noCacheHeaders in any case before we may start a session.

Actions #8

Updated by Mr. Hudson over 12 years ago

Patch set 1 of change I87226a21d9b1955773ceb3c377fa1b4c9938e6b2 has been pushed to the review server.
It is available at http://review.typo3.org/5007

Actions #9

Updated by Anonymous over 12 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100
Actions #10

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF