Archives


Master Symfony2 fundamentals

Be trained by SensioLabs experts (2 to 6 day sessions -- French or English).
trainings.sensiolabs.com

Discover the SensioLabs Support

Access to the SensioLabs Competency Center for an exclusive and tailor-made support on Symfony
sensiolabs.com

Fabien Potencier
Security Release: symfony 1.4.18 released
by Fabien Potencier – May 30, 2012 – 3 comments

symfony 1.4.18 has just been released. Read the post carefully as this version fixes a security vulnerability.

Dmitri Groutso contacted us a couple of days ago about a possible security issue in the session code:

"The regenerate() method as implemented by database backed session classes do not persist the current session data from request memory before regenerating session ID, leaving shadow copy in the database as it was at the beginning of the request (still authenticated in the "logout" case). Passing to $destroy=true to regenerate mitigates the attack, by explicitly removing shadow copy."

His patch has been applied in the 1.4.18 release.

Here are all the changes from the CHANGELOG:

  • [33466] fixed a possible DB session fixation attack (patch from Dmitri Groutso)
  • [33373] fixed test browser click function does not handle css selector without [ or ] (closes #9982, patch from mouette)

If you've checked out a copy of the tag from Subversion you can switch to the latest version:

$ svn switch http://svn.symfony-project.com/tags/RELEASE_1_4_18

If you are using the PEAR package you can update using the pear command:

$ pear upgrade symfony/symfony-1.4.18

And as always, don't forget to clear your cache after upgrading.

Comments RSS

  • Kousuke Ebihara
    #1 Kousuke Ebihara said on the 2012/05/30 at 14:59
    I've read this entry. But, sorry, I can't understand about this security issue.

    I've confirmed an issue that some session storage classes don't remove old session data in logout cases. I think this issue will be fixed this patch.

    But, your commit message says "session fixation". My said is about mitigation of session hijacking attack.

    If this issue is categorized as "session fixation", I think the reporter's saying should be "The regenerate() method ... DO persist the current session data ... before regenerating session ID".

    I want to know about more examples of effect by this vulnerability (?) to understand this problem certainly.
  • Jan G.
    #2 Jan G. said on the 2012/06/04 at 14:17
    But the problem with mysql 5.5 not understanding “Type=InnoDB” still exists. I had to change line 156 in
    symfony-1.4/lib/plugins/sfPropelPlugin/lib/vendor/propel-generator/classes/propel/engine/builder/sql/mysql/MysqlDDLBuilder.php to
    $script .= "Engine=$mysqlTableType";
    manually.
  • Jacob Thomason
    #3 Jacob Thomason said on the 2012/06/04 at 21:54
    So, I've tried searching everywhere and asking asking on the IRC as well, but I've tried the pear upgrade on a git checkout version of a sf project and I'm getting back the "upgrade ok". However, symfony -V doesn't show the new version. The download of the new version was correct with pear as well. I've also cleared the cache.

    Any ideas here?

    I guess I could try and run a diff, but I'd much prefer to avoid this scenario. Cheers!