Re: [PATCH 0/2] vsprintf: ignore %n again

[George Spelvin]

> This is completely pointless.  *ANY* untrusted format string kernel-side
> is pretty much it.  Blocking %n is not "defense in depth", it's security
> theater.  Again, if attacker can feed an arbitrary format string to
> vsnprintf(), it's over - you've lost.  It's not just about information
> leaks vs. ability to store a value of attacker's choosing at the address
> of attacker's choosing as it was in userland.  Kernel-side an ability to
> trigger read from an arbitrary address is much nastier than information
> leak risk; consider iomem, for starters.

You've got to be kidding.  Yes, sometimes a read can have effects, but
such addresses are rare, not present in the main kernel memory mapping,
and you'd have to find a pointer to such an address (or a preceding
address with no nul bytes in between) on the stack at a known offset when
designing the printf string.  That's tricky, and not always possible.
Even for hardware devices, read side effects have gone out of style,
other than forcing PCI posted writes through.

And just because a hardware read has side effects doesn't mean it's
exploitable.  Being able to drop characters from a serial port is only
a DoS.

On the other hand, the ability to write an arbitrary, attacker-controlled
small integer to any address findable on the stack is very powerful and
easy to exploit.

Those two risks aren't remotely equivalent.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/