Hi Jan,
On Thu, Feb 26, 2015 at 8:15 AM, Jan Ehrhardt 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
> >used in you
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 Sma
On 25 February 2015 at 23:00, Stanislav Malyshev 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 - like Smarty
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
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.
>
Hi Jan,
On Thu, Feb 26, 2015 at 6:55 AM, Jan Ehrhardt 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 "zend.scri
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_
Hi Jan,
On Thu, Feb 26, 2015 at 12:07 AM, Jan Ehrhardt 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 users
Hi Kevin,
On 25 February 2015 at 08:18, Kevin Ingwersen (Ingwie Phoenix)
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 and some Nginx
> config
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, provi
Hi Lester,
On Wed, Feb 25, 2015 at 6:52 PM, Lester Caine 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 restrictions
> that WILL b
On 25/02/15 09:14, Yasuo Ohgaki wrote:
> Hi all,
>
> On Wed, Feb 25, 2015 at 5:58 PM, Lester Caine 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
Hi Kevin,
On Wed, Feb 25, 2015 at 6:08 PM, Yasuo Ohgaki 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 get it
>> counte
Hi Jan,
On Wed, Feb 25, 2015 at 5:31 PM, Jan Ehrhardt 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 malware".
I'm
Hi all,
On Wed, Feb 25, 2015 at 5:58 PM, Lester Caine 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, but apparently
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 configu
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 man
Yasuo Ohgaki in php.internals (Wed, 25 Feb 2015 07:54:01 +0900):
>On Wed, Feb 25, 2015 at 7:26 AM, Stanislav Malyshev
>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 misunderstan
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 t
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...@gm
Hi Stas,
On Wed, Feb 25, 2015 at 12:19 PM, Stanislav Malyshev
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 also.
>
> Thi
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
On Wed, Feb 25, 2015 at 9:59 AM, Yasuo Ohgaki 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 Stas,
On Wed, Feb 25, 2015 at 9:52 AM, Stanislav Malyshev
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 include and
Hi
On Wednesday, February 25, 2015, Stanislav Malyshev
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 LOL
> valida
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 t
Hi Dan,
On Wed, Feb 25, 2015 at 9:38 AM, Dan Ackroyd wrote:
> On 25 February 2015 at 00:09, Pádraic Brady
> 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 n
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 t
Hi Dan
On Wednesday, February 25, 2015, Dan Ackroyd wrote:
> On 25 February 2015 at 00:09, Pádraic Brady > 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
On 25 February 2015 at 00:09, Pádraic Brady 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:
http://php.webtutor.pl/en/2011/05/13/p
Hi Stas,
On Wed, Feb 25, 2015 at 8:25 AM, Stanislav Malyshev
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? Of course o
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 inv
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
>
Hi,
On 24 February 2015 at 22:07, Stanislav Malyshev 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 something.phar,
> afaik
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 understa
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 movin
Hi Stas,
On Wed, Feb 25, 2015 at 7:53 AM, Yasuo Ohgaki 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. Thank you.
>
O
Hi Stas,
On Wed, Feb 25, 2015 at 7:26 AM, Stanislav Malyshev
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 time by noti
Hi Stas,
On Wed, Feb 25, 2015 at 7:31 AM, Stanislav Malyshev
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 ".php"
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 defau
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 ex
Hi Stas,
On Wed, Feb 25, 2015 at 7:07 AM, Stanislav Malyshev
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 something.phar,
> afai
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 Stas,
On Wed, Feb 25, 2015 at 5:33 AM, Pádraic Brady
wrote:
> On Tuesday, February 24, 2015, Stanislav Malyshev
> wrote:
>
>> Hi!
>>
>> > Will it add a significant level of protection? No.
>> >
>> > Does it add protection? Yes.
>> >
>> > Each time we add some incremental security hardening,
Hi
On Tuesday, February 24, 2015, Stanislav Malyshev
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, if th
45 matches
Mail list logo
