[PATCH][WIP] Make exploiting talloc harder by using a random talloc_magic

[Simo]

On Fri, 2013-10-18 at 07:28 +1300, Andrew Bartlett wrote:
> On Thu, 2013-10-17 at 12:30 -0400, Simo wrote:
> > On Thu, 2013-10-17 at 17:06 +1300, Andrew Bartlett wrote:
> > > On Thu, 2013-10-17 at 05:58 +0200, Stefan (metze) Metzmacher wrote:
> > > > Am 17.10.2013 03:34, schrieb Andrew Bartlett:
> > > > > This patch is inspired by the exploit in
> > > > > http://blog.csnc.ch/wp-content/uploads/2012/07/sambaexploit_v1.0.pdf‎
> > > > > and is an idea to see if we can make it harder to exploit talloc.  
> > > > > 
> > > > > The re-order is designed to put the flags earlier into the talloc_chunk,
> > > > > where they would have to be overwritten.
> > > > > 
> > > > > The only downsides I see so far are:
> > > > >  - startup needs to select a better random number
> > > > >  - we loose the magic 'different talloc version' detection, it will just
> > > > > abort with wrong magic.  However library .so names and symbol versions
> > > > > will probably avoid this, now we always build with waf. 
> > > > 
> > > > Can't just add the random one to the fixed one and remove it again if we
> > > > want to check the fixed one?
> > > 
> > > Two different libraries somehow inter-linked would generate two
> > > different random numbers, so no useful information would be available. 
> > 
> > I don't see how.
> 
> Either they use the same static variable, and are therefore the same
> library, or they use different static variables, and therefore are
> different libraries, because the static variable is bound to the code
> just as much as the constant was. 

In that case everything will break immediately anyway, having 2 copies
of talloc in the same process is just wrong, so I do not see a *real*
problem. It make no sense to cater for broken binaries.

Simo.