JSON HASHDOS - Externals

11 years ago by Scott Arciszewski — view source — reply

unread

http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html

Sigh

11 years ago by Pierre Joye — view source — reply

unread

This issue has been reported earlier on security@php.net and is being
discussed and analyzed. It is not a simple task.

I have to thank the reporter to have it done the right way.

Maybe Lukas can learn from them for his next report.

Cheers,
Pierre

http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html

Sigh

11 years ago by Yasuo Ohgaki — view source — reply

unread

Hi,

This issue has been reported earlier on security@php.net and is being
discussed and analyzed. It is not a simple task.

If we are not going to use other hash (i.e. half MD4 like other langs), how
about
add max allowed collisions? It would be simple and fast enough. I'm not
looking
at the code, so I could be wrong.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Andrea Faulds — view source — reply

unread

Hi,

This issue has been reported earlier on security@php.net and is being
discussed and analyzed. It is not a simple task.

If we are not going to use other hash (i.e. half MD4 like other langs), how
about
add max allowed collisions? It would be simple and fast enough. I'm not
looking
at the code, so I could be wrong.

Hey,

We could implement a special JSONObject class with custom __get/__set handlers and that’s Traversable, which implements a randomised hashing algorithm rather than using zend_hash. That could be overkill though.

Thanks.

Andrea Faulds
http://ajf.me/

11 years ago by Scott Arciszewski — view source — reply

unread

Not all json_decode()s will operate on user-supplied data. Why not add a
DoS-resistant variant?

I propose the addition of json_safe_decode() to use a randomized hash.

I'm not trolling about the bin2hex() -> ts_bin2hex() when I say this. Well,
not entirely.

Hi,

On Wed, Dec 24, 2014 at 4:51 AM, Pierre Joye pierre.php@gmail.com
wrote:

This issue has been reported earlier on security@php.net and is being
discussed and analyzed. It is not a simple task.

If we are not going to use other hash (i.e. half MD4 like other langs),
how
about
add max allowed collisions? It would be simple and fast enough. I'm not
looking
at the code, so I could be wrong.

Hey,

We could implement a special JSONObject class with custom __get/__set
handlers and that’s Traversable, which implements a randomised hashing
algorithm rather than using zend_hash. That could be overkill though.

Thanks.

Andrea Faulds
http://ajf.me/

11 years ago by Pierre Joye — view source — reply

unread

Hi,

On Wed, Dec 24, 2014 at 4:51 AM, Pierre Joye pierre.php@gmail.com
wrote:

This issue has been reported earlier on security@php.net and is being
discussed and analyzed. It is not a simple task.

If we are not going to use other hash (i.e. half MD4 like other langs),
how
about
add max allowed collisions? It would be simple and fast enough. I'm not
looking
at the code, so I could be wrong.

Hey,

We could implement a special JSONObject class with custom __get/__set
handlers and that’s Traversable, which implements a randomised hashing
algorithm rather than using zend_hash. That could be overkill though.

Please keep in mind that this problem is:

. not json specific
. not specific at runtime but could also happen before a script get the hand

A randomized hash only postpone the issue but won't solve it.

I fear that a fix is way more work that what we may think. A discussion is
going on security, let hope to get something in a reasonable time. I also
wonder what we could provide right now to at least prevent script kiddies
attacks during this holiday season...

11 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Pierre,

Please keep in mind that this problem is:

. not json specific
. not specific at runtime but could also happen before a script get the
hand

A randomized hash only postpone the issue but won't solve it.

I fear that a fix is way more work that what we may think. A discussion is
going on security, let hope to get something in a reasonable time. I also
wonder what we could provide right now to at least prevent script kiddies
attacks during this holiday season..

I only read Zend code on occasion, so it might not be feasible.

Anyway, when collision happens, Engine detects collision.
Limited number of collision should happen under normal circumstances.
Simply limiting number of collisions for a specific hash bucket would
prevent DoS. The limit may be INI setting, so that users may set higher
limit when they need.

We may use more secure hash like half MD4 or CityHash (I'm not sure if
CityHash is secure enough, though), but it would be much slower than now.

Limiting number of collision would be the best solution. We never worry
about
intensional collision attack again.

Regards,

P.S. Did we decide to have 64 bit array keys? 64 bit array key is much more
stronger against collisions.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Pierre Joye — view source — reply

unread

hi,

Hi Pierre,

Please keep in mind that this problem is:

. not json specific
. not specific at runtime but could also happen before a script get the
hand

A randomized hash only postpone the issue but won't solve it.

I fear that a fix is way more work that what we may think. A discussion is
going on security, let hope to get something in a reasonable time. I also
wonder what we could provide right now to at least prevent script kiddies
attacks during this holiday season..

I only read Zend code on occasion, so it might not be feasible.

Anyway, when collision happens, Engine detects collision.
Limited number of collision should happen under normal circumstances.
Simply limiting number of collisions for a specific hash bucket would
prevent DoS. The limit may be INI setting, so that users may set higher
limit when they need.

We may use more secure hash like half MD4 or CityHash (I'm not sure if
CityHash is secure enough, though), but it would be much slower than now.

Limiting number of collision would be the best solution. We never worry
about
intensional collision attack again.

I do not see how it solves the problem. It only reduces it, slightly.
Having a couple of medium instances generating crafted requests will
just have the same effect. So far the more realistic suggestions are
about having collision safe implementation, not implementation with
limited collisions.

P.S. Did we decide to have 64 bit array keys? 64 bit array key is much more
stronger against collisions.

I would not say "much stronger", slightly stronger, but as long as the
same implementation is used, it does not really solve anything on this
area.

--
Pierre

@pierrejoye | http://www.libgd.org

11 years ago by Yasuo Ohgaki — view source — reply

unread

Hi,

I do not see how it solves the problem. It only reduces it, slightly.
Having a couple of medium instances generating crafted requests will
just have the same effect. So far the more realistic suggestions are
about having collision safe implementation, not implementation with
limited collisions.

It's ideal, but other languages are just switched to more secure hash and
random
seed. I'm not sure how feasible it would be.

P.S. Did we decide to have 64 bit array keys? 64 bit array key is much
more
stronger against collisions.

I would not say "much stronger", slightly stronger, but as long as the
same implementation is used, it does not really solve anything on this
area.

If we use the same DJB hash algo, it would not change situation much. I
agree.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

11 years ago by Patrick Schaaf — view source — reply

unread

Hi all,

Am 24.12.2014 10:47 schrieb "Yasuo Ohgaki" yohgaki@ohgaki.net:

I do not see how it solves the problem. It only reduces it, slightly.
Having a couple of medium instances generating crafted requests will
just have the same effect. So far the more realistic suggestions are
about having collision safe implementation, not implementation with
limited collisions.

It's ideal, but other languages are just switched to more secure hash and
random
seed. I'm not sure how feasible it would be.

See http://en.m.wikipedia.org/wiki/SipHash - in addition to e.g. Perl and
Python listed there, I think the same hash is also used in redis.

What could be the specific PHP issues that make it unfeasible, compared to
other languages that adopted the approach? Iteration instability was one of
the issues I remember from discussions about introducing a per-run
randomized hash in perl, but the PHP ordered array / linked list thing
already avoids that. Getting the random seed at RINIT time might be a bit
problematic, doing it in MINIT would already help? Other issues?

best regards
Patrick

11 years ago by Ferenc Kovacs — view source — reply

unread

Hi,

This issue has been reported earlier on security@php.net and is being
discussed and analyzed. It is not a simple task.

If we are not going to use other hash (i.e. half MD4 like other langs), how
about
add max allowed collisions? It would be simple and fast enough. I'm not
looking
at the code, so I could be wrong.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

I think it would be nice also keeping the hash replacement on the table,
otherwise we will just continue the current trend (to fix/work around the
immediate problem, only to resurface later in a different form).

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu