Hi,
Stanislav Malyshev wrote:
Hi!
The two main points are:
1. While it's true that if you're using unserialize() on untrusted input
you are most likely going to be vulnerable due to object injection, it may
be quite hard for an attacker to exploit this for closed source
Objects are not the p
Hi!
> The two main points are:
> 1. While it's true that if you're using unserialize() on untrusted input
> you are most likely going to be vulnerable due to object injection, it may
> be quite hard for an attacker to exploit this for closed source
Objects are not the problem (unless it's interna
On 15.08.2017 at 23:56, Christoph M. Becker wrote:
> What about references? Consider, for instance, the following code:
>
>
> $_POST['untrusted_input'] = 'a:1:{i:0;a:1:{i:0;R:2;}}';
>
> function flatten($array)
> {
> if (is_array($array)) {
> $result = [];
On 11.08.2017 at 12:55, Nikita Popov wrote:
> I think it might also be useful to make a distinction based on
> allowed_classes here. I think there is a reasonable expectation that if
> allowed_classes is empty (and as such any object injection vectors are
> excluded), unserialize() should be safe.
On Fri, Aug 11, 2017 at 12:55 PM, Nikita Popov wrote:
> On Thu, Aug 10, 2017 at 10:49 AM, Nikita Popov
> wrote:
>
>> On Sun, Aug 6, 2017 at 12:49 AM, Stanislav Malyshev
>> wrote:
>>
>>> Hi!
>>>
>>> > https://bugs.php.net/bug.php?id=75006 has been marked as a
>>> non-security
>>> > bug, with the
On Thu, Aug 10, 2017 at 10:49 AM, Nikita Popov wrote:
> On Sun, Aug 6, 2017 at 12:49 AM, Stanislav Malyshev
> wrote:
>
>> Hi!
>>
>> > https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
>> > bug, with the justification that unserialize() should not be fed
>> untrusted
>> > in
On Sun, Aug 6, 2017 at 12:49 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
> > bug, with the justification that unserialize() should not be fed
> untrusted
> > input. While we do document that unserialize() shouldn't be used on
>
Le 06/08/2017 à 00:49, Stanislav Malyshev a écrit :
> Hi!
>
>> https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
>> bug, with the justification that unserialize() should not be fed untrusted
>> input. While we do document that unserialize() shouldn't be used on
>> untrusted i
Hi!
> https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
> bug, with the justification that unserialize() should not be fed untrusted
> input. While we do document that unserialize() shouldn't be used on
> untrusted input, we have always treated these as security bugs in the p
> On 2 Aug 2017, at 23:03, Nikita Popov wrote:
>
> Hi,
>
> https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
> bug, with the justification that unserialize() should not be fed untrusted
> input. While we do document that unserialize() shouldn't be used on
> untrusted input
Hi,
https://bugs.php.net/bug.php?id=75006 has been marked as a non-security
bug, with the justification that unserialize() should not be fed untrusted
input. While we do document that unserialize() shouldn't be used on
untrusted input, we have always treated these as security bugs in the past.
Co
Java has a transient keyword to skip serialising a property and I have
a patch against 5.3 on http://whisky.macvicar.net/patches/
It might make it in to 5.4/6/next once I get some more free time.
Scott
On 1 Mar 2010, at 02:10, Jordi Boggiano wrote:
On 01.03.2010 10:31, Tjerk Meesters wrote
On 01.03.2010 10:31, Tjerk Meesters wrote:
> If visibility is an issue why not just use json_enode/decode for this
> case then?it doesn't seem like a typical enough problem to be solved
> low-level and json seems fast enough for the job ;-)
Honestly I personally don't care, it won't happen to me a
Hi,
If visibility is an issue why not just use json_enode/decode for this
case then?it doesn't seem like a typical enough problem to be solved
low-level and json seems fast enough for the job ;-)
Hi,
I don't know whether it should be fixed or not, but it definitely shouldn't
have received
Hi,
If visibility is an issue why not just use json_enode/decode for this
case then?it doesn't seem like a typical enough problem to be solved
low-level and json seems fast enough for the job ;-)
On 01-Mar-2010, at 4:00, Jordi Boggiano wrote:
On Sun, Feb 28, 2010 at 8:03 PM, Herman Radtk
On Sun, Feb 28, 2010 at 8:03 PM, Herman Radtke wrote:
>> Imo unserialize should check, when applying public or protected values,
>> if either exists on the object, and apply it to the one that exists.
>> Sure it's gonna cost some performance, but at least changing the
>> prototype of your class wh
On 28 February 2010 19:03, Herman Radtke wrote:
>> Imo unserialize should check, when applying public or protected values,
>> if either exists on the object, and apply it to the one that exists.
>> Sure it's gonna cost some performance, but at least changing the
>> prototype of your class while st
> Imo unserialize should check, when applying public or protected values,
> if either exists on the object, and apply it to the one that exists.
> Sure it's gonna cost some performance, but at least changing the
> prototype of your class while stuff is running isn't going to kill your
> code anymor
Heya,
This bug was closed as Bogus http://bugs.php.net/bug.php?id=51173 and
Pierre told me to bring the discussion here since I was ranting on irc.
Johannes argued that the fact unserialize doesn't check the access level
of properties before generating object is good because it allows hackish
fea
On 15.09.2005 00:12, Marcus Boerger wrote:
Well right now we don't fail gracefully
Right, but it could be done easily.
and i don't think we should unless
we are dealing with something introduced in later versions that doesn't hurt
or to generate helpfull error messages that explicitly tell yo
Hello Antony,
Wednesday, September 14, 2005, 8:58:31 PM, you wrote:
> On 14.09.2005 18:02, Marcus Boerger wrote:
>> Hello Antony,
>>
>> why can't we put a marker there? shouldn't we be able to add a flag
>> and allow that flag in older php versions disallowing to load those
>> serialized data
On 14.09.2005 18:02, Marcus Boerger wrote:
Hello Antony,
why can't we put a marker there? shouldn't we be able to add a flag
and allow that flag in older php versions disallowing to load those
serialized data in case it shows unicode semantics?
You mean adding a marker to be able to fail wi
Hello Antony,
why can't we put a marker there? shouldn't we be able to add a flag
and allow that flag in older php versions disallowing to load those
serialized data in case it shows unicode semantics? Right now we'd
simply fail in case of unicode usage in any serialized data with old
php versio
Hello Tex,
Wednesday, September 14, 2005, 1:07:26 PM, you wrote:
TT> Bear with me, I don't know about how PHP uses the serialized info, but if
TT> your goal is to minimize the overhead for unicode data when
no, now we're discussing the following issues:
1) should serialize format be port
On Tue, 13 Sep 2005, Antony Dovgal wrote:
> > But needed, as even with the semantics off, you can get unicode strings.
> > Which can end up as array keys.
>
> Yes, in this case there is no way to avoid converting (while doing
> unserialize()), but I don't see any point in creating Unicode strings
! Inc.
> -Original Message-
> From: Pierre Joye [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 13, 2005 3:44 AM
> To: Antony Dovgal
> Cc: Derick Rethans; val khokhlov; internals@lists.php.net
> Subject: Re: [PHP-DEV] unserialize() & unicode issues
>
>
&g
On 9/13/05, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> Yes, in this case there is no way to avoid converting (while doing
> unserialize()),
> but I don't see any point in creating Unicode strings when serializing with
> unicode_semantics is Off.
If I use serialized data on different hosts with
Hello Antony,
Tuesday, September 13, 2005, 12:42:57 PM, you wrote:
AD> So you propose to store strings/hash keys/class names in Unicode
AD> even if unicode_semantics is Off ?
yes - those items that are encoded into unicode when
unicode_semantics is on (afair, class names and property name
On 13.09.2005 13:52, Derick Rethans wrote:
On Tue, 13 Sep 2005, Antony Dovgal wrote:
On 13.09.2005 13:32, val khokhlov wrote:
> Hello Antony,
>
> Tuesday, September 13, 2005, 11:21:21 AM, you wrote:
>
> AD> Even if the class name is in Unicode, we can try to convert it to ASCII
> AD> and fai
On Tue, 13 Sep 2005, Antony Dovgal wrote:
> On 13.09.2005 13:32, val khokhlov wrote:
> > Hello Antony,
> >
> > Tuesday, September 13, 2005, 11:21:21 AM, you wrote:
> >
> > AD> Even if the class name is in Unicode, we can try to convert it to ASCII
> > AD> and fail only in the case when we can't
On 13.09.2005 13:32, val khokhlov wrote:
Hello Antony,
Tuesday, September 13, 2005, 11:21:21 AM, you wrote:
AD> Even if the class name is in Unicode, we can try to convert it to ASCII
AD> and fail only in the case when we can't find its class entry in the list.
I think, it's not the o
Hello Antony,
Tuesday, September 13, 2005, 11:21:21 AM, you wrote:
AD> Even if the class name is in Unicode, we can try to convert it to ASCII
AD> and fail only in the case when we can't find its class entry in the list.
I think, it's not the only way.
If we don't care about bein
Even if the class name is in Unicode, we can try to convert it to ASCII
and fail only in the case when we can't find its class entry in the list.
So, I don't see any need in markers and other fairly major changes.
On 13.09.2005 04:54, Andi Gutmans wrote:
Not coming with a solution, but I believ
Not coming with a solution, but I believe this would be a bad idea. I
do think some people will be using IS_UNICODE strings when
unicode_semantics=off, mainly for existing applications. They may
want to serialize Unicode strings even though their classes are
IS_STRING. It might make sense to ra
The problems you encountered are fairly big, I wouldn't just dismiss
them.
-Andrei
On Sep 9, 2005, at 6:58 AM, Antony Dovgal wrote:
On 09.09.2005 17:44, Andrei Zmievski wrote:
Yes, serialization is a problem. I would actually advocate putting
a marker in the serialized file that indicat
On 09.09.2005 17:44, Andrei Zmievski wrote:
Yes, serialization is a problem. I would actually advocate putting a
marker in the serialized file that indicates what the value of
unicode_semantics switch was during the serialization, and if the
value is different during deserialization, refuse
Yes, serialization is a problem. I would actually advocate putting a
marker in the serialized file that indicates what the value of
unicode_semantics switch was during the serialization, and if the
value is different during deserialization, refuse to load it or start
a new session. One real
Hello all.
I'm currently working on unicode support in serialize()/unserialize() and stuck
with some issues.
Here they are:
1) What to do with unserializing serialized unicode strings when
unicode_semantics is Off?
I presume it's safe to create & return IS_UNICODE in this case ?
2) Classnames
Derick Rethans wrote:
On Tue, 17 May 2005, Timm Friebe wrote:
Fix
===
Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
Do you have a patch? :)
I attached a patch for ext/standard/var_unserializer.{c,re}
- Chris
Index: ext/standard/var_unserializer.c
===
Derick Rethans wrote:
On Tue, 17 May 2005, Timm Friebe wrote:
Fix
===
Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
Do you have a patch? :)
Oops, and here a patch without the debug fprintf :-)
- Chris
Index: ext/standard/var_unserializer.c
=
Is it documented anywhere what the allowed chars are..?
(I couldn't find it anywhere but sources :)
--Jani
On Tue, 17 May 2005, Timm Friebe wrote:
Hi,
unserialize() cannot unserialize objects whose names contain anything except
a-z, 0-9 and _, the parser allows those, though.
Example
==
Hi,
> > Fix
> > ===
> > Allow anything the parser allows,
> > [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
>
> Do you have a patch? :)
Sorry, no, I'm working under Windows at the moment *without* any development
tools installed except for cygwin, and IIRC PHP won't build with just that
(meaning I co
On Tue, 17 May 2005, Timm Friebe wrote:
> Fix
> ===
> Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
Do you have a patch? :)
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mai
Hi,
unserialize() cannot unserialize objects whose names contain anything except
a-z, 0-9 and _, the parser allows those, though.
Example
===
$ cat unserialize.php
Expected behaviour
==
$ php unserialize.php
object(über)(0) {
}
Actual behaviour
$ php unser
shruti wrote:
Hello all,
I have an issue with unserializing big objects. My object when serialized to a file creates a file as big as 29 Megs. And when i m trying to unserialize the object, it takes forever somewhere around 33-36 secs(sometimes even more).
My object has one member variable which
Hello all,
I have an issue with unserializing big objects. My object when serialized to a
file creates a file as big as 29 Megs. And when i m trying to unserialize the
object, it takes forever somewhere around 33-36 secs(sometimes even more).
My object has one member variable which is a referen
Yes, its fixed. Thanks Marcus!
Nuno
- Original Message -
Hello Nuno,
that should be fixed now. If not report the problem please again here.
best regards
marcus
Saturday, September 11, 2004, 6:17:16 PM, you wrote:
Nuno Lopes wrote:
Hello Marcus,
PHP prints an error for every file in /usr/l
Hello Nuno,
that should be fixed now. If not report the problem please again here.
best regards
marcus
Saturday, September 11, 2004, 6:17:16 PM, you wrote:
>> Nuno Lopes wrote:
>>> Hello Marcus,
>>>
>>> PHP prints an error for every file in /usr/local/lib/php/.registry
>>> One of those files:
Nuno Lopes wrote:
Hello Marcus,
PHP prints an error for every file in /usr/local/lib/php/.registry
One of those files: http://testes.aborla.net/pear.reg
prints:
"Notice: unserialize(): Error at offset 121 of 8404 bytes in test.php on
line 5"
This file is truncated, please verify that it indeed does
Nuno Lopes wrote:
Hello Marcus,
PHP prints an error for every file in /usr/local/lib/php/.registry
One of those files: http://testes.aborla.net/pear.reg
prints:
"Notice: unserialize(): Error at offset 121 of 8404 bytes in test.php on
line 5"
This file is truncated, please verify that it indeed doe
Hello Marcus,
PHP prints an error for every file in /usr/local/lib/php/.registry
One of those files: http://testes.aborla.net/pear.reg
prints:
"Notice: unserialize(): Error at offset 121 of 8404 bytes in test.php on
line 5"
Nuno
- Original Message -
Hello Nuno,
can you sent me he code i
Nuno:
It would also be helpful to know what version of PEAR you are using, and
in particular, the setting of magic_quotes_runtime. Earlier PEAR
versions choked on the unserialize statements in PEAR_Registry if this
setting was on.
Greg
Marcus Boerger wrote:
Hello Nuno,
can you sent me he cod
Hello Nuno,
can you sent me he code it is trying to deserialize?
marcus
Friday, September 10, 2004, 8:42:42 PM, you wrote:
> Hello,
> I think that the last unserialize() changes (2004-09-05) have broken it,
> because now I can't even do a simple 'pear list'.
> I can reproduce this problem i
Hello,
I think that the last unserialize() changes (2004-09-05) have broken it,
because now I can't even do a simple 'pear list'.
I can reproduce this problem in both my two pcs.
Can someone check this problem, please?
Thanks,
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
As I said, over the years I've done both, and this is what I've
settled on as the most practical.
Then you should have learned by now that verifying your
data's integrity is a mandatory task when designing any
client-side session system. Otherwise, attackers can inject
any kind o
Hello Markus,
I've done both many times. There are many ways to do this type of
thing, but the way I described it is very clean because the data is
always in sync with the page (due to the fact that the data is on
the page).
If you save the data to a session, and then click back a coup
Jason Garber wrote:
This is an interesting point you bring up. When we have large
registration processes or similar multi-page forms, we write our
data array to a hidden field using.
base64_encode(serialize($aData))
and read it in with
unserialize(base64_decode($_POST['aData']))
On Sun, 5 Sep 2004 15:33:28 -0400, Jason Garber <[EMAIL PROTECTED]> wrote:
> This is an interesting point you bring up. When we have large
> registration processes or similar multi-page forms, we write our
> data array to a hidden field using.
>
> base64_encode(serialize($aData))
>
>
Hello Harry,
This is an interesting point you bring up. When we have large
registration processes or similar multi-page forms, we write our
data array to a hidden field using.
base64_encode(serialize($aData))
and read it in with
unserialize(base64_decode($_POST['aData']))
pa
Hi All,
Have a situation where I want to unserialize a string received from an
untrusted source over HTTP (a Javascript client in this case). For
basic types this is no concern but when it comes to objects, would be
nice to be able to restrict the class of object to a member of a known
list, to pr
entry found in bugs.php.net
Jean-Pierre
- Original Message -
From: "James Cox" <[EMAIL PROTECTED]>
To: "Jean-Pierre Arneodo" <[EMAIL PROTECTED]>
Sent: Friday, May 23, 2003 6:44 PM
Subject: RE: [PHP-DEV] Unserialize bug in PHP 4.3.2RC4?
[skip]
>
> > From:
61 matches
Mail list logo
