Yasuo Ohgaki in php.internals (Wed, 25 Feb 2015 19:07:05 +0900):
I understand people do all kinds of things.
Therefore, I'm allowing
ini_set('zend.script_extension', ''); // Disable protections at all.
It's users choice if they use systematically secure configuration or not.
However, providing
Hi Kevin,
On 25 February 2015 at 08:18, Kevin Ingwersen (Ingwie Phoenix)
ingwie2...@googlemail.com wrote:
Here are my cents to this RFC, as it just keeps popping in in my inbox and
its beginning to be one that I wish I could ignore.
First, … file extensions? A default Apache configuration
Hi Jan,
On Thu, Feb 26, 2015 at 12:07 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Yasuo Ohgaki in php.internals (Wed, 25 Feb 2015 19:07:05 +0900):
I understand people do all kinds of things.
Therefore, I'm allowing
ini_set('zend.script_extension', ''); // Disable protections at all.
It's
Yasuo Ohgaki in php.internals (Thu, 26 Feb 2015 06:20:46 +0900):
I probably don't understand your question. We already have php_value and
php_admin_value to change INI value in .htaccess (and like).
php_value zend.script_extensions .php .myext # Works like globals
ini_set()
php_admin_value
Hi Jan,
On Thu, Feb 26, 2015 at 6:55 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Yasuo Ohgaki in php.internals (Thu, 26 Feb 2015 06:20:46 +0900):
I probably don't understand your question. We already have php_value and
php_admin_value to change INI value in .htaccess (and like).
php_value
Stanislav Malyshev in php.internals (Wed, 25 Feb 2015 15:00:21 -0800):
This is only a minor detail, compared with the other PHP7 changes.
Not that minor actually since you'd have to enumerate all extensions
used in your app, which can use libraries, which may use other
extensions - like Smarty
Yasuo Ohgaki in php.internals (Thu, 26 Feb 2015 07:18:59 +0900):
If you already have this feature, then you are promoting the RFC the
wrong way. You are constantly hammering on ini_set() to mitigate the
effects of the change. That would cause a lot of code changes for many
frameworks.
Yes we
On 25 February 2015 at 23:00, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
This is only a minor detail, compared with the other PHP7 changes.
Not that minor actually since you'd have to enumerate all extensions
used in your app, which can use libraries, which may use other
extensions -
Hi!
This is only a minor detail, compared with the other PHP7 changes.
Not that minor actually since you'd have to enumerate all extensions
used in your app, which can use libraries, which may use other
extensions - like Smarty or some other template library - and it may be
non-trivial to find
Hi Jan,
On Thu, Feb 26, 2015 at 8:15 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Stanislav Malyshev in php.internals (Wed, 25 Feb 2015 15:00:21 -0800):
This is only a minor detail, compared with the other PHP7 changes.
Not that minor actually since you'd have to enumerate all extensions
Hi Jan,
On Wed, Feb 25, 2015 at 5:31 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Google for java malware and you'll find things like
http://www.javaworld.com/article/2104862/java-security/report-half-of-all-exploits-target-java.html
Thank you for the info.
We are talking about image based
Hi Kevin,
On Wed, Feb 25, 2015 at 6:08 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Your PHP code is only so secure as you make it. If you are in need for
such an RFC just to block a few „rare cases“, then I would rather suggest
you to either check your source or hand it to a professional to
On 25/02/15 09:14, Yasuo Ohgaki wrote:
Hi all,
On Wed, Feb 25, 2015 at 5:58 PM, Lester Caine les...@lsces.co.uk wrote:
As soon as you have any possibility of including a file uploaded by an
attacker, you are probably going to lose.
I think that this is perhaps the key here.
I
Hi Lester,
On Wed, Feb 25, 2015 at 6:52 PM, Lester Caine les...@lsces.co.uk wrote:
Totally understand what you are trying to do, and if the users you are
trying to protect actually downloaded PHP direct from the PHP site it
may stand a chance of actually doing that, but it's adding
Here are my cents to this RFC, as it just keeps popping in in my inbox and its
beginning to be one that I wish I could ignore.
First, … file extensions? A default Apache configuration and some Nginx
configurations actually accept more than one file extension. This RFC does not
include any way
On 25/02/15 00:38, Dan Ackroyd wrote:
As soon as you have any possibility of including a file uploaded by an
attacker, you are probably going to lose.
I think that this is perhaps the key here.
My framework for new sites requires a user to log in before they can
upload anything. So if your
Hi Kevin,
On Wed, Feb 25, 2015 at 5:18 PM, Kevin Ingwersen (Ingwie Phoenix)
ingwie2...@googlemail.com wrote:
Here are my cents to this RFC, as it just keeps popping in in my inbox and
its beginning to be one that I wish I could ignore.
First, … file extensions? A default Apache
Hi all,
On Wed, Feb 25, 2015 at 5:58 PM, Lester Caine les...@lsces.co.uk wrote:
As soon as you have any possibility of including a file uploaded by an
attacker, you are probably going to lose.
I think that this is perhaps the key here.
I thought it's rather obvious how this RFC works,
Yasuo Ohgaki in php.internals (Wed, 25 Feb 2015 07:54:01 +0900):
On Wed, Feb 25, 2015 at 7:26 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
No other languages have such malware.
Are you seriously claiming there is no malware written in languages
besides PHP? It can not be, I must be
Hi
On Tuesday, February 24, 2015, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Will it add a significant level of protection? No.
Does it add protection? Yes.
Each time we add some incremental security hardening, we make it a bit
harder to create vulnerabilities. In this case,
Hi Stas,
On Wed, Feb 25, 2015 at 5:33 AM, Pádraic Brady padraic.br...@gmail.com
wrote:
On Tuesday, February 24, 2015, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Will it add a significant level of protection? No.
Does it add protection? Yes.
Each time we add some incremental
Hi!
require('cuteponies.gif) wouldn't work with this RFC.
move_uploaded_files() prohibits uploading PHP script.
You seem not to be reading the scenario. The include URL would be
phar://cuteponies.gif/pwnd.php and the uploaded file would be
cuteponies.gif. Your protection would not stop moving
Hi,
This RFC benefits may not be obvious for people on this list, but this
RFC eliminates certain type of PHP malware. PHP's script inclusion
I can't think of any type of PHP malware that would be eliminated. At
most, the malware injection protocols have to be slightly modified to
work
Hi Stas,
On Wed, Feb 25, 2015 at 8:25 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
As far as I know, PHP is the only language that has this type of malware.
(Script embedded images) PHP is the only one malware vendors claims
it as PHP malware. This is the fact.
Which type is that?
Hi!
They'd need to upload with a matching file type. Instead of any file
Not sure what you mean by that. phar can read tars, etc. AFAIK, can't
it? Also, phar archive has no requirement of being named something.phar,
afaik can be also named cuteponies.gif. E.g., I just did this:
1. Created file
Hi!
- require/include only includes .php .phar by default.
This is not true. As I repeatedly point out, your change only requires
that the string passed to include would end in .php, but string passed
to include and filename on filesystem are very different things, they do
not have to be the
Hi
On Wednesday, February 25, 2015, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Your example omitted the image validation step which would have
Ah, right, and if I name it .zip, it'd be zip validation, and if I name
it .pdf it'd be pdf validation, and if I name it .lol that would be
On Wed, Feb 25, 2015 at 9:59 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Are you saying current PHP allows
include('zip://...') or include('input://...')?
Correction. include('input://..') should be include('php://input') (and
like)
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi,
On 24 February 2015 at 22:07, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
They'd need to upload with a matching file type. Instead of any file
Not sure what you mean by that. phar can read tars, etc. AFAIK, can't
it? Also, phar archive has no requirement of being named
Hi Stas,
On Wed, Feb 25, 2015 at 9:52 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
- require/include only includes .php .phar by default.
This is not true. As I repeatedly point out, your change only requires
that the string passed to include would end in .php, but string passed
to
Hi!
I think he means matching file extension. File extension should
represent file type, though.
You can not rely on that. I can name files anything regardless of what's
in the file.
Since pwnd.php has .php extension, move_uploaded_file() refuses to
move it
to upload dir by default.
Hi!
That was indeed my point as Yasuo has already explained earlier. Image
validation would however see a phar a mile off.
How much would you bet against the possibility of a file existing that
can both pass as an image file of some type and as a valid zip or tgz or
tar file? Hint: don't go
Hi!
Your example omitted the image validation step which would have
Ah, right, and if I name it .zip, it'd be zip validation, and if I name
it .pdf it'd be pdf validation, and if I name it .lol that would be LOL
validation. You'd have to manually validate every type in existence and
somehow
On 25 February 2015 at 00:09, Pádraic Brady padraic.br...@gmail.com wrote:
Your example omitted the image validation step which would have
noticed your attempt to upload a phar immediately. Add that and try
again.
Image validation is no defense against this type of attack:
Hi Stas,
On Wed, Feb 25, 2015 at 7:26 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
I would like to add a note for this.
Anti Virus products are detecting this type of files as PHP malware.
It looks like you are trying to convince me that PHP malware exists. I
would like to save you
Hi Stas,
On Wed, Feb 25, 2015 at 7:31 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
I think he means matching file extension. File extension should
represent file type, though.
You can not rely on that. I can name files anything regardless of what's
in the file.
Since pwnd.php has
Hi Dan
On Wednesday, February 25, 2015, Dan Ackroyd dan...@basereality.com wrote:
On 25 February 2015 at 00:09, Pádraic Brady padraic.br...@gmail.com
javascript:; wrote:
Your example omitted the image validation step which would have
noticed your attempt to upload a phar immediately. Add
Hi!
I would like to add a note for this.
Anti Virus products are detecting this type of files as PHP malware.
It looks like you are trying to convince me that PHP malware exists. I
would like to save you time by notifying you I am aware of this. My
disagreement is not denying PHP malware
Hi Stas,
On Wed, Feb 25, 2015 at 12:19 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Are you saying current PHP allows
include('zip://...') or include('input://...')?
Neither zip not phar are classified as url handlers. Both have is_url to 0.
Then this is serious bug. I'll fix it
Hi!
I have to at least php://
php://input or php://stdin
allows attacker script execution via POST if it's allowed
by allow_url_include=On.
allow_url_include=On means it's allowed. That's what on setting is
for. Production setting should always be off.
--
Stas Malyshev
smalys...@gmail.com
Hi!
Are you saying current PHP allows
include('zip://...') or include('input://...')?
Neither zip not phar are classified as url handlers. Both have is_url to 0.
Then this is serious bug. I'll fix it also.
This would be another big BC break, as this would mean you can not use
phar streams
Hi Stas,
On Wed, Feb 25, 2015 at 7:07 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
They'd need to upload with a matching file type. Instead of any file
Not sure what you mean by that. phar can read tars, etc. AFAIK, can't
it? Also, phar archive has no requirement of being named
Hi Stas,
On Wed, Feb 25, 2015 at 7:53 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
require('cuteponies.gif) wouldn't work with this RFC.
move_uploaded_files() prohibits uploading PHP script.
I noticed that I should forbid destination file extension also by this
discussion.
I'll add it soon.
Hi!
As far as I know, PHP is the only language that has this type of malware.
(Script embedded images) PHP is the only one malware vendors claims
it as PHP malware. This is the fact.
Which type is that? Of course only malware in PHP can be presented as
PHP malware, but I don't understand why
Hi Dan,
On Wed, Feb 25, 2015 at 9:38 AM, Dan Ackroyd dan...@basereality.com wrote:
On 25 February 2015 at 00:09, Pádraic Brady padraic.br...@gmail.com
wrote:
Your example omitted the image validation step which would have
noticed your attempt to upload a phar immediately. Add that and
Hi all,
I wrote patch and made adjustment in the RFC
https://wiki.php.net/rfc/script_only_include
https://github.com/php/php-src/pull/
Where to check filename extension is subject to be changed.
At first, I thought implementing this as PHP code is good, but
I've changed my mind. It seems
46 matches
Mail list logo
