On Thu, 11 Apr 2013 15:57:03 +1000 Andrew McGlashan <andrew.mcglas...@affinityvision.com.au> wrote:
> On 11/04/2013 3:21 PM, Bob Proulx wrote: > > Andrew McGlashan wrote: > >> Yes, but insecure code is so easy to make and even the so called > >> experts are making them. There is even an O'Reilly book that has > >> wrong information that is leading programmers astray. The > >> protections provided by Suhosin in the past may _always_ be > >> required and necessary. > > > > This is all so nebulous and vague. Is there an example that could > > be cited of a case that the suhosin patch will protect against in > > the php 5.4.4 interpreter? Even one example would really help > > drive the point home. > > I wish I could give you an example, but I can't. > A working commercial PHP programmer probably could, but I'm not sure it would help. PHP is a programming language, running on a web server, which needs to access the server's databases, drives, memory etc. There's no way it can be made secure, any more than C++ could be redesigned to prevent programmers making off-by-one errors, for example. The sword either has two edges or none. Early PHP implementations had insecure features for lazy programmers, for example allowing HTTP form parameters to be used directly as variables in programs, rather than obtaining their values and checking them before storing the checked and interpreted values in program variables. Because so much software uses this very dangerous 'feature', it must be retained, but it is normally disabled by default. Suhosin, among many other things, will warn about this feature being enabled, or turn it off if so configured. Later and later versions of PHP have become much stricter in many ways, and have offered features like Perl's optional variable discipline, so many of the Suhosin features are no longer required. Not only that, but Suhosin will warn about things which are now (mostly) safe to do. It's not so much that PHP itself is a problem, but that PHP software on public web servers is completely exposed to any and every kind of attack, and that programmers need to be extremely disciplined to write secure code. You can assist with this kind of discipline in writing a programming language, but you can't enforce it. If the group of PHP programmers for a particular web server were to read the Suhosin specification, and write all their code so as not to activate any of its protections, then that in itelf would help enormously in securing the server. Having Suhosin actually installed will also catch their mistakes. But as stated, Suhosin has not been well maintained and many of its features have become subsumed into PHP itself or have become actively irritating or obstructive, so currently in Wheezy it is seen as more of a liability than an asset. It was dropped from Sid long ago, of course, before Wheezy had frozen, but then you wouldn't run a public web server on Sid. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130411091127.3d17e...@jretrading.com
