[Drbd-dev] drbd 8.4.3: refcounter overflow on re-sync

[PaX Team]

On 25 Sep 2014 at 2:07, Lars Ellenberg wrote:

> In this overflow case, I still don't see why it is supposed to help to
> shoot the process that happens to be "current" when the overflow occurs,
> respectively why it would be a valid assumption that this process would
> be "the exploit", provoking the overflow on purpose...

for an exploit to be useful it has to be both successful (be able to exploit
the bug(s)) and also reliable (do so 100% of the time, or at least without
any ill side-effects in case of both success and failure).

for refcount overflow based exploits it means precise control over the refcount.
since the exploit is a userland process, in practice only those refcount bugs
are relevant that execute in syscalls. therefore 'current' is actually the
exploit process in practice and more strategically, it runs under the uid that
must have been owned a priori. so killing the triggering process does not only
clean up an otherwise cpu-hungry process (taking 4G refcounts takes time) but
also generates an event about a potential breach of security with actionable
details (at least grsec has such capabilities).

> Though I dislike it even more that it (implementing protection
> techniques) is even necessary, if you have to assume they are out to get
> you.  Which is more a fact than an assumption, in more scenarios than
> I'd like it to be.  So you keep preventing existing bugs elsewhere from
> becoming exploitable, and I'll shut up :)

our protection mechanisms (will continue to) cover all kernel code, including
drbd ;). speaking of that, you could do some hardening yourself in fact, e.g.,
constify data_cmd and asender_cmd. we do this automatically with a gcc plugin
but it'd be a trivial source patch.

cheers,
  PaX Team