A few days ago, Stefan Esser discovered a buffer overflow in the “transparent cookie encryption stack” of the Suhosin extension. Here is the full advisory.
If you previously installed the php5-suhosin package, you should upgrade to its fixed new version (0.9.33) by running :
apt-get update apt-get install --reinstall php5-suhosin
17 replies on “Advisory : buffer overflow in php5-suhosin”
for those who use aptitude it’s
aptitude reinstall php5-suhosin
apt-get has now asked whether I want suhosin.ini to be rewritten. Thank you for the change and the suhosin update Guillaume, you’re the best.
I’ve never installed php5-suhosin as a standalone package, I always installed/upgraded your dotdeb package. Should I update php5-suhosin as well ? BTW my phpinfo() says “This server is protected with the Suhosin Patch 0.9.10”.
@M : there’s no need for you to install php5-suhosin (the *extension*) if you don’t use its functions.
On the other side, the suhosin *patch* that is bundled with Dotdeb’s PHP packages, is not vulnerable to any buffer overflow. No need to upgrade anything.
tnx for the info. I’ve a little problem: I run ‘apt-get install –reinstall php5-suhosin’ before asking you and now I run ‘apt-get remove php5-suhosin’ and now I have ‘PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20090626+lfs/suhosin.so’ – /usr/lib/php5/20090626+lfs/suhosin.so: cannot open shared object file: No such file or directory in Unknown on line 0
‘ . Can you help me ?
@M : you should have summoned “apt-get remove –purge php5-suhosin” to remove Suhosin’s loading/configuration file.
Then, remove it manually : /etc/php5/conf.d/suhosin.ini
Be also sure to remove its symlinks in /etc/php5/*/conf.d/suhosin.ini
ok removed /etc/php5/conf.d/suhosin.ini
but how to remove its symlinks in /etc/php5/*/conf.d/suhosin.ini ?
@M : rm -i /etc/php5/*/conf.d/suhosin.ini
I get ‘rm: cannot remove `/etc/php5/*/conf.d/suhosin.ini’: No such file or directory
‘ . I think I’m safe now 🙂
please please do not recycle previously used version numbers!
Increment the version, e.g. in this case the old version from Fri, 13 Jan 2012 was
and the new release *should have* had version
You ask why?
Because some people use Package mirros like approx.
In our case approx had the old php5-suhosin_5.3.9-1~dotdeb.3_i386.deb cached so it delivered the cached php5-suhosin_5.3.9-1~dotdeb.3_i386.deb to all clients asking for the new one and apt-get upgrade failed with
So please reuse version numbers in the future!
@Marcel : sorry, I got your point, but reusing the version numbers was a the quickest way to fix the buffer overflow this time.
Packaging only php5-suhosin for lenny/squeeze amd64/i386 takes me about 5 minutes, while rebuilding all the php5-* packages last at least 4 hours.
I’ll do my best to avoid this in the future.
i’m not sure i understand why changeing the version number in one package means to rebuild all packages.
You recompiled the suhosin.so file which included the security fix, made a .deb package out of it and refreshed the repository metadata (Packages.gz) to reflect the right checksum and size.
So where is here the need to rebuild the whole php5-* packages if you just additionally changed the minor version number to dotdeb.4?
I can’t follow your argument here 🙂
BTW: Thanks for the service you provide! Even though i do criticise the version numbering in this case this doesn’t mean i do not value your work with all the nice packages you provide!
@Marcel : because each php5-* depends on the php5-common package with the same version number.
Now remote buffer overflow in 5.3.9 🙁
@Kevin : PHP 5.3.10 packages are coming