Re: wheezy still missing php5-suhosin
On Thu, Apr 11, 2013 at 09:11:27AM +0100, Joe wrote: > 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 What does "optional variable discipline" mean? > 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. I think that would be the case whether the code was perl also, but I've only heard bad things about PHP and good things about Perl. Does PHP (without any additions) have an equivalent of perl's "use strict"? -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- 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/20130412063949.GD17459@tal
Re: wheezy still missing php5-suhosin
On Fri, 12 Apr 2013 03:56:31 +1000 Andrew McGlashan wrote: > > If data is passed via forms or via GET or POST and that data isn't > properly handled by php itself, then it may produce a buffer overrun > situation ... possibly before the data gets passed through to the > webpage code; if this can be fixed by an extension or hardening patch, > then great, if not, then we are in trouble. That would indeed be a PHP bug, and would be found quickly. Some people do little else with their lives but fling random data at public interfaces to see what sticks... > > I would like to know that everything that was providing protection via > Suhosin has been incorporated into PHP core, that would be the most > logical way to deal with the problem, rather than having 3rd party > patches and extensions. I would doubt that all of it has been. I think it was withdrawn because it became difficult to use. OK, I've just found this, which will probably answer some of your questions: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698#15 > > Actually it does appear to still be in SID: > > http://packages.debian.org/sid/php5-suhosin > > I hadn't noticed before, but the Debian packages pages show only depends and not conflicts. If you check the properties of php5-suhosin in the Sid apt system you will find it conflicts with php5-suhosin. No, I don't know why it hasn't been removed from the distribution, I just remember it being impossible to upgrade some time ago, and after leaving it for a few weeks for the dust to settle, it was still uninstallable. I should make clear that I'm not a commercial programmer of any kind, and I dabble in PHP now and then only on my home server. I'm past the 'a little knowledge' stage: I know enough about web application security to know that I don't know anything like enough to write secure code to present to the public, so I don't attempt it. My home web server is not accessible from outside other than via a certificate-secured VPN. -- 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/20130411200538.189a7...@jretrading.com
Re: wheezy still missing php5-suhosin
On 11/04/2013 6:11 PM, Joe wrote: > 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. If data is passed via forms or via GET or POST and that data isn't properly handled by php itself, then it may produce a buffer overrun situation ... possibly before the data gets passed through to the webpage code; if this can be fixed by an extension or hardening patch, then great, if not, then we are in trouble. Once data gets past php handling and into variables, it becomes the programmer's responsibility to validate the inputs and make sure that there is no data injection or other misuse issue. > 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. Okay. > 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. I would like to know that everything that was providing protection via Suhosin has been incorporated into PHP core, that would be the most logical way to deal with the problem, rather than having 3rd party patches and extensions. Actually it does appear to still be in SID: http://packages.debian.org/sid/php5-suhosin Thanks AndrewM -- 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/5166f94f.7050...@affinityvision.com.au
Re: wheezy still missing php5-suhosin
On Thu, 11 Apr 2013 15:57:03 +1000 Andrew McGlashan 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
Re: wheezy still missing php5-suhosin
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. You need to know exactly what Suhosin is protecting against, the code implementation that causes vulnerability, and then you need someone to test against that using newer PHP base. >> It's not as bad as 95% of people running Java are using older versions >> that are known to be exploitable, but there is plenty of exploitable PHP >> code -- some may remain for years on non-patched servers, but new and >> properly patched servers shouldn't be part of the problem. PHP needs >> to, upstream, make sure that programming flaws cannot be exploited and >> that is what Suhosin aims to achieve. Bad code will be there, we need >> to be protected from it one way or another. > > So... Why isn't upstream PHP being pressured to address the problem? Perhaps they have, the problem is that we just don't have the details... If PHP upstream has committed to providing the same functionality as Suhosin, and they've implemented it then we are sweet -- but right now, we just don't know. > And if they are really so bad why are so many people still using it? > > Yes I have seen a lot of really horrid php code. But I am not a heavy > user of other people's code. I am supporting one php application that > I wrote and that is it at the moment. And since I wrote it I am very > familiar with the internals of it. But it isn't representative of > "other people's code". I see messages from a Magento website, that is probably always going to be somewhat out of date don't ask me which module or where the code problems are, but I see logcheck messages quite often from Suhosin on stable servers. Cheers A. signature.asc Description: OpenPGP digital signature
Re: wheezy still missing php5-suhosin
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. > It's not as bad as 95% of people running Java are using older versions > that are known to be exploitable, but there is plenty of exploitable PHP > code -- some may remain for years on non-patched servers, but new and > properly patched servers shouldn't be part of the problem. PHP needs > to, upstream, make sure that programming flaws cannot be exploited and > that is what Suhosin aims to achieve. Bad code will be there, we need > to be protected from it one way or another. So... Why isn't upstream PHP being pressured to address the problem? And if they are really so bad why are so many people still using it? Yes I have seen a lot of really horrid php code. But I am not a heavy user of other people's code. I am supporting one php application that I wrote and that is it at the moment. And since I wrote it I am very familiar with the internals of it. But it isn't representative of "other people's code". Bob signature.asc Description: Digital signature
Re: wheezy still missing php5-suhosin
On 11/04/2013 5:40 AM, Bob Proulx wrote: > What I have read (caution unverified) is that the PHP interpreter > isn't intrinsically insecure. It only becomes that way when used with > insecure php code. Which makes sense. Any upstream interpreter > vulnerability would have a CVE number associated with it that would be > tracked. I see people calling for those reports but none are being > provided for any current vulnerabilities. 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. It's not as bad as 95% of people running Java are using older versions that are known to be exploitable, but there is plenty of exploitable PHP code -- some may remain for years on non-patched servers, but new and properly patched servers shouldn't be part of the problem. PHP needs to, upstream, make sure that programming flaws cannot be exploited and that is what Suhosin aims to achieve. Bad code will be there, we need to be protected from it one way or another. Cheers A. signature.asc Description: OpenPGP digital signature
Re: wheezy still missing php5-suhosin
Andrew McGlashan wrote: > To cut a long story short, if PHP upstream has incorporated the features > of Suhosin, then we should be fine; is it the final conclusion from that > long thread and all the references from it, that we are in good shape > with 5.4.4 -- better than pre 5.4 with Suhosin? To be honest I have not read through all of that information myself yet in enough detail to know one way or the other. It really needs the skills of an upstream interpreter developer to know. I would love to hear from someone who is familiar with the code well enough to make an intelligent summary. What I have read (caution unverified) is that the PHP interpreter isn't intrinsically insecure. It only becomes that way when used with insecure php code. Which makes sense. Any upstream interpreter vulnerability would have a CVE number associated with it that would be tracked. I see people calling for those reports but none are being provided for any current vulnerabilities. Bob signature.asc Description: Digital signature
Re: wheezy still missing php5-suhosin
Hi Bob, On 11/04/2013 3:26 AM, Bob Proulx wrote: > Andrew McGlashan wrote: >> Now, php5-suhosin provides some real protection against programming >> problems that could very easily exist and it is not uncommon to see >> messages from Debian stable installs reporting bugs / vulnerabilities >> detected by suhosin > > The question isn't whether the suhosin patch did good with older PHP > versions. The question is whether newer PHP versions benefit as much > from it. Because in recent years AIUI many of the features of suhosin > were merged into the mainline PHP. And supporting suhosin isn't easy. > At least some other distros have also stopped supporting it too. I understand that Ubuntu have 12.10 locked in on 5.3.9 because of lack of Suhosin patch / support. Don't know what later Ubuntu will be doing. >> Will php5-suhosin be re-instated any time soon? And if not, what >> measures can we take to protect Wheezy servers now? > > Here is a good place to read up on the current state of PHP plus > suhosin in Debian. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698 > > It is a long thread with a lot of references to research. Grab a > comfortable chair and a stimulating beverage. Great, thank you very much for your post and the reference. To cut a long story short, if PHP upstream has incorporated the features of Suhosin, then we should be fine; is it the final conclusion from that long thread and all the references from it, that we are in good shape with 5.4.4 -- better than pre 5.4 with Suhosin? Thanks. AndrewM signature.asc Description: OpenPGP digital signature
Re: wheezy still missing php5-suhosin
Andrew McGlashan wrote: > Now, php5-suhosin provides some real protection against programming > problems that could very easily exist and it is not uncommon to see > messages from Debian stable installs reporting bugs / vulnerabilities > detected by suhosin The question isn't whether the suhosin patch did good with older PHP versions. The question is whether newer PHP versions benefit as much from it. Because in recent years AIUI many of the features of suhosin were merged into the mainline PHP. And supporting suhosin isn't easy. At least some other distros have also stopped supporting it too. > Will php5-suhosin be re-instated any time soon? And if not, what > measures can we take to protect Wheezy servers now? Here is a good place to read up on the current state of PHP plus suhosin in Debian. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698 It is a long thread with a lot of references to research. Grab a comfortable chair and a stimulating beverage. Bob signature.asc Description: Digital signature
Re: wheezy still missing php5-suhosin
On Wed, Apr 10, 2013 at 01:54:43PM +0200, "Morel Bérenger" wrote: > Le Mer 10 avril 2013 12:36, Andrew McGlashan a écrit : > > Will php5-suhosin be re-instated any time soon? > > I have no clue about what instated means :) https://en.wiktionary.org/wiki/reinstate signature.asc Description: Digital signature
Re: wheezy still missing php5-suhosin
Le Mer 10 avril 2013 12:36, Andrew McGlashan a écrit : > Will php5-suhosin be re-instated any time soon? I have no clue about what instated means :) > And if not, what > measures can we take to protect Wheezy servers now? Maybe you can reuse the old package. Check the dependencies, it is possible that there has been no changes in them. If there has been, take a look to applications' changelogs, to see if the new versions are compatible with the existing dependencies. As you might know, there is a more or less standard versioning scheme named semantic versioning (it is quite easy to understand even for a non-native english user like me. You can find it's description here: http://semver.org/). If dependencies uses it, you will be able to check compatibility quite quickly: if major number did not changed, then you are fine. Of course, since you are willing to use this tool on a production server, I strongly encourage you to take a look into changelogs and/or ask to their developers to ensure nothing should be broken. -- 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/1c745219c5708a1fbe6875efe44ab43f.squir...@www.sud-ouest.org
wheezy still missing php5-suhosin
Hi, I'm working on a server replacement, the old (current) server is running latest stable release and the new server is running from this downloaded installer ISO: debian-wheezy-DI-rc1-amd64-netinst.iso Now, php5-suhosin provides some real protection against programming problems that could very easily exist and it is not uncommon to see messages from Debian stable installs reporting bugs / vulnerabilities detected by suhosin It seems to me that this is an essential package for most servers running PHP5 and it's non-availability is a very serious concern. I've found the following: http://packages.qa.debian.org/p/php-suhosin/news/20120320T163911Z.html Will php5-suhosin be re-instated any time soon? And if not, what measures can we take to protect Wheezy servers now? Thanks AndrewM -- 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/5165409b.9000...@affinityvision.com.au
