This have to be fixed in libgd first

Notice: I don't think this is really a security bug

Please check https://bitbucket.org/libgd/gd-libgd/commits/3c0d2203b2672b688d4d2326ff3a60b019879062

Also https://bitbucket.org/libgd/gd-libgd/commits/4af76c97a478d4e7c4b64e08ac67abbca7cbd0fb

Hi,

Why do you think this is not a sec. issue?
I think(but am not 100% sure) that it will cause the loop to go down the 0, then it'll go to -1(aka. max int), and will try to free invalid places.

e.g:

unsigned int y = 5;
unsigned int yy;
                for (yy = y; yy >= yy - 1; y--) {
			printf("%u\n", y);
                }

outputs:

$ ./a.out | head -n10
5
4
3
2
1
0
4294967295
4294967294
4294967293




1. it will go on forever, and 2. it will try to free invalid memory.


Thanks,

In PHP gdMalloc is mapped to emalloc which will never return NULL (but bailout with memory limit error), so the "clean_on_error" will never be used.

And I haven't say there is no bug, yes the infinite loop exists in libgd (not in PHP), I just say I can't see how this can raise security issue.

So you're saying that clean_on_error can never be called, so it can't get to that code? Why is it there then?

Anyways, if clean_on_error was reached and it did get to that code, it will cause either a denial of service, or a crash(or both). the crash may be exploitable due to it calling invalid memory. Perhaps somebody that knows more about the security of PHP(aka. not me) should comment.

Thanks,

Why the condition is "yy >= yy - 1"? I imagine for unsigned it's the same as yy != 0 but why not write it this way then? 

In any case, emalloc in PHP never returns NULL so in PHP context it is kind of an academic exercise.

We may want to merge the upstream for cleanness but doesn't look like security issue in PHP.

Ok cool.

@remi: Do you know of any programs using libgd, where gdMalloc does not call an emalloc-"like" allocator, that just quits on failure?



Thanks,