Bug#650536: ITM: Please review hardening-support branch to fix #650536 (Was: Re: Bug#650536: update!)
On 2012-04-02 18:28, Kees Cook wrote:
> 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.
>
Yes, but the tag will only be emitted on architectures that have
stackprotector enabled - hench the override ought to be architecture
specific. At the moment the user/packagers will have to keep that
architecture list up to date in their override (or ignore it), and I
feel Lintian would do a better job given we have the information available.
>> 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.
>
Maybe - I do not code C if I can avoid it, so I do not know how common
stack arrays are. This is partly why I tried to invovle others in the
choice. :)
> Perhaps we should examine some subset of the archive to figure out how
> much noise these checks will add?
>
> -Kees
>
Perhaps - unfortunately, the Lintian infrastructure cannot do it for us,
yet (see #660733).
~Niels
Reply to: