Your message dated Sat, 5 May 2007 19:28:12 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#421002: phpmyadmin: eval is evil.
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: phpmyadmin
Version: 4:2.9.1.1-3
Severity: wishlist
Heya,
in
phpmyadmin/libraries/Config.class.php
line 377 and 380
phpmyadmin uses eval to evaluate the contents of a
config file. There're several reasons to avoid this:
* eval is evil, especially in languages like php
* there're enough ways to read a config file without using eval
(yes, eval makes things simple - and too often pretty bad)
* it's the last web application that stops me from adding
suhosin.executor.disable_eval = On
to my php config.
Would be great if there would be a better implementation in the next
version, in favour of better security.
Thanks a lot,
Bernd
--- End Message ---
--- Begin Message ---
On Thursday 26 April 2007 10:41, Thijs Kinkhorst wrote:
> I can take this up with upstream, but I'm not yet convinced by your
> argument that it's "evil" and "insecure": can you provide a concrete
> example of a security issue with this code, and a method to include the
> configuration that would resolve it? That would help me convince upstream.
I've taken another look and read some more about eval(). I can conclude the
following: there's nothing inherently evil about the way eval() is used in
phpMyAdmin, nor is it exploitable as far as I can tell.
It is used in scripts/setup.php as a means to parse a PHP file and being able
to report on any parsing errors. This is not less secure than include()ing
the file itself, which will be done anyway. The other place is
libraries/zip.lib.php where it evaluates any of a small set of possible,
hardcoded inputs. Again, no risk there.
I consider this not a bug and am closing it. If you think there really is a
security issue, can you please point it out?
thanks,
Thijs
--- End Message ---
