Bug#650536: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
On Mon, Apr 02, 2012 at 11:25:26AM +0200, Niels Thykier wrote:
> No, At least the "hardening-no-stackprotector" can be triggered in a
> perfectly safe program where the stack protector is not needed. We
> worked around this in the test suite by ensuring there was a stack
> that needed protection, but I would be very sad to see people do
> the same in real programs.
Well, I'd expect people to add an overrides file instead.
> If I understood you correctly in comment 44, then the protected
> functions could have the same issue:
>
> """
> For example, if the only function used was gethostname(), it's possible to
> do compile-time verification to see that the _chk() version isn't needed,
> so even though the source was built with -D_FORTIFY_SOURCE=2, the
> unprotected function will be used.
> """
>
> Actually, come to think of it - hardening-no-stackprotector smells a bit
> like a "wild-guess" since we can only say if it is safe, not if it might
> be vulnerable. Though "possible" -> "wild-guess" would change it from
> a "W" to "I" tag (and therefore not visible by default).
> The fortify functions code (in hardening-check) at least makes an
> educated guess and marks it safe if there are no uses of "possible
> vulnerable" functions (or if there are mixed uses). It may still be
> wrong, but we will not get a false-positive if the binary do not use
> any of the vulnerable functions.
>
> Do anyone have comments on dropping the stack protector to wild-guess?
Based entirely on the language, it seems like the stack protector warning
really is "possible". It's not "certain", for sure, but it doesn't seem
like what I'd think of as a "wild-guess". In practice, if its behavior
is more like the "wild-guess" checks, then it would make sense to drop
it to that level.
Perhaps we should examine some subset of the archive to figure out how
much noise these checks will add?
-Kees
--
Kees Cook @debian.org
Reply to: