Re: [PHP-DEV] taint
Good morning, > ==8<-- > Taint is blacklisting. > Last time I checked marking all user input as tainted and requiring "untainting" before usage in sensitive functions is whitelisting and not blacklisting. Regards, Stefan -- SektionEins GmbHstefan.es...@sektioneins.de Breite Str. 159Tel: 0221 / 29282931 50667 Köln Fax: 0221 / 29282935 http://SektionEins.de/ Firmensitz Breite Str. 159 50667 Köln Registergericht Amtsgericht KölnHRB 59950 Geschäftsführer: Stefan Esser, Benjamin Fuhrmannek, Christian Horchert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] crypto_something
Hi, libgcrypt does at least have a maintainer but it's poor Werner Koch who is so destitute he lives on charity raised on Kickstarter and has his work cut out just trying to deal with GPG: http://is.gd/cbHCYO Wow. Just WOW. Are you jealous that thousands of people consider Werner Koch's work valuable and therefore support him building the financial ground to pay full-time maintainers for a software that millions use without even knowing (HINT: package signatures) or are you just a jerk? Unbelievable. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend_execute_internal hook missing from PHP 5
Hi,
it recently came to my attention that the function whitelist and blacklist
feature inside Suhosin is easily bypassable since PHP 5.0.
The reason for this is that PHP is no longer calling the
zend_execute_internal() hook if a function is called from another function (via
zend_call_function)
In the days of PHP 4 the code looked like this:
if (!zend_execute_internal) {
((zend_internal_function *)
EX(function_state).function)-handler(EX(opline)-extended_value,
EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, 1 TSRMLS_CC);
} else {
zend_execute_internal(execute_data, 1 TSRMLS_CC);
}
Nowadays (since PHP 5.0) the code was moved from call_user_function_ex to
zend_call_function and just looks like this:
((zend_internal_function *)
EX(function_state).function)-handler(fci-param_count, *fci-retval_ptr_ptr,
fci-retval_ptr_ptr, fci-object_ptr, 1 TSRMLS_CC);
While this has no immediate impact for average PHP users, it basically kills
the possibility for an extension like Suhosin to catch all function starts.
This should also be a problem for your DTRACE support. And IIRC Xdebug was
hooking this point (at least in the past), too.
My suggestion is to change the code to call the hook again.
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_execute_internal hook missing from PHP 5
Hi, While this has no immediate impact for average PHP users, it basically kills the possibility for an extension like Suhosin to catch all function starts. Actually, there is one, use user opcode handler hook the fcall series opcodes, that is how I did in taint extension. From what I can see your taint extension also does not catch functions called by call_user_func() or array_map() or or or… Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About CVE-2012-0831 (magic_quotes_gpc remote disable vulnerability?)
Hi, 1. In PHP 5.3.10 and before, magic_quotes_gpc is disabled even if it is enabled in php.ini. No the vulnerability allows attackers to disable activated magic_quotes_gpc with a remote exploit. 2. If my PHP scripts don't depend on magic quote feature, in this case, I don't need to apply the patch. Applications like SugarCRM also do not depend on magic_quotes_gpc. However SugarCRM before 6.4.0 contains an SQL injection vulnerability that is not exploitable in case magic_quotes_gpc is activated. But I think it is totally mistakes. I think it is evaluated as SQL Injection attack vulnerability in *PHP*, but it is not correct. magic_quotes_gpc is just a fail-safe (but of course it is tattered) and a script which depends on magic_quotes_gpc is intrinsically vulnerable. While magic_quotes_gpc is for sure not the best solution possible, it is simply not true that scripts relying on magic_quotes_gpc for SQL escaping are insecure. These scripts are simply not portable (when it comes to moving the SQL to a different database software or moving to some multi-byte character sets). There is a lot of old code on the internet that relies on magic_quotes_gpc and it uses utf8 or iso character set and is NOT vulnerable. Of course using mysql_real_escape_string() and prepared statements are more secure, but they are not always required to be secure. Regards, Stefan Esser PS: and all that old code will be vulnerable once the server admin updates to PHP 5.4 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hi, considering that I am the antichrist and eat little children it maybe is better to quote Lord Voldemort instead of Harry Potter. Don't you turn your back on me Harry Potter, I want you to look at me when I kill you, I want to see the light leave your eyes Back to serious. it is nice Reindl that you defend me, but you will not convince people like MM. And you don't have to. Suhosin is not a religion or a Harry Potter movie. If he does not trust me, then he is free to not use it. No one forces anyone to do anything. At least not from my side. Beside the fact that Suhosin is open source and he can audit it himself, or is he not qualified to do it? I explained on Twitter that I would be pretty stupid to try to hide security bugs, because there are enough people out there that would see this and use it to clown me. Regards, Stefan Am 06.02.2012 um 17:22 schrieb Reindl Harald: Am 06.02.2012 17:10, schrieb Michael Morris: On Mon, Feb 6, 2012 at 10:32 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: first: do not top-post if you get a reply below second: in the context of suhosin when mistakes get made by such a person, they are hidden away rather than honestly reported is bullshit at it's best * look at the disclosure below * look at the author * look at the way it was made if only 10% of developers would work like Stefan most software out there would be much better as it is and was all the last years and if someone has this attitude and knowledge is see no single problem and understand fully that he is frustrated ___ Author: Stefan Esser [stefan.esser[at]sektioneins.de http://sektioneins.de] Disclosure Timeline: 12. January 2012 - Vulnerability was found during an internal audit 14. January 2012 - Vulnerability was fixed in the source code 19. January 2012 - Public Disclosure This underscores my fears. Public disclosure was only made once the fix was composed seven days after discovery, and that's presuming the stated date of discovery is honest. As it is an internal audit, who knows other than Stefan? You can take his word. I won't. if you anwer to a list mail answer to the list and not private damend! would it have been better to make a full disclosure before having a fix to help attackers? if this is your opinion you are a foolsih idiot, sorry but no other words for that this does even not happen if the one found a exploit notifies the vendor of the software and especially not if the one who found IS the vendor and the one who will fix it you said when mistakes get made by such a person, they are hidden away rather than honestly reported which is NOT underscored because if it would be the truth the disclosure from Stefan would not exist and he only had released a new version with a fixed some small bugs comments and not more -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hey Nikita, Full disclosure sure is controversial, but I don't think it is regarded as necessarily bad. Just look at the way Stefan disclosed the PHP 5.3.9 remote code execution vulnerability: Full disclosure. So please, again, don't call people names. I guess you are not aware that the bug was disclosed by Stas when he commited the fix to the SVN. I never told anyone where the bug is before it was already all over the internet. So please get your facts straight. Regards, Stefam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Good morning, Well, here's the answer why Suhosin is not part of PHP. With Suhosin existing I am free to implement as many security mitigations I like and do not have to beg the PHP developers to consider adding something. Some people call begging collaboration and consider it a normal way to develop software with teams bigger than one person. Of course, being part of the team is completely voluntary. I think it is clear that Stefan is not interested The Suhosin project was started because I personally considered the state of PHP security not good enough for MY SERVERS. And while you don't like it the security history of PHP (and the fact how often a bug never even affected Suhosin patched PHP) has proven that I was right. I want to have the best possible protection on MY SERVERS. The fact that others can use Suhosin is a gift from me. I could keep the project completely to myself (or let people pay for it). But I did not. But instead of accepting the gift, people like Pierre run around and tell everybody that people only have more problems due to Suhosin, that he is happy that it gets dropped, bla bla bla. This is ironic because Pierre's employer is Microsoft (excuse me if that is not correct anymore). Microsoft created recently Suhosin for Windows. They call it EMET and they actively support it, not fight it like cancer. I see NO REASON why I should kill Suhosin and maybe 5 of 100 features/mitigations go into mainline PHP. If that happens it is not good enough for me. I want all 100 features/mitigations in MY SERVERS. A suhosin that is merged to PHP mainline will never provide the same security as an external solution. This is not good enough for me. Also PHP.net demands that I convince them to take feature A, B and F from Suhosin into PHP. I get ordered to sit down and write RFCs about these features and explain why they need to go inside. Why should I waste my time like that? I know for sure that whatever will be the outcome of it, it will be a compromise (if at all) that will not be sufficient for my personal taste. So in the end from my point of view people have to use Suhosin anyway. Why also waste time merging 5 features of 100 if I can do something more useful in the time and give my Suhosin users 20 more new mitigations. Also history has proven that sooner or later PHP.net gets bitten by some vulnerability in the ass and then they will clone one of the Suhosin features anyway. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hi Pierre, And if security features in Suhosin is so critical, I also why its users rely on one single person for that, the bus factor is quite high. everybody is free to join the Suhosin team. People rely on me because they consider me the person knowing most about PHP security. And the same people do not trust PHP.net anymore. Don't forget that the last 2 releases of PHP had to be followed by new versions because both times code was commited AFTER the last RC that introduced a security vulnerability. People do not trust you anymore. And it is a joke that you are running around telling everyone that all is perfect now with your RFC and new processes. Reality shows a different picture. BTW: rely on a single person is also funny. At SektionEins we have more than one person looking into Suhosin. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Stas, That's your opinion and you completely entitled to it and I have absolutely no issue about it. As I have no issue with your preferring to keep Suhosin as a separate project - it's your code, you decide what to do with it. What I have an issue with is understanding how, after all public invitations and discussion, you claim that we refuse to cooperate and fight you like cancer. The problem is when people like Pierre run around and tell in public that people have only more problems due to Suhosin, that he is happy that distributions kick it. He also tells everybody that he sees no need in any of the Suhosin features and is VERY VOCAL about it. Nevertheless PHP 5.3.9 introduced a vulnerability because PHP.net cloned one of those we see no need for any features features. Also Pierre runs around every time I mention that Suhosin is not bitten by a bug and accuses me of blatant advertisement or he just downplays the fact that Suhosin users were relatively save from the critical major vulnerability in PHP 5.3.9. He is actively lobbying against Suhosin and spreading FUD. That is pretty much like fighting it like cancer. Nobody demands anything from you. However, for a feature to be included in PHP it needs to go through certain process. It's not because we hate you and this process is not personal for you, Please read the email form Pierre: I see no sense in other features of Suhosin. Write some RFC to convince us to include them. And BTW you cannot play the: It is Pierre you know him card. The PHP developers are free to step up and say publicly that Pierre's view is not that of the developers. But you choose to not to do so. So you are behind him. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, This is ironic because Pierre's employer is Microsoft (excuse me if that is not correct anymore). Again you are totally wrong. I work with them not for. And can you please once in this thread (or at all) stop your kiddish personal attack and finally bring technical points to this discussion? Can you do it? Grow up Pierre. Telling people that you work for Microsoft while you only work with them is not a personal attack. The technical points are all over my emails. You just choose to ignore them and highlight every second sentence of mine as personal attack. Microsoft created recently Suhosin for Windows. They call it EMET and they actively support it, not fight it like cancer. It is a very pretentious to consider that EMET has been created from or because of Suhosin. Also some Suhosin features are per se enabled on Windows through VC options (whehter they act the same way or not is disputable but you know it). See you do it again. You claim I believe EMET has been created because of Suhosin. I never said that. Although one of the lead developers of EMET compared it himself to it. You know some features of Suhosin are already in PHP and the HTTP response splitting drama shows that when you break it there is a secondary layer of defense that protects you in case you use Suhosin. Nobody ever asked you to kill it. never. But we did kindly and friendly ask you to participate instead of doing your little crusades like these days. No, you ordered me to sit down and write RFC so that I can convince YOU. A suhosin that is merged to PHP mainline will never provide the same security as an external solution. This is not good enough for me. That's your opinion, I'm convinced of the opposite. The issue here is that you lived in the past, based on your experiences with php core years ago, php3/4 and partially 5/5.2. It is really time for you to wake up. Pierre it is time for you to come out of the delusional state. You repeatedly claim that everything is now superb. Do you forget PHP 5.3.7 and PHP 5.3.9 both times there were security vulnerabilities introduced right after the last RC. This is a sign that the PHP development process is still not healthy at all. Also PHP.net demands that I convince them to take feature A, B and F from Suhosin into PHP. It is a standard procedure that applies to any new feature. Many projects do that as well. There is no exception, even for you. No it is not a standard procedure that you order someone that does not see a need to merge features into PHP to sit down and write RFC to convince you nevertheless. And yes, I do lobby against Suhosin because I consider it causes more harms to the whole thing that what it solves. That's my rights and I do not engage php.net in my statement but only my personal opinions. And I will continue to lobby, actually not against Suhosin, but to get what PHP needs in PHP and not in some random external patches. Enough said. I also try to convince you to finally get around your personal issues with us and join our efforts. I do that every time we meet live at conferences or other events. It is also somehow amusing that you are much more polite and nice in a live discussion than through emails, let try to solve that next time we meet :-) You claim I have personal issues, while I repeatedly tell you the technical reasons why I see it different then you. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, See you do it again. You claim I believe EMET has been created because of Suhosin. I never said that. Although one of the lead developers of EMET compared it himself to it. You know some features of Suhosin are already in PHP and the HTTP response splitting drama shows that when you break it there is a secondary layer of defense that protects you in case you use Suhosin. I was talking about the compilation security options which are similar (in some extends) to what Suhosin does (for some features). Actually no. The key security iprovements in Suhosin-Patch have nothing todo with anything the compile time options of VC offer. Suhosin does not attempt to do Stack Protection, or ASLR or NX. The only thing that might be a compile time option is support for %n in format strings. I think VC or libs do not allow that anymore. The problem with PHP is that is does a lot of things like implementing their own heap manager from scratch, which is a security nightmare and something a compiler cannot protect you from. Do you forget PHP 5.3.7 and PHP 5.3.9 both times there were security vulnerabilities introduced right after the last RC. This is a sign that the PHP development process is still not healthy at all. So any software having security issues at one point or another is not healthy? Again. We are not talking about software having security issues. We are talking about software with 4,5 or whatever number of release candidates. And then the security vulnerability is caused by an unreviewed commit to the code after the last release candidate and before final. This is bad. And there is no point arguing this fact. I consider the opposite, I am very careful when I see a software without any discovered issues for a long time, a sign of lack of activities and users. Of course it might mean exactly this. But it could also mean that the software simply works and does not have major problems. You claim I have personal issues, while I repeatedly tell you the technical reasons why I see it different then you. Sorry but I do not see technical issues in this thread, as in technical explanations about why one given feature is actually a good thing. I did not see any either in the past discussions. I repeatedly tell you that a second layer of defense outside of the main product is a good thing. You disagree. However defense in depth is widely accepted as the way to go. Also having canaries in memory managers, while using more memory is a known valid mitigation against buffer overflows. You can look it up on the internet. Having pointer obfuscation is also a mitigation you see in glibc and Microsoft (even in Internet Explorer). Whitelisting of destructors is a mitigation based on whitelisting. These are all basic prinicples of security mitigations. Why is there a need to write up RFC about these things. They are widely accepted by other software vendors/products. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hi, This is bad. And there is no point arguing this fact. Yes, this was bad. Agreed. It was a mistake. Mistakes happen. We fixed it and hopefully learned from it. Yes mistakes do happen to everyone and we all hope to learn from them. And some of us like to buy insurances so that there is protection in case anything goes wrong. And because we know that everyone makes mistakes we add additional layers of protection. In case of PHP this is Suhosin. In case of Apache this is mod_security. In case of Linux it is better Grsecurity (and not the other stuff). And in case of webservers in general people buy web application firewalls. These are all basic prinicples of security mitigations. Why is there a need to write up RFC about these things. They are widely accepted by other software vendors/products. Because there's a difference between principles and applying them in a particular manner in particular patch to particular software. The responsibility of core PHP developers it to evaluate the specific solutions and patches and decide if they are good or not. Regardless of how well or badly it was done in specific cases in the past, this is what should be done. If the author of the patch doesn't want to do this - well, ok, so he would have his patch and we probably won't, unless we find other ways to do it - maybe even the worst way possible, by having security problem illuminate the need - but I see no way around it. The patches are available for everyone. You can download them at http://suhosin.org - also everyone can use them for free. Everyone can just take them and merge them into PHP. But it will not be me. As I previously stated I can live with a few percent less performance or more memory usage due to memory canaries. (The later can actually be largely improved and I have plans to do it somewhen in the next months). However I know that memory canaries will never go into PHP mainline. And knowing that tells me that I have to keep Suhosin anyway as a project. And therefore people should use it. And all those that maybe cannot live with this impact can already use Suhosin today and just disable the memory canaries via environment variables. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello, I only say a few words and then i will be silent I tend to agree with Linus on this one Security people are insane Yes and the security community thinks that Linus is insane for his view on security topics. Not words : write RFC(docs),patches with sane techincal disscussions or a pluggable architecture with extensions and rules, something like is done with LSM http://en.wikipedia.org/wiki/Linux_Security_Modules or mod_security in apache It is funny that you come to this thread not knowing what you are talking about and say we should do something like mod_security for Apache. You obviously have no idea that the majority of Suhosin features is already inside an extension to PHP. The only stuff not inside that extension are features that need to be in the core and therefore cannot be in an extension. And these mitigations inside the core are stuff like memory manager canaries that are considered too much a performance impact by PHP.net. Therefore these patches have to be in a separate patch. Therefore all the features are in the patch. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Pierre, Why do you need a RFC to propose something to the W3C, or python? Even if it is widely adopted already. No need to answer, that's rather obvious. you still fail to realize that I don't want to propose (anything) to you. If you love writing RFCs then write some. I am perfectly satisfied with people having the choice to just use my stuff or not. I do not need to write RFCs to make PHP more secure in the future. Instead people have TODAY the choice to just install Suhosin and get that extra bit of security. I am merely informing people that from my point of view (and most people in the web security community agree) using PHP without Suhosin is a bad choice. And If you disagree that is your problem. By lobbying against Suhosin you are not hurting me or Suhosin, you are hurting the internet. -stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Pierre, I think we all know that 90% of your emails consist of twisting other people's words in the hope to make them look bad and redirect from the technical content. Every time in this threat you replied to me, you were not adressing the technical issue but taking some sentences and twisting the words and play offended e.g. for calling you an Microsoft employee, while you yourself claim that on LinkedIn. You repeatedly claimed that I said A, B or C, while that infact is not the case. This trick might work on the average mind in the PHP community, but not on me. However you keep saying that we should not do that or that RFCs are not needed for these additions (if that ever comes) because it is widely used. And that is totally wrong. Now I think we are done :) I never said that your RFCs are a bad idea. I said that I will not write your RFCs. And I see no need in an RFC about something that will not happen anyway. And that said I consider this discussion done from my side and I will not reply to any other mail from you. -stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hey Florian, Now that's something I didn't read from Ondřej's mail, but delivering the packages with and without suhosin would, while being more work, certainly the most helpful way for users. Then again I'd gladly help if there's anything of this additional work that can be done. people are constantly ignoring the fact that Suhosin-PHP listens to several environment variables: SUHOSIN_MM_USE_CANARY_PROTECTIONdefault = 1 SUHOSIN_MM_DESTROY_FREE_MEMORY default = 0 SUHOSIN_MM_IGNORE_CANARY_VIOLATION default = 0 SUHOSIN_HT_IGNORE_INVALID_DESTRUCTOR default = 0 SUHOSIN_LL_IGNORE_INVALID_DESTRUCTOR default = 0 By configuring these environment variables you can disable the canary protection that is eating tons of memory and speed (which is greatly exaggerated by people). You don't need to have two compiled packages. You can just DISABLE Suhosin to 90% with these flags - or make it even stronger by telling it to sanitize all freed memory. BTW: The Debian PHP maintainers know about these flags, because I repeatedly mentioned them in my answers to them. Also the Debian PHP maintainers patched the code of these environment variables 2 years back. So not knowing about them is just an excuse (if they bring it up). Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Soenke, I know it's hard because he personally attacks people and this doesn't help at all, but deal with him. He really made PHP and the interwebs more secure for the last decade. Do not respect him for how (bad) he's communicating things, respect him for what he coded. We are coders. I am not attacking people personally. Telling someone that he looks very stupid, because he did something stupid is not a personal attack. It is stating the facts. How does it not look stupid for the lead maintainer of PHP in Debian* to write a We do not need Suhosin, because I believe there will be no future Bugs in PHP mail the very same day various PHP distributions have to put out updates because of a critical security bug that INFACT is mititgated by PHP. People don't get that saying we do not need Suhosin because there have been no such critical bugs is like saying: we code perfectly we do not need ASLR, NX, Fortify Source, ... And it does not only look stupid to write such a mail at that moment it also shows how disconnected the Debian PHP maintainers are from what is happening around PHP. It also shows that the PHP devs seem to not like the Debian people, because otherwise they would have kept him in the loop. I know for a fact that Ubuntu and Redhat were informed. So instead of telling me that I am bad with communication they should start critizicing themself. Regards, Stefan *well I heard there is no such thing as a lead maintainer in Debian, but he takes the lead at the moment -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hey, How does it not look stupid for the lead maintainer of PHP in Debian* to write a We do not need Suhosin, because I believe there will be no future Bugs in PHP mail the very same day various PHP distributions have to put out updates because of a critical security bug that INFACT is mititgated by PHP. of course that should read: mitigated by Suhosin. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, Please state the facts. I did add Debian and Ubuntu to the discussions on secur...@php.net. For all the issues you have reported yesterday (and I do the same for other). I do not know if Ondrej is on the security debian list, but that's up to them to deal with that. Actually you have not. All mails that went to me were only forwarded to redhat security and ubuntu security. If you sent any mail to debian than this mail was not CCed to me. And even if you have done so than the big fuckup is on the side of Debian for not informing their maintainers. Yes, as far as I know no more active members are part of the list, but they are part of the security people on bugs.php.net. Reporting flaws via bugs.php.net would be actually much better these days as more people can read it (see the repo for their accounts) and it is actually archived. And thisis also one of new good things we have changed recently. Pierre secur...@php.net was founded by me many years ago, because THIS is the worldwide accepted standard for reporting security problems. It doesn't matter if your prefered way is bugs.php.net or whatever - standards are there for a reason. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, Again, please tell me which part of Suhosin would make sense to have in the core? With technical explanation or details. Then we can begin a good discussion and maybe a RFC to get them in. what part of all of it and I am not going to try to convince you about this do you not understand? I am not interested in pushing Suhosin into PHP mainline. Why in hell would I want that. If Suhosin gets absorbed by PHP.net then I would have to start a new project, because there are tons of mitigations I can think up that will be implemented at some point in time and will never make it into PHP mainline. With Suhosin existing I am free to implement as many security mitigations I like and do not have to beg the PHP developers to consider adding something. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The case of HTTP response splitting protection in PHP
Hello,
I think current events show how important it is to make this case publicly
known.
On Dec 6th 2005 PHP got a partial protection against HTTP response splitting. A
security mitigation == Security Patch == important
The commit is here:
http://svn.php.net/viewvc/php/php-src/trunk/main/SAPI.c?r1=200124r2=202220
569 /* new line safety check */
570 {
571 char *s = header_line, *e = header_line +
header_line_len, *p;
572 while (s e (p = memchr(s, '\n', (e - s {
573 if (*(p + 1) == ' ' || *(p + 1) == '\t') {
574 s = p + 1;
575 continue;
576 }
577 efree(header_line);
578 sapi_module.sapi_error(E_WARNING, Header may not
contain more then a single header, new line detected.);
579 return FAILURE;
580 }
581 }
As you can see the code checks for \n and only allows it if it followed by
whitespace to protect against header injections.
Now fast forward to 2011/2012 the PHP developers get a security bug report that
this protection is not sufficient, because browsers are too allowing.
https://bugs.php.net/bug.php?id=60227
You can see that this bug is not marked as some kind of security bug, although
it is reported as security bug.
This results in the following code being changed in PHP see
(http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/SAPI.c?r1=321634r2=322263):
592 /* new line safety check */
593 char *s = header_line, *e = header_line +
header_line_len, *p;
594 while (s e ((p = memchr(s, '\n', (e - s))) || (p
= memchr(s, '\r', (e - s) {
595 if (*(p + 1) == ' ' || *(p + 1) == '\t') {
596 s = p + 1;
597 continue;
Keep in mind this is a security fix/improvement. So one would expect this to
get reviewed. But it is obviously not reviewed, because any \r before the last
\n won't be checked.
So bypassing this is easy as \rSet-Cookie: XXX=YYY; \r \n blah
So I point this obvious flaw out several times, yesterday on the internals
mailinglist in public infront of everyone.
But instead of someone from the security team taking action just some guy gets
going and patching it.
The commit is here:
http://svn.php.net/viewvc/php/php-src/trunk/main/SAPI.c?r1=321634r2=323033
Best thing about this commit is the commit message:
- Hopefully correct fix for bug #60227.
#No commit for 5.4 for now
From the commit message it seems obvious that the guy commiting it is not
really sure that he fixed anything. Not a good way to handle a security
fix/improvement.
But it gets better: without review this code is now merged from Trunk into PHP
5.3
So the new code looks like this:
714 char *s = header_line;
715 while (s = strpbrk(s, \n\r)) {
716 if (s[1] == ' ' || s[1] == '\t') {
717 /* RFC 2616 allows new lines if followed by SP or HT */
718 s++;
719 continue;
720 }
well lets look a bit further:
727 sapi_header.header = header_line;
728 sapi_header.header_len = header_line_len;
Now the educated reader might think: Wait a second! There is a header_line_len?
So maybe that header_line can contain NUL bytes. Wait… that security check is
using a string function that will stop at a NUL byte.
And then maybe the person reading the code will realize: wait! they just killed
the whole protection, because now a single NUL byte infront of the \r\n will
bypass it.
Luckily it is not affecting everyone, because at least the Apache SAPI will
stop sending the header at the NUL byte, too.
However everybody running CGI/FastCGI will loose the protection with this.
And that my dear readers is exactly what would happen to the code of Suhosin if
it gets merged into PHP. It would be patched by people that do not know exactly
what they are doing. And it would be broken. And if I would not sit on every
single commit to PHP this would happen, because obviously inside PHP no one
cares about reviewing security patches.
And with Suhosin outside of PHP, there is a secondary protection layer around
PHP that would have catched this problem: also known as defense in depth.
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Ondřej, My personal feeling is that most people see suhosin as this is about security, thus it must be good. This combined with bad PHP security history makes everybody feel insecure when suhosin was removed, but the real question is if the suhosin is still really helping with PHP security or it is just a burden in the general installations now. considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed). Just saying. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and will have bugs. This is not really hot news. That does not affect this discussion. I know that for many years you have not understood the idea behind Suhosin, the concept of exploit mitigations. The only reason why Suhosin exists is because there will ALWAYS be bugs. And because that is a fact you must have safe guards in case something goes wrong. Suhosin/HPHP provides this safe guard for 8 years to the PHP community. Ideas like: I haven't seen much bugs lately so lets drop all the safe guards is like not paying for your life insurance anymore, because you haven't died too often recently. BTW: You should really really look into the history of PHP security and check for each of the last 8 years how many features were in Suhosin and later merged into PHP because of some nasty security problem. You will see that at least 2 features of Suhosin per year were merged into PHP. And there are many many good reasons, why Suhosin must be external to PHP. The most obvious one is that the code is clearly separated, so that not someone of the hundred PHP commiters accidently breaks a safe guard. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Ohh btw… I have walked the bug list for 5.3 mentioning suhosin[2] to actually at least partially support what I have just said. I have found few bugs where suhosin was causing a problems ([3],[4]) and a handful of bugs with have suhosin, cannot help. I know this isn't (and can't be) a definitive list, but it just show that P.S.: Also see stas reply[5] about valgrind. Links: 1. http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php 2. https://bugs.php.net/search.php?search_for=suhosinboolean=0limit=90order_by=direction=DESCcmd=displaystatus=Allbug_type=Allproject=PHPphp_os=phpver=5.3cve_id=assign=author_email=bug_age=0bug_updated=0 3. https://bugs.php.net/bug.php?id=60216 4. https://bugs.php.net/bug.php?id=60935 5. http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/ 1) You understand that Hardening-Patch is not Suhosin-Patch, do you? 2) Maybe you should also search for: Have Debian, then use a clean PHP not a broken Debian build Bug 3 - is not a bug in Suhosin, it is the fact that the suhosin.executor.max_depth function was not set correctly. Reading the documentation helps: http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.max_depth Bug 4 - the guy is actually writing inside the bug report that the problem occurs with and without Suhosin 5) You can just start PHP with the environment variable SUHOSIN_MM_USE_CANARY_PROTECTION=0 and can use valgrind. So basically all points you bring up are no issues. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, For one, some were not not ported but features were implemented, with the support of their original authors. They are not related to Suhosin, like the Blowfish support, which I ported to php with the help of Solar Designer. Suhosin uses the same implementation. Sorry it makes no difference if a feature was introduced into PHP by taking code from Suhosin or from someone else. Fact is the feature existed before in Suhosin. * GLOBALS overwrite protection * max_file_uploads * max_input_vars * crypt() blowfish * max_input_nesting_level * Superglobals overwrite protection in explode()/import_request_vars() * safe unlink in Zend memory manager * http response splitting protection against \n * http response splitting protection against \r --- broken attempt to support this in PHP 5.4 * and most probably many more that I do not know from the top of my head (this are already 9 features and Suhosin/HPHP exists since 2004 = 8 years). I understand why you left the security team and the php project years ago. Back then I was not on the security team, so I won't comment this period (and I would have partially agreed with you). However, I am Suhosin/HPHP existed 3 years before I left the security team. So the creation of it had nothing todo with me leaving the team. Many features are making their way to PHP as well, on a case by case basis. We have changed and we are on the right track since quite some time already. If you have features that you consider that it must be in the core, then let discuss it, on this list. But so far I failed to see other features in Suhosin that we need to implement without having more cons than pros. The fact is the PHP developers NEVER saw other features they needed to implement and then some external people disclosed some PHP bug and as a result one of the Suhosin features were cloned. The thing is: I see no problem with the status quo - Suhosin exists and people can use it - it is like people can choose if they want ASLR, NX, Fortify Source on their system. I do not have the time or wish to convince the PHP developers to add some features that most probably after some time will be copied/clones/reimplemented anyway. The only problem I see is that some PHP developers negate the fact that Suhosin increases security of PHP (which was proven again and again for 8 years, why else clone features) and recommend people to stay away from it: This is malicious. And yes I like the Suhosin codebase separate, because if there is a bug I can smack the responsible person (myself) over the head bigtime. If Suhosin merges with PHP a lot of patches will go into the code and the work to keep track with every commit that touches some Suhosin feature will explode. Just look at security patches like this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225r2=318997 Yes it is one of the features that is in Suhosin for a long time - anyway that security fix is completely broken and noone cares about it. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Derick, * and most probably many more that I do not know from the top of my head (this are already 9 features and Suhosin/HPHP exists since 2004 = 8 years). Lots of stuff in PHP was also stolen from Xdebug, but I am not whining about that as the goal is (and has always been) to make PHP better. I am not whining of something being stolen I trying to demonstrate that a lot of the features noone ever saw a need for in PHP have been cloned. PHP devs repeatedly tell that Suhosin brings no additional value, while they clone and clone every time they are hit by a nasty bug. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225r2=318997 I'm sure we'd be more than happy to hear why it's broken and hear about possible suggested fixes. The purpose of the code is to detect all occurences of \r or \n not followed by whitespace and error out. It is obviously doing something else. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Hello Pierre, This is exactly where you should help php directly instead of doing what you do now to defend your patch. In the long run (or maybe even mid term), the Suhosin patch will disappear. I seriously doubt that. The PHP developers will never ever merge all features into the PHP core. And therefore Suhosin will continue to add additonal value. Especially since the next Suhosin-Patch for PHP 5.4.0 will already have new and more mitigations. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.9, Hash DoS, release
Dear Pierre and others, I'd strongly suggest to release 5.3.9 (RC5 has been tested now) final this week using the max_input_vars fix, with the modification from Laruence (but with a larger limit). Laruence addition also fixes serialize or json, which are parts that need this fix as well as it is impossible to valid a string manually (length check only is not enough or cannot work in all cases). Why do you advocate a patch from Laruence that randomizes the size of the HashTable, which does not fix the HashDOS security problem at all? It seems that the majority of people working on this HashDOS stuff do not understand the actual mathematical problem and try to exploit it by using numerical indices. In case of numerical indices a collision is trivial: 0x0001, 0x0002,0x0003, … 0x will all collide because n mod 2^x is always 0 for x=16. This is however just the cheap way to cause HashTable collisions in PHP. The actual HashDOS exploit the nruns guys were talking about *DOES NOT* involve numerical indices at all. The nruns guys are speaking about collisions in the DJB hash function, which is used for alpha numerical indices. This cannot be fixed by random HashTable size increments. Random HashTable size increments will only lead to tricky debugging situations, because due to the randomness the PHP memory layout/usage for the same script will be totally different with each run. Just one of the possible consequences: the same script, running on the same server, called 2 times with the same parameters can e.g. cause memory limit violations in totally different places. Or sometimes does not violate the memory limit at all. And this all ignores the fact that the patch by Laruence is broken and performs dangerous operations on the size field that could introduce further problems. *** The only way to fix the HashTable implementation is by using a randomized HashFunction (not a randomized HashTable) *** *** And of course resource limits are always a good addition to protect against this and future different vulnerabilities. *** Regards, Stefan Esser signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] 5.3.9, Hash DoS, release
Hey, I think you accidentially sent this to me, not to the list ;) By the way, I think you and Pierre are talking about different patches. We do know that the hash size randomization will not work. Pierre is referring to another patch that extends max_input_vars to unserilized() and json_decode(). ah okay. I see now that there is a different patch, but it is not clear if Pierre meant this or the HashTable randomization patch, because both were advocated to fix the unserialize() and json_decode(), too. Just a quick look at it tells me that I don't like this patch either. It adds code to each POST handler. The POST handler interface is something extensions can extend. With Laurence's patch: suddenly all extensions that implement their own POST handlers must add the max_input_vars check. Of course I am biased, because suhosin is one of the affected extensions. But that said suhosin has a limit similar to max_input_vars for 7 years now. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release
Hey, That is Restricting a max length of a buckets list in a hash table. If a bucket's length exceed 1024, any insertion into this bucket will return failure and a warning will be generated. What do you think? very bad idea. Especially when it comes to numerical indices a legitimate application might put data into a big array and have legitimate colliding keys. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.9, Hash DoS, release
Hello Pierre, Not really the same, but yes. While the reasons you did it was not the same. Also the length check is not related or cannot be used for this fix. But nice self promotion ;-) Considering the fact that the HashDOS problem was originally discussed in a paper 2003, someone discussed HashDOS vs. PHP originally somewhen in 2004 and Hardened-PHP came out in 2004 it is funny that you believe to know, why I added variable count restrictions. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release
Hello, I am not sure whether you have understood my point. I understood your point: you want to break HashTables because 1024 colliding entries could have an performance impact. This could break thousands of scripts. for ($i=0; $i2000; $i++) $arr[$i16] = 1; would stop working, while it should not. Regards, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.1 reference parameter regression
Hi, because this breaks backward compatibility -without notification- with a minor version update both in 5.3 and 5.2 branch. well actually the bug was that call_user_func_array() did not trigger the what you do is deprecated warning. Calling the function directly would have resulted in a this is deprecated warning anyway. Stefan Esser -- SektionEins GmbH stefan.es...@sektioneins.de Eupener Straße 150 Tel: 0221 / 29282931 50933 Köln Fax: 0221 / 29282935 http://SektionEins.de/ Firmensitz Eupener Straße 150 50933 Köln Registergericht Amtsgericht Köln HRB 59950 Geschäftsführer Johann-Peter Hartmann -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.1 reference parameter regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Tim, There seems to have been no progress on this. Is there anything I can do to help? just for the record: why does MediaWiki rely on a feature Call-Time-Pass-By-Reference that is deprecated since PHP 4.0.0 - Yes exactly 4.0.0 What happened between 5.3.0 and 5.3.1 is that stas killed that feature for internal functions to work around a big security problem in the design of the Zend Engine. Considering the fact that the feature is DEPRECATED since 4.0.0 it would even be okay to kill it for all functions. Stefan Esser - -- SektionEins GmbH stefan.es...@sektioneins.de Eupener Straße 150 Tel: 0221 / 29282931 50933 Köln Fax: 0221 / 29282935 http://SektionEins.de/ Firmensitz Eupener Straße 150 50933 Köln Registergericht Amtsgericht Köln HRB 59950 Geschäftsführer Johann-Peter Hartmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksp0bcACgkQSuF5XhWr2nhdwQCggzxIUz8N7ZlRLWWklTqJBnPO BSoAniiOqs2JXyh4iNwRtp9FiGRIy/16 =q9+2 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inspecting opcode
Hello, Cannot compile with VC6/x86 under Windows.. Is there any precompiled binary for this environment? Thanks I recently realised that the ZTS build is broken. Will fix it during the weekend or early next week. I will also move Bytekit and Suhosin.org to new redmine installations, becaue Trac is crap. Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inspecting opcode
Hello, Does anyone know how to inspect the opcode of a php file? take a look at Bytekit at http://www.bytekit.org Bye, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #40698 Re-use search term in the quicksearch input field
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Josef, before you want to commit something to the PHP bugs website, you should recheck your code for obvious XSS bugs in it... +input class=small type=text name=search_for value=?php if(isset($_GET['search_for'])) echo $_GET['search_for']; ? size=30 / Greets, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknNIzMACgkQSuF5XhWr2njSZwCfTsKMpEM+/q4w8jwx8w2rqLFt EHIAnjpNDsqAS0MdERmWNUHETS2QXLHQ =477X -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_USER_OPCODE_CONTINUE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Johannes, while implementing a small toy extension (see [1]) I found out that ZEND_USER_OPCODE_CONTINUE seems to misbehave as it doesn't go to the next opcode so I ended up in an endless loop executing the same opcode again and again. I guess that is exactly the required behaviour. How else do you want to implement an user opcode that transfers control to another opline, like a special kind of jump opcode. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmbJqwACgkQSuF5XhWr2njnzACgizi7a24c6GxNKTwMPU3SjvFF KLQAnRz4w6i36ogEmT0LBofAjI5EiULP =KDZK -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #44872 canary mismatch on efree() - heap overflow detected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, a false positive on the part of Suhosin. If it does report a problem however, then mssql extension has a bug and valgrind output should be good enough to identify the where the why. valgrind cannot (by definition) see all memory problems Suhosin detects. Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjvbr4ACgkQSuF5XhWr2ngkKQCgniliTOQKjqpOJMS30lN2+Vf5 +NMAmgP3FtFlZnmoctZhAI67rDSDqdOI =M9h8 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dmitry, __FILE__. /../../foobar.php probably could work on Windows/BSD only, but won't work anymore. this works on Linux and everywhere where GLIBC is used, because GLIBC realpath() supports this nonsense. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkihRmwACgkQSuF5XhWr2nhv5gCgsRSUMOtc8/PcsugrL3xTNar0 iYIAoIVA4fO5dWwRfxIzHpYfhNFNNuA4 =tAba -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Dmitry, while you are at fixing realpath() it might be a good idea to fix the ../ nonsense. What I mean is: fopen(this_is_not_a_dir_but_a_file/../../../../../../../../etc/passwd, r); works because of realpath() and PHP's wrapper. Same for fopen(this_is_not_existing/../../../../../../../../etc/passwd, r); Both is madness... Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkidgR0ACgkQSuF5XhWr2nhovACXZpeATBITDai/M1wsCuavuZ3C OgCgn46uM4XHwENW7si4aJzeNgnuTKg= =QiYy -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Switch Table Extension for PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Dmitry, while I also believe that the extension should not be included in the core at the moment I strongly believe that it will be compatible with every well behaving opcode cache. Because it modifies op_array during execution... a) the opcode cache is not affected at all because it always provides a copy of the cached op_array to execute() or b) the modification will be performed on the cached opcodes in memory which means the opcode cache either stores (and therefore shares) the manipulated opcodes (with other processes) or not. Either way any process loading the opcodes that were manipulated by another process should recognise the loaded op_array as not yet optimized. Therefore the optimization will be repeated in the other process again = No problem at all. Therefore only on edge cases, where 2 processes share the same memory addresses for the switchtables a malfunction due to an opcode cache can happen. (I will improve that by a canary value that is different for each process and that I will store in the extented_value of the JMPZ opcode that is following the CASE) Attention: switchtable is not threadsafe at the moment Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiS+BMACgkQSuF5XhWr2nhGxQCgn1EPNaZS3ndUZG4DKTQ2+njk 7lwAnjiTWCoInAbR1jTY+4B6vdEm8NLd =+8w7 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Switch Table Extension for PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dmitry, As you set the extended_value in shared memory to point into process memory the other process will read it and look into it's own memory, and of course it won't find proper switch-table there. In case the opcode cache directly uses op_array mapped in shared memory the extension should result in a slow down because every . However it SHOULD detect that the extended_value points to an invalid memory address, because it checks if it points into the memory allocated. The heap should be random enough to catch this most of the time. But yeah I know that there are some (potential) problems ;) That is why it is experimental. The bigger question is however if the whole idea fails with some switch() constructs. Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTC4QACgkQSuF5XhWr2ni66ACdG2DuhO/q2n1StRU559QCPoMn iiwAoLpBBcA/jQD0NjBajkD/uRpEWa5M =kloR -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Switch Table Extension for PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The idea also won't work with variables and unresolved constants as case labels (I saw your extension already carries about this limitation). Yeah constants are the reason why I perform the optimization at runtime. Because the moment a switch is executed the constants should be available, because otherwise the switch() does not make sense. And at that point the constant cannot change anymore. That is the reason why compiletime / optimization time optimization is a problem. And yes variables and function calls in CASEs are a problem. That is why I am not supporting them (and will not). After all there are people that abuse switch() as OR. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTJYkACgkQSuF5XhWr2niH/gCfVhl1xoED9IdEUUPvUgKlxtaI 31gAoJdnpFssybdbqfwYC8XUDpMdfUWY =8mem -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Lester, I wonder if you could enlight us, why you hate ext/mysql? Do you believe the urban legend that smaller .exe/.dll are loaded faster? Maybe you have never heard of shared code segments... Every readable only segment is shared on windows. So there is only one copy of the .dll/.exe loaded for ALL processes using it... Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh6/vkACgkQSuF5XhWr2njBNQCgk+JHAUN7cLDA0oSgmU90bd8r RJIAn1mCKkEsPHQq6W6Fa++MuQRJ05xa =J5LW -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.4.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Janusz Lewandowski schrieb: PHP 4 end of life announcement: After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Considering the fact that PHP 4.4.8 is known to have several public security problems that where only fixed in PHP 5, releasing PHP 4.4.9 as last final version is the right thing todo. Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhyGhYACgkQSuF5XhWr2njsGACguBayiah0yj0RojBYhIIvCIqq 67kAni2syRvA1Db2mOHv96csV7pwh+tB =U9RH -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New flame
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is used when reading scripts that are in encodings like Shift-JIS which is very common in Japan. In any case, I have tried to get involvement from some people I know over there without much success. I've asked around a bit as well with our customers/partners, and all they seem to answer is we simply use UTF-8. It is very unlikely that anyone on internals uses Shift-JIS (EUC-xx). Mainly because (nearly) noone here is Japanese (Korean, Chinese). However google for phpinfo() and you will see that zend_multibyte is compiled into several PHP servers. You can also google for Shift-JIS and co... The problem here is that newer Asian systems will use UTF-8 (except those nations using characters not possible in utf-8) and therefore the customers of the PHP developers (on this list) will not need that support. However there are many legacy systems out there who depend on this feature. They most probably don't know about this discussion or internals at all, so they cannot speak up. If PHP 5.3 drops this feature it might close some multibyte security problems. However this also means that all those Japanese/Chinese/Korean/Taiwanese/... multibyte scripts will not run anymore. This forces systems to stay on PHP 5.2 which will most probably don't get security updates once PHP 5.3 is out of the door. Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhhAu0ACgkQSuF5XhWr2njCswCcDCyWnFi4jInpX+BPhmSp6ec7 pAEAoKfDzhhpFKifgwlsn99WMwkve5bp =2qIJ -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New flame
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Lukas, As such the conclusion can only be that investing any time in readding this feature would be a bad idea. If anyone actually uses this feature they will have to come out of the woodwork now or when 5.3 is out. At this point we might have enough information to actually understand how that feature is used and how we can add it to 5.3. I really don't know what is so hard for you understand with this feature. It switches the Zend Parser into another encoding that is used when reading from blah.php files. (okay there is also some auto detecting magic). The reason for this is very simple. It allows you to write f.e. Japanese in strings. If you use Shift-JIS then several Japanese characters will not work in single byte PHP. The backslash (escaping) character is part of several Japanese characters. In single byte PHP these characters are wrongly considered as escape sequences by the parser while the multi-byte parser realises that they are not escape sequences. The same is true for chinese people using GBK. (afaik GBK is not completely within utf-8) Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhhBgwACgkQSuF5XhWr2nivWwCghOHAq9l0wrORJ9/3d7a4/RTz Qp0AoJj3zqjxjTgEs1JlJZK5TftsCHcG =rTY0 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Creating one extension version: how?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, How can you prepare my new extension source code and/or links so that the DLL can support all the PHP 5.x.x versions? You can't. But you can have one source version which can be built against all PHP versions. This is not true. It is possible to create an extension that loads and works in all PHP versions, but it is a PITA to write it. If you really want to do this you need to internally support different binary versions of PHP and you need to replace the get_module export with your own code that exports different structs depending on PHP version. Ah yes, and you need to load many symbols through the libc because they might not exist in the PHP version. f.e. globals... Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgmxuwACgkQSuF5XhWr2ni3VgCglNM7Ve6FXfHhG8vKcXyRCgMy tMwAnj6Q+G0cZEV6bzSi4yPQuEJa9zgl =WCeY -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3 the slowest PHP of all times ?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good morning, I just want to bring attention to the fact that while benchmarks show that PHP 5.3 is faster than PHP 5.2 on linux systems on MacOS/X the opposite is shown. Actually just executing bench.php from the PHP distribution shows that PHP 5.3 is about half the speed of PHP 5.2.5 How can that happen? Greets, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfwsNoACgkQSuF5XhWr2ng9egCgosYoQWLoXp4gpGLJSAz79uY7 ktkAoJdZ9Iq8DiDtqyGnQNseelAm/fyb =UEbw -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 the slowest PHP of all times ?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marcus, did we change from non ZTS to ZTS builds on MacOS? ZTS builds do a bunch of additional copying of tables. Nope. Thread Safety is disabled. I did my comparision with PHP 5.2.5 and PHP 5.3-Snapshot. Both versions were compiled with a simple ./configure without any additional parameter. bench.php was executed with the CLI SAPI. Here are the tables for PHP 5.2.5 simple 0.328 simplecall 0.405 simpleucall0.660 simpleudcall 0.767 mandel 0.993 mandel21.253 ackermann(7) 0.993 ary(5) 0.050 ary2(5)0.048 ary3(2000) 0.498 fibo(30) 2.229 hash1(5) 0.089 hash2(500) 0.091 heapsort(2)0.281 matrix(20) 0.237 nestedloop(12) 0.535 sieve(30) 0.222 strcat(20) 0.040 - Total 9.719 And here for PHP 5.3 simple 0.535 simplecall 0.799 simpleucall1.322 simpleudcall 1.320 mandel 1.691 mandel22.170 ackermann(7) 1.299 ary(5) 0.101 ary2(5)0.094 ary3(2000) 0.986 fibo(30) 3.282 hash1(5) 0.225 hash2(500) 0.195 heapsort(2)0.499 matrix(20) 0.458 nestedloop(12) 0.948 sieve(30) 0.469 strcat(20) 0.077 - Total 16.469 regards, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfxABIACgkQSuF5XhWr2niu0QCbBhCZWBW8nPX5G48YxNgM6qr2 8CQAn0SeMMKFjV1Hy/uKT4NSCMU5Lj/9 =lZtJ -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
Hello Lukas,
Ah ok .. sorry for having missed that point. Of course I was assuming
that the feature worked as advertised. I guess I was thrown off by the
fact that Stefan initially made it sound like the concept in general
is flawed and would automatically make an application insecure.
Obviously a buggy implementation of such a critical piece could lead
to some issues, though like I said in this case I hardly see this as a
security risk. Relying on $_REQUEST to implement your
the problem is that you usually don't care if the input comes from GET
or POST. But you normally don't want cookies to influence that.
Just imagine my example...
switch ($_REQUEST['action'])
{
case 'logout':
logout();
break;
...
}
When someone injects you a cookie like +++action=logout through an
XSS or through a feature like foobar.co.kr can set cookies for *.co.kr
(in FF atleast).
Then you CANNOT use the application anymore. This is a DOS. You cannot
defeat this problem except detecting and telling the user to delete his
cookies manually...
There are only hard ways to kill the cookie for you, because then you
would need to
a) parse the cookie header to know exactly how it is called (remember
whitespace in the beginning is ignored)
b) you need to guess for what domain/path combination the injected
cookie was set (because otherwise you cannot kill it)
Have fun with sending tons of Set-Cookie headers or have fun with
telling a DAU how to kill his cookies...
But this problem does not only result in DOS. I have also seen code like
this:
admin_config.php
/* The configuration was modified */
if (isset($_REQUEST['config'])) {
...
updateConfig($_REQUEST['config']);
}
This is what I call a Delayed Cross Site Request Forgery because I
just give you the cookie config[header_include]=http://evil.com/cmd.txt?
and the next time you modify the configuration in your application the
sleeping cookie will take effect and overwrite a specific config option.
In this case the included header file of your e.g. forum with a remote
URL. (just an example... such a bug could also be in the user management
and the next time you edit a user he becomes admin...) And the bad thing
with Delayed Cross Site Request Forgery is, that all protections
against CSRF will fail in this situation.
So you see that you nearly NEVER ever want the cookie in _REQUEST. And
even if you can think up a theoretical situation where you don't care
the problem is that everyone else uses _REQUEST in unsafe places...
Therefore my recommendation in PHP source code audits is usually... If
your code uses _REQUEST then overwrite it with an array_merge() of _GET
and _POST in the beginning of the script.
Stefan Esser
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
Stanislav Malyshev schrieb: @Richard: You don't understand the Problem with _REQUEST. It is not about the fact that someone can forge GET, POST; COOKIE variables. It is about the fact that COOKIEs will overwrite GET and POST data in REQUEST. Isn't it solved by setting variables_order to correct value, at least partially? I.e. if you have variable in GET/POST it won't be overwritten by the COOKIE one, of course there still may be a scenario when the variable is set only in COOKIE, but then doesn't omitting 'C' from variables_order exclude cookies from _REQUEST? Changing the variables_order to CGP is not a good idea either, because then applications that use cookies through _REQUEST could be tricked by simple _GET variables. Session Fixation vulnerabilities in selfmade session management systems come to mind. Unfortunately removing C from variables_order does not only remove cookies from _REQUEST but removes the content of _COOKIE. And that would kill e.g. ext/session. It would have been a good idea to have such a configuration option that allows to specify what is in _REQUEST and what not... Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
Stefan Priebsch schrieb: Richard Lynch schrieb: If a web service really doesn't care whether it is responding to GET or POST or even forged COOKIES to product its output, why would it not just use REQUEST? It's not as if it's any harder to forge GET vs. POST vs. COOKIE data, really. I am replying to Stefan's mail because I don't see the one by Richrd (yet). @Richard: You don't understand the Problem with _REQUEST. It is not about the fact that someone can forge GET, POST; COOKIE variables. It is about the fact that COOKIEs will overwrite GET and POST data in REQUEST. Therefore I could infect your browser with a cookie that says e.g. action=logout and from that day on you cannot use the application anymore because REQUEST[action] will be logout forever (until you manually delete the cookie). And to infect you with a COOKIE is so simple... a) I could use an XSS vuln in any application on a subdomain b) Ever tried setting a cookie for *.co.uk or *.co.kr when you own a single domain there? c) Other cross domain whatever ways... And if you believe that this is not an issue then I can tell you that there is a simple possibility to set f.e. a *.co.kr cookie that results in several PHP versions just returning white pages. Imagine: Just a single cookie to kill all PHP pages in *.co.kr And by setting an illegal session ID in a cookie valid for *.co.kr in a variable called +PHPSESSID=*illegal* you can still DOS every PHP application in korea using PHP sessions... Greetings, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
The main flaw in type conversion hinting is that it's nearly pointless.
Why convert the type at function call? PHP will automatically juggle the
type depending on the variable's destination, really no point in
converting it one more time when calling the function
Well that is not entirely true. There is a point, because inside the
function the type information is static. Therefore intra functional
analysis of optimizers and static source code scanners is still able to
use this information.
However you loose the extra juice where calling a function with a type
hint (int) also gives you information about the type in the calling
function. You loose this information if you auto convert.
You also loose the ability to decide on byte code level if code is broken.
But yes, because everything can be casted to a number/string the
userland feature to detect wrong types passed to functions is gone...
Imagine
function doStuff(string $x)
{
...
}
doStuff(md5($_GET['xxx']));
When you cast you don't realise that this code is broken
md5(array()); returns NULL; which is autocasted and doStuff() accepts it...
Stefan Esser
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
Hello Daniel, It may be off-topic for the initial post, but I disagree wholeheartedly with the above statement, Stefan. There are innumerable reasons where $_REQUEST would be much more economic than writing out all conditions for $_POST, $_GET, $_SESSION, $_COOKIE it doesn't matter if you disagree with my statement, because that is just another personal opinion. It is a known fact that using $_REQUEST usually introduces security holes in applications. There is always $_COOKIE merged into it, which overwrites $_GET and $_POST. That means I just need to infect your browser with a cookie and have delayed cross site forgeries all over the place... Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
Hello Alain, I think you are also confused about PHP type hinting... The manual clearly states: Type Hinting PHP 5 introduces Type Hinting. Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). And suddenly you want to change that definition to Functions are now able to force parameters to be types that *could be casted* to objects/arrays. That is not going to happen. Type hints are supposed to force parameter to be of a specific type. Any kind of auto conversion would redefine type hinting and would be just another feature that gives PHP haters a reason to rant about. And if you want that '1' is allowed to be passed as parameter (without an actual int cast) because it COULD BE CASTED to int then you gain ABSOLUTELY nothing from the type hint. Then you don't need to introduce them at all. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Be conservative in what you do; be liberal in what you accept from others. You hopefully realise that this is exactly the opposite of your earlier opinion that ext/filter should be used to block everything and let only harmless data through. And only have raw data on demand... I really don't understand why adding a *new feature* to the language (that you can use or just not use and) that helps writing better code and helps potential optimizers (that will come up as soon the feature is implemented) to highly optimize the code get so much resistance... Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] U
Hello, typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a that $_REQUEST['age'] has been checked for numeric before the functio would you please not use $_REQUEST in any of your examples? $_REQUEST is one of the biggest design weaknesses in PHP. Every application using $_REQUEST is most probably vulnerable to Delayed Cross Site Request Forgery problems. (This basically means if e.g. a cookie named (age) exists it will always overwrite the GET/POST content and therefore unwanted requests will be performed) And well... This thread continues without a single valid (!= personal opinion) reason why type hinting should NOT be introduced. BTW accepting the string '1' where an (int) type hint is placed would be the next stupid design decision. Yours, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
opinion) reason why type hinting should NOT be introduced. BTW accepting the string '1' where an (int) type hint is placed would be the next stupid design decision. Why Because type hinting is supposed to limit what kind of variable type is allowed for a parameter. When you magically convert you kill the whole idea of type hints and replace it with some magical function parameter auto type conversion, which would be another hard to understand magic feature of PHP. And the next problem would be what should happen in case of a magical conversion when the function wants an int in a parameter that is a reference. Suddenly calling a function does magically change variable types outside of the function = NIGHTMARE. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Good Morning everyone, one should not forget that type hinting has some clear advantages the anti type hinting advocates always try to forget... * the code gets smaller because not so many typechecks in every function * because the code gets smaller it is faster executed (userspace typecheck is slower than engine-space) * without all these type checks the code gets easier to read * with type hints byte code optimizer can optimize the code far better - faster execution * with type hints static analysing tools that check for bugs/vulnerabilities can perform far better (intra procedural analysis gives more information) Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Stanislav Malyshev schrieb:
* the code gets smaller because not so many typechecks in every function
What do you mean not so many? You need one per checked parameter.
There is a difference in complexity between a userlevel type check and a
low level type check.
* with type hints byte code optimizer can optimize the code far better
Do you have any optimizer that can do that? Any plans to make one? Any
tests showing you can optimize real-life application this way?
How should one have an optimizer for that as long PHP does not have this
feature? Noone would implement one that is capable of doing this not
knowing if the feature ever makes it into PHP.
That is true, type hints do make static analysis easier - strict
typing is created exactly for that purpose. However, it only helps if
all the code is strictly typed - otherwise you just move point of
failure around. And in any case, type won't help you much form most
real static analysis purposes, such as security - string can hold
anything.
That is not completely true. If for example 10 functions use type
hinting and other functions not, then you have atleast 10 functions
where you can analyse better.
A simple example is:
function decryptID($id)
{
return $id ^ SOME_RUNTIME_CONSTANT;
}
function getUserFromId($id)
{
$sql = select * from user where id=.decrypt($id);
...
}
To analyse this construct a static code analyser has a lot todo and it
still needs to check every call to getUserFromId() to verify if this is
an actual security hole, because it doesn't know the content of
SOME_RUNTIME_CONSTANT and therefore the return value of decryptID could
be a binary xored string. However a type hint of int in the decryptID()
function would allow the analyser to know that decryptID() always return
int and this would tell it that this is not a security hole. You see in
this example that just partial usage of type hinting can mean the
difference between a false positive and a definitive unexploitability.
Greetings,
Stefan Esser
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tainted Mode Decision
Good Morning, I just wanted to ask if there was ever a decision made that said tainted mode will go into PHP mainstream. Currently there are two implementations available: GRASP by Coresecurity * pro: byte level tainting which actually works * negativ: slow PHP Taint mode by Wietse Venema/IBM * pro: faster * negativ: broken design+insecure It is no secret that I don't like the idea of a taint mode in PHP because it cannot be made secure and fast at the same time. Coresecurity's GRASP is the best example for this it uses a secure design and is therefore slow. On the other hand it seems some people want the fast implementation of Wietse in the core which would be bad, because it is based on wrong assumptions and uses an insecure design that does only give a false sense of security. Examples for the wrong assumptions in PHP Taintmode: 1) _SERVER['PHP_SELF'] is not safe and allows XSS (and more) in many applications 2) Using mysql_real_escape_string() on user input does not make it safe for SQL. It only makes SQL strings safe. Example: SELECT * FROM table WHERE id=.mysql_real_escape_string($id) is NOT secure but will result in no taint warning 3) Using htmlentities() on usr input does not make it safe for HTML output. It only makes it safe in some situations. Example: echo 'sometag style=some-attribute: ',htmlentities($user_input),''. Will allow XSS through the style attribute without a taint warning Example2: echo 'img src=',htmlentities($user_input),''. Will allow XSS through javascript: URL (f.e. in Opera) without a taint warning Yours, Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tainted Mode Decision
Hi Dan, I believe the primary use case for taint mode would be to use it in development: taint mode is a mode which can be turned on to give you an idea of where your application may have exposed some vulnerabilities; let you fix those identified vulnerabilities; then turn off for production purposes. The speed of the implementation, if this is indeed the intention for taint mode, would therefore be irrelevant. The problem here is that both approaches fail to be completely secure even when your test environment has 100% code coverage. And I am speaking of real 100% ... Currently there is no tool that can ensure that. All PHP CC tools I know of so far will for example not handle the ternary operator correctly. The reason why both taint mode implementations fail are simple. Take the following statement. $sql['id'] = mysql_real_escape_string($_GET['id']); $query = SELECT * FROM table WHERE id=.$sql['id']; Wietse's taint mode will consider this statement safe and never cry. GRASP on the other hand will see that there is user supplied data in the SQL query, but will ignore it because it is a number. It will only react if $sql['id'] contains a string. Atleast the very first version did this. This means currently both approaches would tell the developer that they are safe, while they are in fact not. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tainted Mode Decision
Hi Steph, In a preliminary release for feedback purposes you talk about wrong assumptions? Surely this is the whole point of having a preliminary release for feedback :) yes of course it is preliminary. But the whole idea is flawed. It is assumed that a single function exists that makes user input secure for HTML or for SQL. But infact there is not. There exists a wide number of possible contexts like 1) SQL: Inside a SQL string 2) SQL: Inside a SQL table name 3) SQL: Inside a SQL field name (uncommon) 4) SQL: Inside a SQL comment 5) SQL: Where a numerical id is expected 6) ... possible others All these different contexts need another way of preparation/escaping. What kind of handling is actually needed can only be found out by parsing the query and knowing what bytes are tained. This cannot be done if you only use variable level tainting. If you look at HTML it gets even more complicated because you have many more possibilities like 1) HTML: Outside of a TAG 2) HTML: Inside a TAG 3) HTML: Inside an attribut of a style tag 4) HTML: Dangerous URLs in attributes 5) HTML: JavaScript between script tags 6) HTML: JavaScript inside a JS String 7) That said the implicit untainting by use of mysql_real_escape_string() and htmlentities() is simply not feasible. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tainted Mode Decision
Hello Lukas, I wonder how other languages solve this dilemma? Like how does Ruby's taint model work? What are the experience there? Are there any other languages that have a taint model? I don't know exactly what they do, but if I am not completely mistaken the difference is simple. AFAIK perl has variable level tainting, but does not have implicit untainting. That means the developer has to use something like untaint($variable) whenever he wants to use tainted input. This means the developer can only use tainted input when he THINKS and explicitly untaint()s it. He is responsible for bad decisions like using the wrong escaping function and telling perl that he untaint()ed the input. This is different from the implicit untainting through htmlentities() and mysql_real_escape_string() because there are obviously cases where these functions are the WRONG functions and the developer will never realise this because he was not taught to untaint() himself only when he is sure... Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Large file support for PHP
Hi, please keep in mind that compiling PHP with large file support breaks binary compatibility... One of the globals contain a stat struct that has different size for LFS or no LFS. Stefan Esser Wez Furlong schrieb: This bug has been open for a while: http://bugs.php.net/bug.php?id=27792 Having run into this issue recently, here's a patch (hopefully attached, mail.app and list filters willing) against PHP 5.3 to address it. This patch will promote to double the file sizes that overflow LONG_MAX, which works transparently for my script. Note that this only touches the obvious functions in the core; there may be other extensions that need to behave similarly. The defines that I jam into CFLAGS are known to work in our other projects on Linux, Solaris, FreeBSD and OSX. The other (weirder) platforms might need some other adjustments to work correctly. --Wez. -- Stefan Esser SektionEins GmbH Tel. xxx Ober Buschweg 9a 50999 Köln [EMAIL PROTECTED] www.sektioneins.de SektionEins GmbH, Standort Köln Firmensitz: Ober Buschweg 9a, 50999 Köln Registergericht: Amtsgericht Köln, HRB 59920 Geschäftsführer: Johann-Peter Hartmann -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Storing additional information for op_arrays
Morning, I think it's a bug in APC. Each extension has its own slot, by allocated slot number, and should never touch other slots (unless it has some protocol to talk to the extension which owns other slot). So touching slot that is not owned by the code is a bug like touching unallocated memory. Yes it was a bug in APC. But the problem is that I doubt it is clearly documented how to get access to the reserved resourced. Actually I believe Suhosin was the first open source solution that used these resources and the only closed source software that did it (and dit it long before Suhosin) are Zend tools. Well, we can't have pointers to disk in memory :), so disk is another problem. As for shared memory, I don't see how one can support arbitrary length and structure data without using pointers in one way or another, so once you share that you'd have to use shared memory pointers anyway. Maybe I misunderstand something in what do you mean - could you tell some more on what would be the improvement you are thinking of? Well the problem I want to be solving is the following 1) Extension generated extra data that is linked to the op_array (f.e. information like: was generated by eval()'d code, does use variable XYZ, uses session functionality, ) 2) Naive way is to reserve a slot and simply put a pointer in there 3) Naive way works when there is no opcode cache, because then the extra data has to be regenerated everytime anyway (SLOW!) 4) Naive way works when the opcode cache does only work on a per process/thread basis, because then the pointer stays valid 5) Naive way FAILS when opcode cache stores data on disk and loads it back (pointer wrong, or process never generated the extra data) 6) Naive way FAILS when opcode cache shares data between processes (pointer wrong, ...) Now the idea was to create a solution for this problem that is compatible with all opcode cachers that follow some rules. Correct me if I am wrong, but I believed that op_arrays in shared memory cannot be used directly and usually have to be copied into the own address space to work on... If this is true then maybe the simplest idea would be to have some kind of suspend and resume functionality for op_arrays. When you put the op_array into the shared memory you call a suspend hook() extensions can register and when you read it from shared memory you call the resume() hook. This would be the simplest way, because then the extension could maybe clear its pointer in the extra slot so that it is NULL for the other process and then it knows inside the other process that it has to regenerate it for the other process. Or it simply regenerates the information from within the resume_hook(). I think this idea is pretty simple to implement. But my original idea was a little bit more complicated. I wanted that the suspend hook creates a binary data package (by extension) and that when the opcode cacher caches the binary data package it copies the data of the suspend hook into shared memory/writes it onto disk. On the other hand the resume hook will decode the extra data... To make it simple for the opcode cachers PHP could internally handle the whole combine data of extensions and split up data by extension stuff. So for opcode cachers they simply have to: 1) zend_suspend_op_array(op_array, *buffer, *size); 2) Store the extra data in buffer of size bytes together with the op_array 3) zend_resume_op_array(op_array, buffer, size); I know that there are some op_array() hooks for zend_extensions but I believe right now there is no way to hook I just came from some kind of shared memory (memory/disk/network) please fix me up so that I still work in your process Stefan Esser -- Stefan Esser SektionEins GmbH Tel. +49 175 6782326 Ober Buschweg 9a 50999 Köln [EMAIL PROTECTED] www.sektioneins.de SektionEins GmbH, Standort Köln Firmensitz: Ober Buschweg 9a, 50999 Köln Registergericht: Amtsgericht Köln, HRB 59920 Geschäftsführer: Johann-Peter Hartmann -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Storing additional information for op_arrays
Hi everyone, I would like to use this list to address the major players in bytecode caching tools: Zend, APC, Xcache... One problem I and others have run into is that from time to time we need to store extra information for specific opcode arrays. For simple values it is possible to use one of the reserved slots in the op_array structure, but in the past that has been unrelieable because APC for example simply overwrote the first slots without asking the Zend Engine to reserve some space. The next problem is that the amount of data you can store is not that big. Leaving a pointer in the reserved field is also not a good idea, because this will break as soon the opcode array is shared among processes or was stored on the disk. Therefore it would be great if we can come up with a modification of the op_array structure that allows extensions to append arbitrary sized data to an op_array, that gets also cached by all the opcode cachers... What do you think? Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Storing additional information for op_arrays
Derick Rethans schrieb: On Thu, 20 Sep 2007, Stefan Esser wrote: One problem I and others have run into is that from time to time we need to store extra information for specific opcode arrays. For simple values it is possible to use one of the reserved slots in the op_array structure, but in the past that has been unrelieable because APC for example simply overwrote the first slots without asking the Zend Engine to reserve some space. Have a pointer on how this is done? I sortof need/want to do this in Xdebug as well, however I don't want opcode caches to remember this value. Well the official way to use the reserved area of an opcode array is to get an handle from the zend engine for reserved space. This is done by ZEND_API int zend_get_resource_handle(zend_extension *extension) it returns an index you can simply use. (I think meanwhile APC will honor this and will not overwrite the first bytes). Sounds like a good idea to me - but the op code caches do need to some special trickery for this I guess. However, in my case I do *not* want an opcode cache to remember the stored data, so that perhaps needs to be taken into account as well The basic idea would be to add API functions like zend_op_array_add_data(key, data, size, flags) zend_op_array_remove_data()... zend_op_array_get_data, zend_op_array_get_all_data In the flags one could choose: Needs to be cached etc... Well and this will be stored in a datastructure that will just be pointed at by the op_array struct. So op_arrays will not really grow (just a single pointer added) and the whole overhead is only in the extensions that actually require such extra data and in the opcode caches that need to cache this. And I think the opcode cachers would just need to traverse the list of all data and store it with the op_array. I doubt that would take much changed in the cacher software. And well if the cache authors speak up, PHP can pretty much implement all the API functions required for such a step... Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_ini.h
Stanislav Malyshev schrieb: stas Thu Aug 2 23:57:21 2007 UTC Modified files: (Branch: PHP_5_2) /ZendEngine2 zend_ini.h Log: add stage for .htacces This change is great. However are there any plans to add a symbol or something else so that a PHP extension can detect the support for this feature at runtime? I see that this feature will be backported to older PHP 5 and even to PHP 4 used by linux/bsd distributions, because it is a required security fix. For extension developers this will be a problem unless there is some means of runtime detection, because the same PHP 4.4 extension is supposed to work with and without the fix (without recompilation). Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_ini.h
Hello, new stage won't ever work, of course. If there's an extension which uses INI_STAGE_ACTIVATE and needs to support new htaccess stage, it can be fixed in source so check for this stage too - but I didn't see such extensions yet. Well I actually know such an extension ;) It is called Suhosin. Well but that support was broken anyway. The sense of the INI_STAGE_ACTIVATE check was to give the admin the possibility to forbid groups of INI_PERDIR to be configured by htaccess. (without setting a default with php_admin_value in httpd.conf for all that should not be under user control.) Actually before your commit that of course never worked correctly and broke INI_PERDIR completely. Now with the new commit I can implement it correctly. However the problem stays that actual binary compatibility is not broken by the check but any extension relying on the new feature might not work correctly. However I think for my purposes I can simply define the INI_STAGE_HTACCESS constant if it does not exist and simply tell everyone to upgrade to a bugfixed version. Haha. Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/session session.c
Stanislav Malyshev schrieb:
That's nice. Could you now explain why you need these symbols in
session IDs?
Even Zend Platform used ':' in session IDs not long ago. Maybe recent
versions of Zend Platform don't, but that is not the point.
The point is YOU DON'T KNOW how many people use one of these characters
in session IDs. YOU DON'T KNOW how many people use the PHP session
management but use the session_id() function to provide their OWN
session identifier. After all THAT is the reason for the session_id()
function.
Now without any warning you set a bunch of characters on a blacklist.
For no real reasons, just to NOT encode them when sending them out in
the cookie.
Face it this will break backward compatibility and even if only one
single person would be affected by this, this BC break is completely
unecessary, because by encoding the ID it is possible to support all the
other characters.
And especially when the session id is something home generated that
directly comes out of base64 encoding it is very likely that it ends in
the character = which is forbidden by your blacklist.
OHH yeah and your invalid reason that these characters are forbidden in
cookie values is NONSENSE. First of all the Netscape Cookie 0 format
(which is the one used by PHP) clearly says that everything except
whitespace and semicolon is allowed and secondly just LOOK at the
cookies you have in your browser.
: = () ; these characters are used everywhere. A good start are your
*.google.com cookies they contain nearly all of these chars.
Stefan Esser
Stefan Esser wrote:
sesserSat Jun 16 07:47:46 2007 UTC
Modified files: /php-src/ext/sessionsession.c
Log:
Fix attribute injection security bug correctly by URL encoding
session name and session value. (in future maybe encode
path/domain, too)
Remove backward compatibility breaking blacklist of characters.
http://cvs.php.net/viewvc.cgi/php-src/ext/session/session.c?r1=1.472r2=1.473diff_format=u
Index: php-src/ext/session/session.c
diff -u php-src/ext/session/session.c:1.472
php-src/ext/session/session.c:1.473
--- php-src/ext/session/session.c:1.472Fri Jun 15 22:42:43 2007
+++ php-src/ext/session/session.cSat Jun 16 07:47:46 2007
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: session.c,v 1.472 2007/06/15 22:42:43 stas Exp $ */
+/* $Id: session.c,v 1.473 2007/06/16 07:47:46 sesser Exp $ */
#ifdef HAVE_CONFIG_H
#include config.h
@@ -398,7 +398,7 @@
int vallen;
/* check session name for invalid characters */
-if (PS(id) strpbrk(PS(id), \r\n\t '\\\()@,;:[]?={}%)) {
+if (PS(id) strpbrk(PS(id), \r\n\t '\\\)) {
efree(PS(id));
PS(id) = NULL;
}
@@ -1069,6 +1069,7 @@
{
smart_str ncookie = {0};
char *date_fmt = NULL;
+char *e_session_name, *e_id;
if (SG(headers_sent)) {
char *output_start_filename =
php_output_get_start_filename(TSRMLS_C);
@@ -1082,11 +1083,18 @@
}
return;
}
+
+/* URL encode session_name and id because they might be user
supplied */
+e_session_name = php_url_encode(PS(session_name),
strlen(PS(session_name)), NULL);
+e_id = php_url_encode(PS(id), strlen(PS(id)), NULL);
smart_str_appends(ncookie, COOKIE_SET_COOKIE);
-smart_str_appends(ncookie, PS(session_name));
+smart_str_appends(ncookie, e_session_name);
smart_str_appendc(ncookie, '=');
-smart_str_appends(ncookie, PS(id));
+smart_str_appends(ncookie, e_id);
+
+efree(e_session_name);
+efree(e_id);
if (PS(cookie_lifetime) 0) {
struct timeval tv;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dismantling the lies...
Well, php test suite is a functional test, so if the patch is done correctly it'd pass of course. I'm moe worried about the performance - my experience shows that the guesses are often wrong when talked about performance effects in complicated code. If you would have time to run a benchmark using something like bench.php and maybe some more complicated code, it'd be nice to know the result. bench.php is a totally unrealistic benchmark that has nothing todo with real life PHP applications. Of course when you call a function several million times the performance penalty will be big if you add code that executed with every function call. But in reality PHP applications don't call millions of functions. Most of the waiting time in PHP applications is waiting for disk/DB I/O operations. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dismantling the lies...
Stanislav Malyshev schrieb: Well yes. I think to solve this once and for all a public statement by the PHP group would be nice that says: I don't think they are not important, just that they are not important enough to want them fixed no matter the cost. Running shared hosted server in a mode that relies on restricted code IMO is wrong anyway, and for non-shared environment these problems could be exploited only if specifically enabled by very badly written code. So when there's a trade-off between having the language work better for 100% of cases or protect those who run broken code on their servers - the choice would be to make language run better. Again, that doesn't mean bugs shouldn't be fixed - just the fix shouldn't make the situation worse. Unfortunately we live in the real world, where people usually break into servers that run bad PHP code. And the more tight you make the OS, like CGI, separate user account, no write access to document root, chrooted document root,... The more obvious it becomes that local vulnerabilities matter. Because in such a environment you CANNOT break out of it with plain PHP code. You need to execute arbitrary machine code. Remote PHP Code Execution Vulnerabilities will not be dead when allow_url_include is installed and disabled everywhere. Just keep in mind that the most popular PHP worm ever (Santy) that exploited phpBB was attacking through the /e modifier of preg_replace(). Really Bad Code exists everywhere and admins have a very bad feeling in their stomach when they have to install PHP applications. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dismantling the lies...
Alexey Zakhlestin schrieb: the problem is, that, in this case, code is not broken. it is not an error to use large stack. it is an error to let someone use the low-level side-effects of a problem in a high-level language. Uhmm you only look at the MOPB #2 issue. The main point of this whole thread is however the performance impact through the #1 issue that does not depend on stack usage, but allows PHP userspace code to execute arbitrary machine code. The problem here is that some voices inside the PHP team and community claim that you can takeover the system through the execution of high level PHP code anyway and therefore using a local PHP vulnerability to execute arbitrary machine code would not be an issue. If you see it this way there is actually no reason to do this performance impact. However it should be obvious that I see this all a little bit different, because I think about defense in depth and realise that to attack tightly secured systems you NEED direct memory manipulation and/or execute arbitrary machine code. For example to get around non-executable HEAP situation you first need to poke the right offsets in memory to reenable the dl() function (NOT possible with plain PHP code), find some writeable diskspace, dump a shared library there and load it. From there you can execute whatever kernel exploit you want, to get for example out of the chroot, to disable SELINUX... And here is the problem with the OS hardening argument of the PHP developers. OS hardening is useless if I can use exploits in PHP to simply disable/get around this hardening. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dismantling the lies...
Well yes. I think to solve this once and for all a public statement by the PHP group would be nice that says: We are no longer wasting time fixing security problems in PHP4 that have already been addressed in the current version of PHP - PHP5 - So no further development time will be wasted on PHP4 :) This decision has been made to allow developers to move forward to get PHP6 out of the door ;) While this statement would be honest it does not solve the problem, that PHP 5 is also affected by security vulnerabilites that are only local and therefore WON'T FIX. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Dismantling the lies...
Hello, it is no secret that I am really sick and tired of this constant stream of nonsense and lies comming out of the mouths of PHP developers when it comes to security issues. In the other thread, where Stanislav spreads the usual lie/propaganda that there is no help comming from me to the PHP developers, he also claims that the MOPB issues #1 and #2 cannot be fixed right now. Xdebug, Suhosin, Hardening Patch have already demonstrated for years that it is not true that #2 [2] cannot be fixed without breaking binary compatibility. There have also been patches on this mailinglist that calculated the maximum depth automatically, therefore there is no need to dismantle this lie. The other lie however that MOPB issue #1 [1] is unfixable ends here... First of all everyone into PHP development knows that the obvious fix for this issue would be to just break binary compatibility and use a 32 bit reference counter. It does not fix the actual problem but it is enough so that it cannot be triggered anymore. The reason for this fix not being applied is not it's impossibility, but because the closed source extension developers (everyone knows who they are) don't want another binary compatibility break, because then their closed source extensions have to be shipped in yet another version. However there exists another fix to the problem that deals with the actual problem of an overflowing reference counter. Therefore every refcount increase in the Zend Engine Source has to be protected. While this sounds much of work it actually takes less than half an hour to do it. Here is the patch I created in approximately half an hour. A solution to a problem that is *NOT* fixable at the moment, according to Stanislav. http://www.hardened-php.net/patches/php-4.4.7-refcount-overflow-fix.patch.gz MD5: 0b558564d86b798651b69181920f9378 Stefan Esser Reference: [1] - reference counter overflow - http://www.php-security.org/MOPB/MOPB-01-2007.html [2] - deep recursion crash - http://www.php-security.org/MOPB/MOPB-02-2007.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
Dear Kevin, you are just ridiculous. Educate yourself WHO is responsible for improved PHP security. Stefan Esser This one time, at band camp, Stefan Esser [EMAIL PROTECTED] wrote: Stop flooding my inbox with your unqualified comments. You can write the patch yourself, can you? Or can't you? Then shut the fuck up. I'm not the one whining about nothing being done. This constant stream of dribble about PHP not being the way _you_ want it is pathetic. You seem to typify the open source community in a nutshell. WAA ITS NOT THE WAY I WANT IT!!! SOMEBODY FIX IT!!! The time and effort you have spent on this thread could really have been used for more constructive purposes, unless the purpose of these posts is to inflate your ego and that all should bow to your demands on you _you_ believe the PHP project should be adminstered, whilst deriding the good work and intensions of others. grow up. Kevin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dismantling the lies...
Cristian Rodriguez schrieb: Here is the patch I created in approximately half an hour. A solution to a problem that is *NOT* fixable at the moment, according to Stanislav. at openSUSE, we also have a patch for this issue since a few weeks, as a vendor unfortunately we have to take care of things that people here dont want to fix... http://www.flyspray.org/patches/MOPB-01-abicompatible.patch.bz2 I only see one major problem with this patch. You just call zend_error() when a possible integer overflow is detected. This is however not really safe. Refcount increases etc... are usually done deep in the engine and it is not ensured that in case of a bailout this cannot result in destruction of structures that were only partialy initialised. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
Christian, I suggest that you simply stop arguing with PHP developers about security issues. The problem is that they don't understand them. They are too arrogant. They actually believe they know everything better. In such a situation there is only one healing. Stop giving them tips and let them run against walls again and again. With the last X releases and the again and again introduced BC breaks and additional security bugs they have pissed off already many of their users. At the moment they are very predictable. You send them a security bug and first they try to tell you that you are totally wrong (because you made a mistake by sending them a non working example). Then you recommend a way to fix it. But don't expect that they are fixing it the way you tell them... They will do something else to prove that they outsmarted you. Yeah guess what their fix is of course not a solution and as usual fixes just one of the symptoms. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
I wonder if you actually aware of the fact that there's no such single entity as PHP developers and each of them is entirely different living human? And these humans sometimes are in disagreement and some of them are wrong? And then the thing called discussion happens and it's not always about conspiring against certain security researchers? There's no them. Try to think about it for a minute. Yes I think you do not need to repeat that there is no such thing as a PHP leadership. The reason number one why PHP development is chaotic and unprofessional. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
If you are aware of some security problems in current PHP sources you are as always welcome to report them and they will be fixed. I think everybody here as always are thankful for any help we can get. Ohh BTW. I am aware of many security problems in current PHP, actually the whole world is, because there are still a lot of local vulnerabilities unfixed that were disclosed during the MOPB. The ext/filter email issue is also not fixed in 5.2.2 And yes I know a bunch of bugs in PHP that were not disclosed during the MOPB. But what sense does it make to release them now, while a bunch of MOPB bugs are not yet fixed or were marked as fixed in the release notes of 5.2.2 but were not actually fixed. Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
Stanislav Malyshev schrieb: Yes I think you do not need to repeat that there is no such thing as a PHP leadership. I don't need to repeat it because I never said that and it's not true. There's difference between leadership and not having disagreement or discussion, even if some fail to see it. Everyone watching the PHP internals list can see how true it is. One war after another, because some PHP developers are more equal than others. It depends on the status of the maintainers if beta/alpha extensions are merged into the core. (ext/filter) or if they are refused. The whole filter problematic is still unsolved. The filter hooks were still not moved into php_register_variable_ex so that they cannot be bypassed by mistake of a 3rd party PHP extension that implements another POST content-type. And ext/filter still does no daisy chaining of the filter hooks... Let's not forget that the typical internals discussion is that some Zend employee steps in and believes he is a leader and makes the decisions. (Hello Antony). And this happens because there is NO leader that steps in. (Hello PHP Group) Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
Stanislav Malyshev schrieb: What you see as a war, other see as a discussion. I think if you tried viewing it as figuring out common solution and discussing options and not combat it would make sense to you too, probably. Maybe I read a different internals list. Just read the World vs. Pierre thread. While some things in there are quite true, it is completely agressive towards Pierre. I think it would be better to describe the problems you see with filters in separate email and in more detail, since I have a feeling not everybody would be following this discussion closely. And I think I repeated myself often enough. I have a feeling that this somehow implies being Zend employee disqualifies person from discussing matters and making decisions. One weird position, I'd say. No it implies that Zend employees believe they have a special status because they work for Zend. Just look at Antony and his aggressive attitude to dictacte what others should do or should not do. Recent example: Antony vs. Pierre. Antony is very fast with assigning bugs to persons that have nothing todo with them. I believe there is still a bug assigned to me because in Antony's world I am responsible for it, while infact my commit was in a version AFTER the one the problem was reported for. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
Stanislav Malyshev schrieb: So here we go again - a lot of time spent to write lengthy emails about how bad this and that person or PHP Group as a whole is, or to hint about multiple problems without getting into details - and when it comes to details - no, that's no fun anymore. Should we open [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Stanislav, you are a liar. Enough said. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: access to variables
Hello, zend_hash_find(Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]), DOCUMENT ROOT, sizeof(DOCUMENT ROOT), data); strcpy(buffer, Z_STRVAL_P(data); It is called DOCUMENT_ROOT, not DOCUMENT ROOT... -sesser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: access to variables
Ci schrieb:
Stefan Esser napisał(a):
Hello,
zend_hash_find(Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]),
DOCUMENT ROOT, sizeof(DOCUMENT ROOT), data);
strcpy(buffer, Z_STRVAL_P(data);
It is called DOCUMENT_ROOT, not DOCUMENT ROOT...
It was mistake in rewriting. If I choose any php variable, such as
DOCUMENT_ROOT, SERVER_NAME I got data in buffer like: '`5u', '1x'.
Is that method of getting variable correct?
No. The correct way for getting the variable is
zval **data;
...
if (zend_hash_find(Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]),
DOCUMENT_ROOT, sizeof(DOCUMENT_ROOT), data)==SUCCESS) {
...
strlcpy(buffer, Z_STRVAL_PP(data), sizeof(buffer));
}
-sesser
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A request for code change : Repeated opening and closing the session leads to a LOT of Set-Cookie headers.
Hello Richard,
your problem is a bug in the session extension.
My suggested but not tested workaround is that you simply call
ini_set(session.use_cookies, 0);
after the first time you call session_write_close(). This will stop the
session extension from sending further cookies during a single request.
Stefan Esser
Richard Quadling schrieb:
Hi.
I have a webapp which uses Ajax to initiate a process on the server
which could take several minutes to complete and will go through many
steps to before the task is finished.
In that script, I update the session to indicate the current position
of the process.
When the user initiates the main process, another AJAX request is made
which examines the state of the main process (via the session) and
reports back to the client - keeps them interested. The user can also
abort the process and closing the browser also triggers an abort.
All works FINE in FF. In IE, I'm getting a Page cannot be displayed
sort of errror (having to debug the response to see this). This SEEMS
to relate to the fact that I am closing and opening the session in the
first script as I want to keep the session file uptodate. The process
script only has 1 output and that is the final result at the end of
the script.
I also tested this using a telnet connection to the webserver and sent
the same headers that FireFox generated (captured via FireBub) and it
bombed just before the data arrived (Lost connection).
e.g.
?php
function UpdateSession($s_Progress) {
session_start();
$_SESSION['Progress'] = $s_Progress;
session_write_close();
}
//Stage 1
UpdateSession('Loading preferences');
...
//Stage 10
UpdateSession('Report generated and is now available at a href=' .
MakeWebPath(realpath($s_PDFReport)) . 'here/a.');
echo rawurlencode(json_encode(array('SUCCESS' =
MakeWebPath(realpath($s_PDFReport);
?
As a consequence, I get ...
Set-Cookie: PHPSESSID=uWPNRja2oT0PHPDCLqUiMzXiz1b; path=/
Set-Cookie: PHPSESSID=uWPNRja2oT0PHPDCLqUiMzXiz1b; path=/
Set-Cookie: PHPSESSID=uWPNRja2oT0PHPDCLqUiMzXiz1b; path=/
...
LOTS of times followed by a Page cannot be displayed. If I use
Ethereal to examine the data, it is all there and is the same via IE
and FF, it is just the IE doesn't like the REALLY long header.
I accept this is normal behaviour and IE should deal with it, but ...
Is there any mileage in stopping session_start from sending the same
header if it has already been sent? If the PHPSESSID is different,
then fine, send it.
From looking at session.c and php_session.h, I think the following
changes would suffice.
1 - The typedef struct _php_ps_globals {} needs to include ...
char *prev_id;
2 - In PHP_GINIT_FUNCTION(ps) ...
ps_globals-prev_id = NULL;
3 - In php_session_send_cookie(TSRMLS_D), do a comparison of prev_id
and id (taking into account prev_id could be NULL) and if different,
then allow the cookie to be set and to update prev_id with the id
sent.
Some other issues, if other parts of the cookie are altered, then
maybe rather than just examining the ID, the entire cookie should be
remembered.
Assuming that the cookie would be identical, repeatedly sending it to
the client when the session is repeatedly opened is a pain and I think
can easily be fixed.
Thank you for your time.
Richard Quadling.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
It should be noted, that the PHP Group is not allowed to give anyone the right to use PHP in it's product name. If they do so they violating the Open Source Definition http://www.opensource.org/docs/definition.php#5 Any kind of discrimination against anyone is not allowed. Giving some people special rights, like allowing them to use the name PHP in their Products name, while other parties are not allowed is clearly in violation with the discrimination paragraph... But that is old news. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
I wonder what discrimination means in your world. In my world, this clause means that OS license can not put forth specific personal or group conditions for receiving the license, such as belonging or not belonging to ethnicity, race, religion, sex, political party, etc. Stanislav, I know that you like to enforce your idea of what a word means on others, but the word *discrimination* comes from the Latin discriminare, which means to distinguish between. Discrimination means ANY kind of different treatmeant of different groups of people. There is one group that gets permission and another group that does not get permission. There's another part of this too. The OSI lists the PHP license under their list of approved licenses. It would stand to reason that they don't see it as conflicting with their definition of Open Source. Yeah well, I am waiting for their comment about this issue. Beside the fact that the License can still be OSI conform as long the PHP group does not give anyone a special treatmeant. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
Hello Marcus, that's plain wrong what you wrote. First PHP license is OSI Approved and for that defintively does not violate any OSI recommendation. Besides that We will see how OSI explains how a discriminating license can be OSI approved. read the paragraph again and again. You will eventually find out that the act of disallowing to use the term php in any of their names to whomever by the php-group does not violate definition part 5. In fact that tells you that php-group must allow anyone to contribute, which they do. Noone has I suggest that you read it again and again: The license must not discriminate against any person or group of persons. This means the license MUST NOT have different rules for different kinds of people. Those in favour of PHP Group and those not. any term in any license means some restiction that only applies to certain people. ups. This is plain nonsense. Other licenses pretty much make it clear that ANYONE has to follow the same rules. p.s.: Instead of discussing stuff that is better of with layers you guys should contribute to open sourcein the spirit of open source... The spirit of open source is NOT that those in favour of the PHP Group can abuse the PHP Project for whatever they want. Like advertise their own companies. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
It's a bit of an edge case. I don't think I ever really considered CSS as being part of the PHP source code, but I suppose technically it is. Like I previously stated. The phpSecInfo program does not only steal PHP code and uses PHP in it's name, it also steals the layout of phpinfo, including the PHP.net logo+link. This is actually no suprise. The marketing consortium aka. PHP Security Consortium does everything to look endorsed by PHP.net. They also stole the PHP.net favicon for phpsec.org And the only reason noone goes against this is because these people are friends of the members of the PHP group. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
http://phpsec.org/images/phpsecinfo_ss.png Yes it is exactly what I am talking about 1) CSS code is directly stolen from PHP source code (PHP licensed code) 2) Output functions are directly converted from C to PHP code 3) The PHP logo is used although it is clearly in violation with http://www.php.net/download-logos.php / Logo Licensing ... If in doubt, ask mailto:[EMAIL PROTECTED]. However you should not use the logo in such a way, that it suggests that a particular person, company, course, etc. is endorsed by PHP.net. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
Stanislav, you obviously did not get the point... It is not about including URL stream wrappers that youself provide. It is about URL Include vulnerabilities in the application that allow remote attackers to issue attacks against Userstreams of the application. I would not be suprised to see some Wrapper Userstream that actually allows specifying a remote URL (something like php://filter just as userstream). And If I am not completely mistaken here unlike php://filter a userstream will not give the THIS_IS_AN_INCLUDE_FLAG down to a stream itself opens. PS: Don't tell me that userstreams are not available at the time of the include... I have seen enough stuff like include base.lib.php; ... include $templatepath./header.php; ... include $templatepath./footer.php; Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
Greg, i was not talking about providing all the different versions of include. For me it is a broken application design to include anything out of an URL wrapper. However it would also be fine to just have allow_url_include affect all URLs and to be setable by ini_set() and be turned off by default. Insane applications can then turn it on/off for every REMOTE URL they need. Aside from that there could be a setting for the admin to completely disallow URLs marked as is_URL. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
Mathieu CARBONNEAUX schrieb: http://us2.php.net/manual/en/ref.pdo.php#pdo.prepared-statements Sorry for my buz... This piece of manual say the same i've said... Yeah and it is wrong. The manual claims the following: The parameters to prepared statements don't need to be quoted; the driver handles it for you. If your application exclusively uses prepared statements, you can be sure that no SQL injection will occur. (However, if you're still building up other parts of the query based on untrusted input, you're still at risk). While it is true that the PHP script is not subject to SQL injection when the application does not build parts of the query based on untrusted userinput it is not true that you are not at risk. Ever heard of stored procedures? And precisely of SQL injection in stored procedures? Prepared statements can do nothing about SQL Injection in Stored Procedures. And if you teach people that they only should use prepared statements they will NEVER know that it is dangerous to put userinput into the query. And aside from that they have never learned how to do it correctly if there is ever a situation where they have to do it. But i repeat, i thing a security (or a good dev practice portal) portal is a good freind of the manual and can be abel to level up the security of php dev app... There are enough secure programming examples by so called experts around that are vulnerable to different kind of attacks. Do you really believe a community portal by complete strangers can provide reliable security documentation? And is bad for the php image... It is very good that bugs in PHP Applications are bad for PHP's image. The majority of servers get hacked because of Remote URL Includes (and not by XSS/SQL Injection). The existance of Remote URL Includes is fully to blame on the PHP engine and is UNIQUE. After years the feature is still not kicked out of PHP. In PHP 5.2.1 there will be a configuration option that activates an (incomplete) blacklist. Everyone should know by now that blacklists are BAD. On this portal i thing also be interesant log php alert in more friendly way... You mean like using marketing tricks to make security bugs look less serious? Stefan Esser Hardened-PHP Project -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
I am not sure I would call it a blacklist. It is a flag in the streams layer that marks stream handlers that could possibly make a network connection as such and there are only a finite set of stream handlers. Unfortunately there is not a finite set of stream handlers. First of all there are userstreams. An application could register a dangerous userstream (that is of course not marked as URL) which is then abused by an include. Then there are PECL extensions that register streams. Just pick a random one: Let's take ext/ssh2. This is not just any pecl extension, but one from a PHP core developer. SSH is obviously a network protocol. The PHP documentation even states that SSH streams are forbidden during allow_url_fopen. However from looking at the code I assume this documentation is wrong, because I see all is_url flags being set to 0. Voila, just install pecl/ssh and you are still vulnerable to remote file includes. That is the problem with opt-in/aka blacklist methods. Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
My 2cents, the actually best would be to completely forbid the usage of URLs inside include/require and introduce a new keyword: include_url that works like the current include would work and rename allow_url_include into allow_dangerous_urls (for include_url only). Basically this would protect everyone from URL includes with no way around and if someone really really wants this dangerous feature he has to explicitly request it via include_url. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
