On Thu, 18 Nov 2010 00:20:11 -, Pierre Joye
wrote:
If there is no objection I like to apply this patch to 5.3 tomorrow
morning (Europe) so we have it in for 5.3.4RC1. Please raise your
concerns until then. At the very least we can always revert it after
RC1.
Note the patch broke severa
hi,
Patch applied in 5.3. I will do in trunk next week.
Cheers,
On Mon, Nov 15, 2010 at 11:42 AM, Rasmus Lerdorf wrote:
> Ok, I went through all the 5.3 code. This should fix the null poisoning
> problems in 5.3 without breaking binary compatibility:
>
> http://progphp.com/nullpatch.txt
>
> Th
On Tue, 2010-11-16 at 10:29 +0100, Johannes Schlüter wrote:
> On Mon, 2010-11-15 at 02:42 -0800, Rasmus Lerdorf wrote:
> > Ok, I went through all the 5.3 code. This should fix the null poisoning
> > problems in 5.3 without breaking binary compatibility:
> >
> > http://progphp.com/nullpatch.txt
>
hi,
If there is no objection I like to apply this patch to 5.3 tomorrow
morning (Europe) so we have it in for 5.3.4RC1. Please raise your
concerns until then. At the very least we can always revert it after
RC1.
Cheers,
On Mon, Nov 15, 2010 at 11:42 AM, Rasmus Lerdorf wrote:
> Ok, I went throug
Is this related to http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/ ?
That's a quiet old bug, I'm happy to listen it's now worked on and has a patch.
J.Pauli
On Tue, Nov 16, 2010 at 12:34 PM, Pierre Joye wrote:
> hi,
>
> On Tue, Nov 16, 2010 at 7:15 AM, Rasmus Lerdorf wrote:
>> On 1
hi,
On Tue, Nov 16, 2010 at 7:15 AM, Rasmus Lerdorf wrote:
> On 11/15/10 10:12 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> Well, it changes the signature of that function, so while we don't break
>>> backward binary compatibility, we break forward compatibility within the
>>> 5.3 branch. As in, if I
On Tue, Nov 16, 2010 at 6:07 AM, Stas Malyshev wrote:
> Hi!
>
>> Yeah, I thought about that too. Still not something we can do without
>> breaking binary compatibility in the 5.3 branch though and I really
>> would like to at least get all the core functions to guard themselves
>> against null-po
On 11/16/10 1:44 AM, Derick Rethans wrote:
> On Mon, 15 Nov 2010, Rasmus Lerdorf wrote:
>
>> Ok, I went through all the 5.3 code. This should fix the null poisoning
>> problems in 5.3 without breaking binary compatibility:
>>
>> http://progphp.com/nullpatch.txt
>>
>> There are quite a few places
On Mon, 15 Nov 2010, Rasmus Lerdorf wrote:
> Ok, I went through all the 5.3 code. This should fix the null poisoning
> problems in 5.3 without breaking binary compatibility:
>
> http://progphp.com/nullpatch.txt
>
> There are quite a few places where we can't solve it centrally, so
> perhaps we
On Mon, 2010-11-15 at 02:42 -0800, Rasmus Lerdorf wrote:
> Ok, I went through all the 5.3 code. This should fix the null poisoning
> problems in 5.3 without breaking binary compatibility:
>
> http://progphp.com/nullpatch.txt
I didn't check it as I'm on vacation traveling right now, but: Does the
Yes, you could say that users should just know to filter, and if we were
able to pass the binary string through and had binary-safe filesystem
calls, I could agree that we wouldn't need to do anything, but the
current default of truncating at the null byte is dangerous.
Compare these:
% echo '/et
hi,
don't we have ext/filter that should check all the dangerous input
strings? It would be useless to perform additional checks for constant
stings known at compile time (e.g. on include "foo.php")
Thanks. Dmitry.
Rasmus Lerdorf wrote:
On 11/15/10 10:12 PM, Stas Malyshev wrote:
Hi!
Well
On 11/15/10 10:12 PM, Stas Malyshev wrote:
> Hi!
>
>> Well, it changes the signature of that function, so while we don't break
>> backward binary compatibility, we break forward compatibility within the
>> 5.3 branch. As in, if I change my extension to use this new NoNull
>> string flag, it will
Hi!
Well, it changes the signature of that function, so while we don't break
backward binary compatibility, we break forward compatibility within the
5.3 branch. As in, if I change my extension to use this new NoNull
string flag, it will no longer work on<5.3.3 whereas if I do the
if(strlen(fil
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Monday, November 15, 2010 9:25 PM
> To: Andi Gutmans
> Cc: Stas Malyshev; internals
> Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
>
> Well, it changes the si
On 11/15/10 9:16 PM, Andi Gutmans wrote:
>> -Original Message-
>> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
>> Sent: Monday, November 15, 2010 8:21 PM
>> To: Rasmus Lerdorf
>> Cc: internals
>> Subject: Re: [PHP-DEV] Adding path_len to al
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Monday, November 15, 2010 8:21 PM
> To: Rasmus Lerdorf
> Cc: internals
> Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
>
> Hi!
>
> > Ok, I wen
Hi!
Yeah, I thought about that too. Still not something we can do without
breaking binary compatibility in the 5.3 branch though and I really
would like to at least get all the core functions to guard themselves
against null-poisoning there.
How adding a new option char to zend_parse_paramete
On 11/15/10 8:21 PM, Stas Malyshev wrote:
> Hi!
>
>> Ok, I went through all the 5.3 code. This should fix the null poisoning
>> problems in 5.3 without breaking binary compatibility:
>>
>> http://progphp.com/nullpatch.txt
>
> Looking at this patch, I wonder if it wouldn't be cleaner to add new
>
Hi!
Ok, I went through all the 5.3 code. This should fix the null poisoning
problems in 5.3 without breaking binary compatibility:
http://progphp.com/nullpatch.txt
Looking at this patch, I wonder if it wouldn't be cleaner to add new
type (string without nulls) in parameter parsing and have
hi Rasmus,
Thanks for the patch! It is great for 5.3 (this problem has been an
issue for too long already).
However I would like to change the APIs in trunk accordingly to avoid
to have checks in every single place where path are used, and indeed
to avoid to have bugs in new codes. In short, it s
Ok, I went through all the 5.3 code. This should fix the null poisoning
problems in 5.3 without breaking binary compatibility:
http://progphp.com/nullpatch.txt
There are quite a few places where we can't solve it centrally, so
perhaps we need to take the same approach in trunk.
This should take
Right, but the root of the problem is where to do the invalidation check
of bogus file path strings. Like checking for bogus null bytes in them.
Right now:
file_exists($file . '.txt');
and
file_exists($file);
will check the same file if $file has a \0 stuck onto the end. This can
lead to secur
Hi Rasmus,
Hope I understood the problem correctly. If not, this answer won't make sense :)
I do not see a major problem in passing path_len but wonder how much it'd
actually solve as we end up calling OS APIs that do not accept path_len, no? I
assume we don't want to start searching all these s
24 matches
Mail list logo
