AW: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
Hi Kalle, > With all this being said; there is however one option in case the vote passes > when it ends in about a weeks time. > That is for the Firebird Foundation to take over control of the extension on > PECL and work out its problems and > re-propose it to be included back into php-src once it is in a mature state > with the PHP RFC process. This means that it > still has the possibility of being included in PHP8 which currently is > looking to be released at the end of 2020. That > leaves over a year to get familiar with how the PHP project works, our > policies, community and guidelines. I think that's how we should do it. So I will have (hopefully) enough time to understand the extension development and get into the process of the PHP community. By the way: Pierre Joye mentioned to request access via a github account at https://www.php.net/git-php.php. I read the complete instruction. But I'm still unable to process successfully. I always get an error saying the answer is not correct. Surely I'm doing something wrong, but I don't know what. That's a similar problem as with the subscription form. Please consider to make it more user friendly. I am sure other people will fail as well. What are the next steps? In which area should I register as a maintainer? In the ext or PECL area? How do I do that and who is my contact person? Regards, Martin
Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers
On Wed, Apr 17, 2019 at 12:44 AM Stanislav Malyshev wrote: > Hi! > > > 2. Improve caller control on unserialization. Change the signature to > > public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and > > invoke the behavior similar to how unserialize itself works. Since all > > of this problem stems from the use of untrusted content on the phar:// > > stream, we should put into the caller's hands as much control as > possible. > > This, unfortunately, is only a partial solution. As long as > serialization format supports references - and they are likely not going > anywhere - it won't be security, it's virtually impossible to secure > code that can modify references while object is being unserialized. At > least without rewriting whole unserialization code. If somebody > undertakes this task, then yes, maybe it can be made secure (not sure > even then). For now, unserializing insecure data is insecure, regardless > of allowed_classes. Allowed_classes is just a barrier to block most > obvious attacks in the wild now, but it does not guarantee safety. > This issue had an extant report, bug # 76774 [1]. To that report, I've added some detail. I agree that $allowed_classes is a partial fix. But is it not better to incrementally add defensive layers? I'll get to the immediate mitigation after I finish my phar fuzzing work, unless somebody beats me to it. bishop [1]: https://bugs.php.net/bug.php?id=76774
Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers
Hi! > 2. Improve caller control on unserialization. Change the signature to > public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and > invoke the behavior similar to how unserialize itself works. Since all > of this problem stems from the use of untrusted content on the phar:// > stream, we should put into the caller's hands as much control as possible. This, unfortunately, is only a partial solution. As long as serialization format supports references - and they are likely not going anywhere - it won't be security, it's virtually impossible to secure code that can modify references while object is being unserialized. At least without rewriting whole unserialization code. If somebody undertakes this task, then yes, maybe it can be made secure (not sure even then). For now, unserializing insecure data is insecure, regardless of allowed_classes. Allowed_classes is just a barrier to block most obvious attacks in the wild now, but it does not guarantee safety. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers
Hi! > This issue was discussed in this list before. > As long as PHP calls unserialize for phar metadata, object injection is > possible > which may allow malicious code execution. Right. That's why I want to make it not unserialize this data unless it's explicitly being requested. > I'm not sure if Phar metadata requires object or not. > If not, Phar may use JSON. Or we may add safer unserialize that ignores > object > and reference for maximum compatibility. That would break BC with all existing phars that use metadata. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers
On Tue, Apr 16, 2019 at 10:55 PM Bishop Bettini wrote: > On Tue, Apr 16, 2019 at 6:38 AM Yasuo Ohgaki wrote: > >> On Mon, Apr 15, 2019 at 3:28 PM Stanislav Malyshev >> wrote: >> >> > Hi! >> > >> > > Thanks for responding to this issue. >> > > >> > > Will calling getMetaData still parse and >> > > execute malicious code? >> > >> > If it's contained in phar and serialized data and the surrounding code >> > (I understand that most techniques mentioned in the article rely on >> > certain vulnerable code being present) then yes. >> > >> >> This issue was discussed in this list before. >> As long as PHP calls unserialize for phar metadata, object injection is >> possible >> which may allow malicious code execution. >> >> https://github.com/php/php-src/blob/master/ext/phar/phar.c#L607 >> >> I'm not sure if Phar metadata requires object or not. >> If not, Phar may use JSON. Or we may add safer unserialize that ignores >> object >> and reference for maximum compatibility. >> >> Something has to be done, since we wouldn't fix memory issue(s) in >> unserialization. >> > > Phar itself does not require object metadata, but users may have objects > in their phars' metadata. Using the argument from BC, we can't remove > object support. That said, I'd suggest we go about this in two phases: > > 1. Immediate mitigation. Invoke phar_parse_metadata only when explicitly > called for, via getMetadata. I believe hasMetadata and delMetadata do not > need to unserialize to answer their functions. This is, as I understand it, > Stas' suggestion. > > 2. Improve caller control on unserialization. Change the signature to > public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and > invoke the behavior similar to how unserialize itself works. Since all of > this problem stems from the use of untrusted content on the phar:// stream, > we should put into the caller's hands as much control as possible. > > If the above is reasonable, I'll create tickets for the work and put it up > at the top of my queue (right behind finishing the phar fuzzing PR). > Sounds good to me. Currently, it seems phar unserialize metadata always by phar_parse_pharfile() https://github.com/php/php-src/blob/master/ext/phar/phar.c#L664 This behavior is not nice. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
Somebody wrote somewhere: > > > Would you agree if things are done correctly that it is in everyone's best > > interests to keep a solid and well-maintained driver for InterBase and > > Firebird in the core? No. When PHP first became widely used, distributing software was difficult, and having everything in one place made life a bit easier for both the people writing code, and users. Since then, people have invented distributed version control (like git), easily available online code repositories (like Github), and self-published software (like Composer/Packagist + NPM). These have all made it much, much easier to distribute software. I'm pretty sure one of the big goals that the PHP project should try to accomplish over the next year or two is to allow extensions to be distributed through channels similar to Composer. If/when that happens, there's a very good chance that other extensions will be moved out from core (imo) as having extensions be separate is better as it means: * extensions are not forced to have the same release schedule. * there can be natural selection in which extensions people use. * most discussions about extensions that only a very few people use won't need to be on the PHP internals list. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Required Make version
On Di, 2019-04-16 at 09:46 -0600, Levi Morrison wrote: > > I'd be happy to work help with the CMake port, as I know it a decent > bit, but I don't have enough time to champion the whole thing. > That has been done ages ago: http://svn.php.net/viewvc/php/cmake/ Back then it didn't have any uptake because it was uncommon and people don't like to change. (and maybe some technical reasons where some hidden sauce in PHP's build system allows some magic) A key factor for PHP's build system (imo) back the was that PHP's incremental build was *a lot* faster (typical development cycle: touch a single file and type "make") than CMake (while CMake+make is more correct since it also checks touched headers) nowadays we have SSDs, which makes this a bit less of an issue, and CMake supports ninja, which eventually might be faster. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
Hi Den tir. 16. apr. 2019 kl. 20.38 skrev Jason Wharton : > > Kalle, > > I am not intimately aware of the details of how things have been maintained > in the past by Lester. But, it didn't sound to me as if Lester was patching > his own build of PHP or trying to take short-cuts in a bad way. He was > pointing out that the API for InterBase and Firebird have been very stable > for a long time and that the bulk of the efforts to keep the driver going > stems more from work required on the PHP side of things. This is natural > and to be expected, as I see it. Lester has not maintained anything in the PHP project, I do not remember any patches from his side in my time within the project. Of course my memory is not perfect, no one is, the primary thing he has contributed in this debate after it was sparked by my RFC was noisy that made it hard to navigate the actual relevant discussions. As for whether the API is stable, that I cannot say, it might be, but if the extension is not actively maintained or has not been for a long time, it becomes unstable. Bug#72175 is a very good example to start understanding what I'm talking about, it spawned because no one abled (like mentioned in my RFC) was able to actually test it and work with it. We essentially ported the extension blindly, that is anything but stable, it is terrible and bad place for our millions of users that one extension is in this critical state of being unstable. To add further to this (as also pointed out in the RFC) is that it does illegal things for threaded mode of PHP (ZTS), this too is unacceptable when the extension claims to be threaded compatible. > In any case, there has been new activity this year with new people making > effort to address whatever issues need to be addressed. This is a fresh new > bud of growth, so to speak, that I would like to foster and encourage. > Please join me to also do so.H > > Whatever grievances the PHP-DEV team has with the etc/interbase driver, we > ask for an opportunity to have them enumerated so that we can assess our > capacity to address them. Keeping drivers up to date requires mutual > collaboration from both sides. There is wounds that needs to be healed combined with the lack of understanding of how the PHP project is managed that needs to be sorted as the very first. I have not gotten the impression by any of the emails I have gotten personally that leaves me with impression of this, and this thread is only a testament to this, but I do like to be wrong but it does not seem to be the case here. > So, while there are reasons to point the finger in our direction, lets get > it all out in the open. Then, lets do all we can on both sides to meet the > needs of our mutual customers in the most convenient manner possible for > them. Then I would look at PDO_Firebird as a first step, this extension can use a hand and there is still time for it to get major improvements before PHP 7.4 hits a feature freeze in the summer time this year. I think I have stated the rest of my thoughts in this email and the previous one I sent as a start. > For me, this is the bottom line. We at the Firebird Foundation are working > hard to raise revenue to fund the various objectives we see as viable. This > is an important objective for us, even if you have not seen reasons yet to > convince you of this. I'd like to keep our momentum moving forward and I > believe you could open doors and make a difference in this. Our doors are always open, however I will *not* stop the democratic vote that is currently on going when we got nothing to start building trust on, this is not the way that PHP as a project works, we have rules, guidelines and practices much like the Firebird project. While I do believe your words are honest and truthfully, I got nothing to build trust on, that trust was broken a long time ago and coming in the last moment does not help me believe that anything could happen when we have been burnt so many times in the past. I say that if there was any concrete evidence (in terms of patches) to show a willingness and to help justify the words that I would consider halting the vote, but none of that happened, leaving me with nothing to base a belief on. > Would you agree if things are done correctly that it is in everyone's best > interests to keep a solid and well-maintained driver for InterBase and > Firebird in the core? While I agree with this sentiment, I do not agree to stop the RFC because of this. I mentioned PDO_Firebird which is a PDO variant specifically for Firebird currently in the core, this extension will currently stay in php-src (as also noted in the RFC). I do not know or understand why you (you as in you as a person and as in the Firebird Foundation) seem to ignore the fact that it exists and only want to focus on ext/interbase. With all this being said; there is however one option in case the vote passes when it ends in about a weeks time. That is for the Firebird Foundation
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
On 16/04/2019 18:20, Kalle Sommer Nielsen wrote: Everytime the topic of interbase comes up, you always referer to applying fixes, yet I'm yet to see any contributions from you to actually maintain the code at php-src, am I to understand that this means you patch your own builds of PHP? Because it is not something that strengths the argument that has any merit of strengthen the argument of keeping it, quite the contrary if anything. I've never been granted access to commit my own work! But a number of overhauls of the PHP side I've contributed to and tested the work of others ... I started with fixing the problems back in 5.2.x and you will find my contributions on this mail list back then! I was asking about splitting the fbird_* commands back then but was told there was no need as there were no differences that warranted it :( Nothing much has changed in the intervening 11 years ... it's still running the same sites perfectly ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
Den tir. 16. apr. 2019 kl. 20.09 skrev Lester Caine : > The 'advantage' up to now of being in core has been that the BULK of the > code changes have been required to track changes in the PHP side of the > interface. The core SQL interface has not basically changed so up until > now it has worked fine for both Firebird and Interbase. So as long as > someone who understands the PHP side of the equation puts the same > generic changes into the driver as in other core extensions then things > carry on working ... but developments in the PHP side have become a lot > more difficult to track than when I did manage to apply fixes to the > driver code many years ago. Everytime the topic of interbase comes up, you always referer to applying fixes, yet I'm yet to see any contributions from you to actually maintain the code at php-src, am I to understand that this means you patch your own builds of PHP? Because it is not something that strengths the argument that has any merit of strengthen the argument of keeping it, quite the contrary if anything. > Moving forward there has been some substantial changes on both the > Firebird and Interbase side which today could benefit from a separation > but that is not 'essential' to continue to use the the legacy interfaces > as the vast majority of development work on the Firebird side is in > additional SQL functionality and the core way of passing that has not > changed in 25 years so there has been no reason to 'continually update' > the driver, only the wrappers around the basic driver. Which do not > impact the driver extension itself? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
On 16/04/2019 14:29, Chase Peeler wrote: Not once has the fact that an extension exists in PECL instead of core prevented me from utilizing that extension. The only thing that has ever prevented me from using an extension is when it is not maintained. I've been following this entire thread, and I have yet to see what the big deal about having the extension moved to PECL is. If anything, being in PECL gives you MORE flexibility as you aren't tied to the PHP release cycle. The 'advantage' up to now of being in core has been that the BULK of the code changes have been required to track changes in the PHP side of the interface. The core SQL interface has not basically changed so up until now it has worked fine for both Firebird and Interbase. So as long as someone who understands the PHP side of the equation puts the same generic changes into the driver as in other core extensions then things carry on working ... but developments in the PHP side have become a lot more difficult to track than when I did manage to apply fixes to the driver code many years ago. Moving forward there has been some substantial changes on both the Firebird and Interbase side which today could benefit from a separation but that is not 'essential' to continue to use the the legacy interfaces as the vast majority of development work on the Firebird side is in additional SQL functionality and the core way of passing that has not changed in 25 years so there has been no reason to 'continually update' the driver, only the wrappers around the basic driver. Which do not impact the driver extension itself? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Required Make version
If we change anything about our build system, I think it ought to be switching to CMake instead. This supports multiple backends, including generating project files for IDEs, and is designed to be portable, instead of targeting only GNU systems. This means we can use a single build system instead of one for Windows and one for everyone else. At one point, there was a Google Summer of Code project that began this work, but it never got merged and I couldn't find any discussion about why. I'd be happy to work help with the CMake port, as I know it a decent bit, but I don't have enough time to champion the whole thing. On Tue, Apr 16, 2019 at 9:40 AM Bishop Bettini wrote: > > On Sun, Apr 14, 2019 at 12:07 PM Peter Kokot wrote: > > > Hello, > > > > people familiar with the PHP *nix build system today can be probably > > counted on the fingers of two hands, so I'm hoping to get some answer > > also here. > > > > Does anyone maybe still have any insights on which Make version does > > PHP require or silently specify as a minimum? GNU make? POSIX make? > > Maybe some GNU make minimum version? 3.81? etc... > > > > Currently, there are two steps where different make can be used: > > > > 1.) ./buildconf > > (here GNU make is required because of using the conditional macro > > assignment operator ?= in build/build2.mk file) > > > > 2.) make step after ./configure > > (here POSIX make can go through more or less ok). > > > > This is seen, for example, on the Solaris systems where doing this: > > > > ./buildconf > > > > causes: > > > > make: Fatal error in reader: build/build.mk, line 22: Badly formed > > macro assignment > > > > so, this needs to be done: > > > > MAKE=gmake ./buildconf > > > > however, this works then ok: > > > > ./configure > > make > > > > Is this confirmed and ok with everyone that GNU make is the minimum > > required derivative for PHP to be used? Or should software such as PHP > > be an example and use POSIX compatible make? > > > > Reason for asking this: https://github.com/php/php-src/pull/4025 and > > similar improvements... > > > > Relying upon a single build feature set simplifies development, and GNU > make is ubiquitous. I am in favor of standardizing on GNU make. > > The fact that few people know the autotools mechanism we're using, and that > GNU make probably isn't the most performant build system for us [1], > suggests an interesting project: integrating an alternative build systems. > Like X.org attempted [2] with Meson [3]. It might not yield any fruit, but > that'd validate the system we're using. > > bishop > > [1]: http://www.conifersystems.com/whitepapers/gnu-make/ > [2]: > https://www.phoronix.com/scan.php?page=news_item&px=Xorg-Server-Meson-Fitting > [3]: https://mesonbuild.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Required Make version
On Sun, Apr 14, 2019 at 12:07 PM Peter Kokot wrote: > Hello, > > people familiar with the PHP *nix build system today can be probably > counted on the fingers of two hands, so I'm hoping to get some answer > also here. > > Does anyone maybe still have any insights on which Make version does > PHP require or silently specify as a minimum? GNU make? POSIX make? > Maybe some GNU make minimum version? 3.81? etc... > > Currently, there are two steps where different make can be used: > > 1.) ./buildconf > (here GNU make is required because of using the conditional macro > assignment operator ?= in build/build2.mk file) > > 2.) make step after ./configure > (here POSIX make can go through more or less ok). > > This is seen, for example, on the Solaris systems where doing this: > > ./buildconf > > causes: > > make: Fatal error in reader: build/build.mk, line 22: Badly formed > macro assignment > > so, this needs to be done: > > MAKE=gmake ./buildconf > > however, this works then ok: > > ./configure > make > > Is this confirmed and ok with everyone that GNU make is the minimum > required derivative for PHP to be used? Or should software such as PHP > be an example and use POSIX compatible make? > > Reason for asking this: https://github.com/php/php-src/pull/4025 and > similar improvements... > Relying upon a single build feature set simplifies development, and GNU make is ubiquitous. I am in favor of standardizing on GNU make. The fact that few people know the autotools mechanism we're using, and that GNU make probably isn't the most performant build system for us [1], suggests an interesting project: integrating an alternative build systems. Like X.org attempted [2] with Meson [3]. It might not yield any fruit, but that'd validate the system we're using. bishop [1]: http://www.conifersystems.com/whitepapers/gnu-make/ [2]: https://www.phoronix.com/scan.php?page=news_item&px=Xorg-Server-Meson-Fitting [3]: https://mesonbuild.com/
Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers
On Tue, Apr 16, 2019 at 6:38 AM Yasuo Ohgaki wrote: > On Mon, Apr 15, 2019 at 3:28 PM Stanislav Malyshev > wrote: > > > Hi! > > > > > Thanks for responding to this issue. > > > > > > Will calling getMetaData still parse and > > > execute malicious code? > > > > If it's contained in phar and serialized data and the surrounding code > > (I understand that most techniques mentioned in the article rely on > > certain vulnerable code being present) then yes. > > > > This issue was discussed in this list before. > As long as PHP calls unserialize for phar metadata, object injection is > possible > which may allow malicious code execution. > > https://github.com/php/php-src/blob/master/ext/phar/phar.c#L607 > > I'm not sure if Phar metadata requires object or not. > If not, Phar may use JSON. Or we may add safer unserialize that ignores > object > and reference for maximum compatibility. > > Something has to be done, since we wouldn't fix memory issue(s) in > unserialization. > Phar itself does not require object metadata, but users may have objects in their phars' metadata. Using the argument from BC, we can't remove object support. That said, I'd suggest we go about this in two phases: 1. Immediate mitigation. Invoke phar_parse_metadata only when explicitly called for, via getMetadata. I believe hasMetadata and delMetadata do not need to unserialize to answer their functions. This is, as I understand it, Stas' suggestion. 2. Improve caller control on unserialization. Change the signature to public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and invoke the behavior similar to how unserialize itself works. Since all of this problem stems from the use of untrusted content on the phar:// stream, we should put into the caller's hands as much control as possible. If the above is reasonable, I'll create tickets for the work and put it up at the top of my queue (right behind finishing the phar fuzzing PR). bishop
Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance
On Tue, Apr 16, 2019 at 8:12 AM Kalle Sommer Nielsen wrote: > Hi > > Discussions regarding PHP should be in the public and on the PHP > internals mailing lists, not in private so I'm forwarding this email > to its proper place. > > Den tir. 16. apr. 2019 kl. 02.40 skrev Jason Wharton : > > I would like to introduce myself as the newly elected President of the > > Firebird Foundation. One of the major motivations I had in running for > this > > office was to do all I could to increase the usability of Firebird for as > > many languages and platforms as possible. I seek to have you reconsider > > demoting our driver from the core to the PECL. > > Not once has the fact that an extension exists in PECL instead of core prevented me from utilizing that extension. The only thing that has ever prevented me from using an extension is when it is not maintained. I've been following this entire thread, and I have yet to see what the big deal about having the extension moved to PECL is. If anything, being in PECL gives you MORE flexibility as you aren't tied to the PHP release cycle. > As the original RFC author of this RFC, I will give reply with my > thoughts here inline, and while I'm a Core Developer of PHP, I cannot > speak for every single developer of the team as they are entitled to > their own opinion, so I will make it as abstract as I can; Based on > reading this email (along with the many others I have gotten after I > initially proposed the RFC), it strikes me first that the Firebird > community does not seem to understand a few things, while they have > been iterated over and over again on the mailing lists in the last > month or so, I will try my best to do so again. > > Reading your email at first gives me the impression that you may not > have read the RFC or understand it from the technical perspective as > it was presented. The ext/interbase extension was designed almost 20 > years ago, it has barely changed since then and was originally > targeting InterBase before Firebird was created. As a bonus the > extension was able to connect to Firebird as the protocol is mostly > the same, requiring very few changes to make the extension work with a > Firebird backend, which itself is great. However, the problem > mentioned in the RFC[1], and further explained in there[2] is that we > had no one to step up and maintain the extension. It was even blindly > ported to PHP7 which in terms spawned the notorious bug #72175[3], we > called out for maintainers multiple times[4][5][6] (and further > mentions of it being broken here[7][8]), I could probably dig out more > but already this list should be a red flag indicator. We had some > maintainers step up in the past to try work out the issues of this > extension, but they have either never touched it or went missing after > a while (also mentioned in the RFC[9]). > > What baffles me in this whole debate is the lack of communication from > Firebird's side. I could not find any article posted or a relevant > mailing list or similar where it shows the Firebird Foundation's > commitment into investing time into Drivers, I could however find the > article posted on your website in january[10], claiming that you have > found a maintainer for the extension, which is great, however it lacks > one major detail. No one from Firebird has been in contact with PHP in > regards to this (I cannot stress how important this one is!), there > has been no patches, bug reports or even the slightest communication. > Even the new "maintainer" was not subscribed to PHP internals. The > extension and its code is essentially owned by PHP and for a third > party organization to claim maintainership of something we distribute > in PHP without any communication sounds more like a fork to me, which > is very poor execution from Firebirds side of things. > > It was first when the proposal to move the extension out of php-src > came into the light that this was even relayed to PHP internals. I > explained to Martin (the new claimed maintainer) that I wanted to see > concrete patches before the time period of when the voting was > supposed to begin to even remotely consider holding it off and that > similar to this, I do not appreciate conversations in private, they > belong to the public, more than ever especially now. I did not see > any, or even hear any further plans for what the idea with this whole > thing was and still to this moment of writing this response, I am in > the unclear of the direction of this "development" and to prevent my > fellow team members and contributors of PHP the burden of acting like > we actively maintain something which we don't, push it forward and > into PECL. > > Moving an extension to PECL does not mean its gone for good. It means > that the extension is not maintained by the PHP Development Team in a > sense that we do not provide fixes in any capacity as apart of the > standard release cycle. PHP has a rather strict release cycle where we > generally
[PHP-DEV] Re: PHP (ext/interbase) driver maintenance
Hi Discussions regarding PHP should be in the public and on the PHP internals mailing lists, not in private so I'm forwarding this email to its proper place. Den tir. 16. apr. 2019 kl. 02.40 skrev Jason Wharton : > I would like to introduce myself as the newly elected President of the > Firebird Foundation. One of the major motivations I had in running for this > office was to do all I could to increase the usability of Firebird for as > many languages and platforms as possible. I seek to have you reconsider > demoting our driver from the core to the PECL. As the original RFC author of this RFC, I will give reply with my thoughts here inline, and while I'm a Core Developer of PHP, I cannot speak for every single developer of the team as they are entitled to their own opinion, so I will make it as abstract as I can; Based on reading this email (along with the many others I have gotten after I initially proposed the RFC), it strikes me first that the Firebird community does not seem to understand a few things, while they have been iterated over and over again on the mailing lists in the last month or so, I will try my best to do so again. Reading your email at first gives me the impression that you may not have read the RFC or understand it from the technical perspective as it was presented. The ext/interbase extension was designed almost 20 years ago, it has barely changed since then and was originally targeting InterBase before Firebird was created. As a bonus the extension was able to connect to Firebird as the protocol is mostly the same, requiring very few changes to make the extension work with a Firebird backend, which itself is great. However, the problem mentioned in the RFC[1], and further explained in there[2] is that we had no one to step up and maintain the extension. It was even blindly ported to PHP7 which in terms spawned the notorious bug #72175[3], we called out for maintainers multiple times[4][5][6] (and further mentions of it being broken here[7][8]), I could probably dig out more but already this list should be a red flag indicator. We had some maintainers step up in the past to try work out the issues of this extension, but they have either never touched it or went missing after a while (also mentioned in the RFC[9]). What baffles me in this whole debate is the lack of communication from Firebird's side. I could not find any article posted or a relevant mailing list or similar where it shows the Firebird Foundation's commitment into investing time into Drivers, I could however find the article posted on your website in january[10], claiming that you have found a maintainer for the extension, which is great, however it lacks one major detail. No one from Firebird has been in contact with PHP in regards to this (I cannot stress how important this one is!), there has been no patches, bug reports or even the slightest communication. Even the new "maintainer" was not subscribed to PHP internals. The extension and its code is essentially owned by PHP and for a third party organization to claim maintainership of something we distribute in PHP without any communication sounds more like a fork to me, which is very poor execution from Firebirds side of things. It was first when the proposal to move the extension out of php-src came into the light that this was even relayed to PHP internals. I explained to Martin (the new claimed maintainer) that I wanted to see concrete patches before the time period of when the voting was supposed to begin to even remotely consider holding it off and that similar to this, I do not appreciate conversations in private, they belong to the public, more than ever especially now. I did not see any, or even hear any further plans for what the idea with this whole thing was and still to this moment of writing this response, I am in the unclear of the direction of this "development" and to prevent my fellow team members and contributors of PHP the burden of acting like we actively maintain something which we don't, push it forward and into PECL. Moving an extension to PECL does not mean its gone for good. It means that the extension is not maintained by the PHP Development Team in a sense that we do not provide fixes in any capacity as apart of the standard release cycle. PHP has a rather strict release cycle where we generally do not add new functionality in a release branch (currently PHP-7.1, PHP-7.2, PHP-7.3), we have policies for keeping backwards compatibility and such. I'm mentioning this because an extension in PECL does not have these rules and extensions there are free to change exactly as they feel like. If the voting passes then naturally the Firebird foundation are free to claim it on PECL and essentially do anything you wish with it, it just will not be included in the php-src distribution anymore (which has less and less meaning nowadays with package managers). PECL even have Windows integration and can compile extensions in many flavors. > Whil
Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers
On Mon, Apr 15, 2019 at 3:28 PM Stanislav Malyshev wrote: > Hi! > > > Thanks for responding to this issue. > > > > Will calling getMetaData still parse and > > execute malicious code? > > If it's contained in phar and serialized data and the surrounding code > (I understand that most techniques mentioned in the article rely on > certain vulnerable code being present) then yes. > This issue was discussed in this list before. As long as PHP calls unserialize for phar metadata, object injection is possible which may allow malicious code execution. https://github.com/php/php-src/blob/master/ext/phar/phar.c#L607 I'm not sure if Phar metadata requires object or not. If not, Phar may use JSON. Or we may add safer unserialize that ignores object and reference for maximum compatibility. Something has to be done, since we wouldn't fix memory issue(s) in unserialization. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
