Lots of things get allocated with malloc. Including structures with function pointers in them. I don't count myself as an exploit expert, but I do know if I can manage to get to a situation where I have a writable, predictable location in memory that I know will get called in short order by something I am interested in, my job likely just got easier.
I think we're insane to try to predict the complexity of modern attacks and say that "oh a single attack can be defeated by this". Exploit authors are freaking smart and chain together 20 things to make a workable attack. I think we can be thinking along the lines of the above, wherein we have a piece of the world that can make the attackers life easier, and we make it harder. Especially if it's free or cheap. Not to mention that for the sub page size allocations, moving the list around will mean they're more likely to more often end up in a situaiton where they will get placed against a guard when we turn on such things, so we'll potentially see crashes more often in that case. So based on my experimentation with this, I'm for it, even without a necessarily demonstrated attack type that this stops. -Bob On Thu, May 1, 2014 at 8:18 AM, Ted Unangst <[email protected]> wrote: > On Thu, May 01, 2014 at 15:57, Damien Miller wrote: >> On Thu, 1 May 2014, Ted Unangst wrote: >> >>> What's better than a freelist? Four freelists! >> >> Apart from moar = better, what's the motivation? Do you have a particular >> attack in mind? The only thing I can think of where this change might help >> is an attack that speculatively spams small offsets from the overflow and >> hopes it doesn't run off the end of the page, and this seems fairly >> contrived... > > Nope, I can't tell you exactly how this would help, but it seems cheap > enough. Guiding philosophy is simply to make a list of everything > "known" about malloc, and then make it unknown or less certain. >
