Hi all, I''m working on updated phpmyadmin packages to fix all issues currently open in the tracker. I''m a bit short on time due to personal circumstances and I need to check one fix better to make sure it''s actually correct, so it will take a few more days. Meanwhile, I can report that these issues can be updated: - CVE-2007-1325 is a workaround for PHP issue CVE-2006-1549. That issue has been fixed in PHP already, or would need to be fixed there. It''s not an issue for phpmyadmin specifically, and should be regarded as not relevant for us. - CVE-2007-1395 is marked as vulnerable in all versions, while sid and lenny have already been fixed. thanks, Thijs
* Thijs Kinkhorst:> - CVE-2007-1325 is a workaround for PHP issue CVE-2006-1549. That issue has > been fixed in PHP already, or would need to be fixed there. It''s not an issue > for phpmyadmin specifically, and should be regarded as not relevant for us.Thanks for the explanation.> - CVE-2007-1395 is marked as vulnerable in all versions, while sid and lenny > have already been fixed.Can you provide the version number of the fix?
On Tue, May 8, 2007 18:33, Florian Weimer wrote:>> - CVE-2007-1395 is marked as vulnerable in all versions, while sid and >> lenny have already been fixed. > > Can you provide the version number of the fix?4:2.10.0.2-1 Thijs
On Tue, May 08, 2007 at 06:33:40PM +0200, Florian Weimer wrote:> * Thijs Kinkhorst: > > > - CVE-2007-1325 is a workaround for PHP issue CVE-2006-1549. That issue has > > been fixed in PHP already, or would need to be fixed there. It''s not an issue > > for phpmyadmin specifically, and should be regarded as not relevant for us. > > Thanks for the explanation.Hmm, I not sure about this. The issue at hand seems like a generic design issue in PHP that''s unlikely to be ever fixed inside the interpreter. I would assume that limits to recursion depth would beed to be imposed application-specific instead. What''s the outlined attack here? A database administrator being able to DoS the webserver instance serving his phpmyadmin instance or being able to mess up the MySQL database itself? If it''s the former it appears harmless anyway. Cheers, Moritz
On Wednesday 9 May 2007 00:12, you wrote:> Hmm, I not sure about this. The issue at hand seems like a generic design > issue in PHP that''s unlikely to be ever fixed inside the interpreter. I > would assume that limits to recursion depth would beed to be imposed > application-specific instead.It''s a MOPB-found bug in PHP which have already been fixed inside the interpreter, and in fact, it has been fixed specifically in a security upload to etch: http://security-tracker.debian.net/tracker/CVE-2006-1549 Only sarge is still "vulnerable". http://www.php-security.org/MOPB/MOPB-02-2007.html> What''s the outlined attack here? A database administrator being able to DoS > the webserver instance serving his phpmyadmin instance or being able to > mess up the MySQL database itself? If it''s the former it appears harmless > anyway.It''s in any case a mild issue, but something that should be fixed when you have the chance. Especially in mass-hosting environments where lots of accounts are handed out, it would at least be inconvenient if someone could very easily DoS the webserver. And it''s not trivial to find out who did it. Thijs
On Wed, May 09, 2007 at 12:16:44PM +0200, Thijs Kinkhorst wrote:> On Wednesday 9 May 2007 00:12, you wrote: > > Hmm, I not sure about this. The issue at hand seems like a generic design > > issue in PHP that''s unlikely to be ever fixed inside the interpreter. I > > would assume that limits to recursion depth would beed to be imposed > > application-specific instead. > > It''s a MOPB-found bug in PHP which have already been fixed inside the > interpreter, and in fact, it has been fixed specifically in a security upload > to etch: http://security-tracker.debian.net/tracker/CVE-2006-1549 > Only sarge is still "vulnerable". > http://www.php-security.org/MOPB/MOPB-02-2007.htmlThis tracker data is likely wrong. If it should have really fixed in this NMU: "php5 (5.1.4-0.1) unstable; urgency=high" it most probably got lost afterwards. Stefan Esser specifically mentions it as present in all versions in above MOPB URL and has added a note: "Update: The description in CVE-2006-1549 is misleading. It reads as if the bugs were fixed in PHP 4.4.3 and PHP 5.2.0, which is not the case." Cheers, Moritz
On Monday 14 May 2007, Moritz Muehlenhoff wrote:> > http://www.php-security.org/MOPB/MOPB-02-2007.html > > This tracker data is likely wrong. > > If it should have really fixed in this NMU: > "php5 (5.1.4-0.1) unstable; urgency=high" > it most probably got lost afterwards. Stefan Esser specifically > mentions it as present in all versions in above MOPB URL and has > added a note: "Update: The description in CVE-2006-1549 is > misleading. It reads as if the bugs were fixed in PHP 4.4.3 and PHP > 5.2.0, which is not the case."The changelog claims that it has been fixed by a new upstream version, so it is still unfixed. So it probably should be fixed in the applications. Cheers, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070515/7b6fccf6/attachment.pgp