Comparing GCC and Clang security features

Posted Sep 13, 2019 17:38 UTC (Fri) by rweikusat2 (subscriber, #117920)
Parent article: Comparing GCC and Clang security features

> Cook responded that there is value in bringing the architecture to a known state at function return; it may not block a specific
> attack right now, but "we don't know what is coming next".

This is an appeal to ignorance (logical fallacy).

Comparing GCC and Clang security features

Posted Sep 13, 2019 18:41 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (15 responses)

> This is an appeal to ignorance (logical fallacy).

Aka proactive security? What about this one?

"The kernel is now free of implicit fall-throughs; of the roughly 500 patches fixing fall-through warnings in the last year, Cook said, about 10% turned out to be addressing real bugs in the code."

Comparing GCC and Clang security features

Posted Sep 13, 2019 20:11 UTC (Fri) by rweikusat2 (subscriber, #117920) [Link] (14 responses)

No. That's invalid reasoning aka invalid reasoning, and nothing else.

Comparing GCC and Clang security features

Posted Sep 13, 2019 20:42 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

No. This is a valid reasoning from the past experience.

Comparing GCC and Clang security features

Posted Sep 14, 2019 0:49 UTC (Sat) by rweikusat2 (subscriber, #117920) [Link] (12 responses)

https://ses.edu/logical-fallacies-101-ad-ignorantiam/

Nothing follows from ignorance.

Comparing GCC and Clang security features

Posted Sep 14, 2019 7:06 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (10 responses)

Call it paranoia if you want, but it is certainly not ignorance. It is definitely a known fact that even the smallest knowledge of register contents has in the past been turned into exploits

Comparing GCC and Clang security features

Posted Sep 15, 2019 19:37 UTC (Sun) by rweikusat2 (subscriber, #117920) [Link]

That's definitely not a known fact as an exploit this 'feature' is supposed to 'defend' against would otherwise need to exist, ie, nobody would have to resort to "we don't what will happen in future" as reason for "why is this of value".

Comparing GCC and Clang security features

Posted Sep 15, 2019 19:53 UTC (Sun) by rweikusat2 (subscriber, #117920) [Link] (5 responses)

For a practical example. This ARM64 (mnemonical) machine code for a function supposed to strip trailing newlines from a string.

  46b710:       8b214001        add     x1, x0, w1, uxtw
  46b714:       eb01001f        cmp     x0, x1
  46b718:       540000a3        b.cc    46b72c 
  46b71c:       14000007        b       46b738 
  46b720:       d1000421        sub     x1, x1, #0x1
  46b724:       eb01001f        cmp     x0, x1
  46b728:       540000c0        b.eq    46b740 
  46b72c:       385ff022        ldurb   w2, [x1,#-1]
  46b730:       7100285f        cmp     w2, #0xa
  46b734:       54ffff60        b.eq    46b720 
  46b738:       3900003f        strb    wzr, [x1]
  46b73c:       d65f03c0        ret
  46b740:       aa0003e1        mov     x1, x0
  46b744:       3900003f        strb    wzr, [x1]
  46b748:       d65f03c0        ret

This is called with a pointer to the string in x0 and its length in w1. After the function has finished, x1 points to a null byte written over the the first trailing newline or immediately behind the string if there were no newlines. w2 contains the rightmost character which wasn't a newline or 10 if there were only newlines in the string. There's no information in these registers which isn't already available at the call site, hence, there's absolutely no point in changing the values of these two registers before returning from the function.

Comparing GCC and Clang security features

Posted Sep 15, 2019 20:14 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

So all the software you're writing consists of newline stripping? No other functions whatsoever?

That... explains things.

Comparing GCC and Clang security features

Posted Sep 15, 2019 21:00 UTC (Sun) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

As usual, your wild speculations about me are impolite, untrue and besides the point.

Comparing GCC and Clang security features

Posted Sep 15, 2019 21:06 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope, it's on point exactly.

It doesn't seem that you understand the issue. It's possible to guarantee that ONE particular and easy function has no adverse effects from clobbered registers, it's not possible to prove that ALL functions are equally safe.

Comparing GCC and Clang security features

Posted Sep 15, 2019 21:11 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

You're able to guarantee which registers a compiler will use without manual inspection of the output?

Comparing GCC and Clang security features

Posted Sep 19, 2019 11:28 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Proof by example. No, proof by simple example.

How valuable.

Comparing GCC and Clang security features

Posted Sep 15, 2019 20:09 UTC (Sun) by ken (subscriber, #625) [Link]

I must say I'm really skeptical about cleaning out caller saved registers. If you are cleaning up all registered used inside a called function on return you could potentially need to clear like 10-16 of them depending on what architecture you run on.

And without even a single example of when that would have help it does sound a bit excessive.

Comparing GCC and Clang security features

Posted Sep 15, 2019 20:34 UTC (Sun) by ballombe (subscriber, #9523) [Link] (1 responses)

Or maybe the register clean up code can make some future attack easier.
Paranoia cuts both way.

Comparing GCC and Clang security features

Posted Sep 19, 2019 10:39 UTC (Thu) by dvdeug (guest, #10998) [Link]

Pseudo-paranoia cuts both ways. But real paranoia has to follow patterns. It's hard to justify that register clean up makes some future attack easier; all it's doing is providing less information to the other functions. It's easy to imagine cases where the register clean up makes some future attack harder; the example rweikusat2 shows how string functions can leave pointers to strings in registers, and if that's working on sensitive information and something calls it and returns without sanitizing its own registers, it would return that information in registers. The expectation from a programmer that the only thing returned is what is explicitly returned would be violated.

Comparing GCC and Clang security features

Posted Sep 20, 2019 1:46 UTC (Fri) by kmweber (guest, #114635) [Link]

As is typically the case, the person who resorted to merely shouting "fallacy" rather than substantively explaining the alleged error in the argument has failed to understand both the argument they're responding to and the fallacy they're inaccurately name-dropping.

There's a difference between "we don't know with certainty that this is a safe state, so there is a chance that this is unsafe so let's not take any chances" (which is the argument actually being made) and "we dony know it's safe; therefore it is definitely unsafe" (which would indeed be an argument to ignorance).

Comparing GCC and Clang security features

Posted Sep 13, 2019 22:14 UTC (Fri) by Paf (subscriber, #91811) [Link] (1 responses)

This is a deliberately simplistic analysis, taking one sentence and turning it in to an independent logical proposition.

I’ll expand the sentence in to the context you know exists and you can tell me if it’s still “arguing from ignorance”.

“Many récent security vulnerabilities have come from leaking internal state that was not previously recognized as important. Therefore, it is worth scrubbing potential sources of this internal state information, even without specific attacks identified for that particular vector.”

Comparing GCC and Clang security features

Posted Sep 15, 2019 20:47 UTC (Sun) by flussence (guest, #85566) [Link]

> This is a deliberately simplistic analysis, taking one sentence and turning it in to an independent logical proposition.

And IIRC, doing so is such a tired logical fallacy that it even has its own pretentious latin label.