Re: Re: com php-src: fix several datatype mismatches: Zend/zend_API.h ext/standard/basic_functions.c ext/standard/basic_functions.h

OF COURSE IT’S NOT REALISTIC. But it’s a web security nightmare. Imagine a simple website accepting $_GET[‚test‘] as input. Now imagine a web attacker who converts the server-side variable into an array (?test[foo]) trying to INTENTIONALLY TRIGGER an overflow. I’ve just tested it. It throws an error message like Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /usr/share/nginx/www/foo.php on line 6 But why are we letting attackers even get so far? Why aren’t we blocking them far before that critical line of defense? This is at least an information leak vulnerability in PHP which should be fixed. On 22 Oct 2014, at 21:31, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Wed, Oct 22, 2014 at 9:18 PM, Daniel Zulla <daniel.zulla@gmail.com> wrote: > What happens if you exceed uint32? > > Just curious, security-wise, because AFAIR exceeding uint32 would be possible through > superglobals only, which a potential attacker could abuse. > > param=foo > > param[a]=foo&param[b]=foo&param[c]=foo&param[…]=foo (reaching uin32+1) > > Creating an array that overflows uint32_t size requires at least 128 GB of memory (the way you > wrote it more like ~500GB of memory). It's just not a realistic scenario. > > If you happen to have that much memory available and overflow the size, PHP will probably > crash. We don't currently check overflows for this (at least not correctly). > > Nikita >