[grsec] PAX_REFCOUNT doesn't work

[pageexec at freemail.hu]

On 2 Sep 2008 at 13:00, Carlos Carvalho wrote:

>  >> You mean that the kernel always leaks memory but it frees the
>  >> structure when it overflows, thus plugging the leak?
>  >
>  >yes, as long as the refcount doesn't reach 0, the kernel considers the
>  >given object as in-use and doesn't free the associated memory.
> 
>  >so in normal (non-attack) circumstances when the refcount leak does
>  >not actually result in a wrap, the object is effectively leaked memory.
> 
> Isn't this correct? Isn't it what the refcount is for? I don't
> understand why you call it leaked.

i'm talking about the buggy situation where a refcounted object has its
refcount unbalanced. in that case when the unbalancing code path in the
kernel executes, there's nothing that would undo it and the object's
memory remains allocated 'forever' (well, until an exploit comes around
and 'helps' it ;) - this is why i called it a leak, as it is a sideeffect
of the refcount handling bug.

>  >under attack however the refcount can be made to wrap and that's when
>  >the real trouble begins.
>  >
>  >> You say that this plugging is a problem because the freeing may happen
>  >> when the structure is still in use, therefore you chose to never free
>  >> it? Instead you prefer to make the memory leak permanent? 
>  >
>  >in terms of effects, yes, that's the result
> 
> I'm hesitant in using this feature because I'm not sure the cure is
> better than the disease. What's the effect on a busy server that runs
> continuously for several weeks if you avoid the freeing? Note that I
> have no idea which data structures you're talking about.

i'm not talking about any particular data structure in fact, i'm talking
about a class of kernel bugs that can affect any refcounted data structure.

as for the cure vs. disease, there's nothing that can be worse by using
this new PaX feature because an attacker can already cause the memory leak
at will (that is, if he's able to trigger the bug then he can stop short
of exploiting it). in fact, the memory leak already occurs regardless of
this protection (this is how one would spot it normal use), where PaX
enters the picture is that it prevents it from becoming exploitable.