I wish more vendors would take this seriously and attack the problem
with aggressive code reviews. Then we wouldn't have the need for
interim hacks.
> Regarding guessing the canary value, it is really hard to brute-force a
> guess at the canary value. The canary is randomly chosen at exec time;
Unfortunately the current random canary value is quite easy to guess
at. This is something that should be fairly easy to fix though.
> It is more plausible to use Newsham's technique to get the program to
> reveal the canary value, but that only applies where the additional
> vulnerability of a buffer that can be used to get at the canary word
> exists. Also note that there is a separate canary value per function,
> so a canary-access buffer vulnerability in one function does not help
> you to smash a different function.
Unless you use a cryptographically sound way of generating the
random numbers, knowing one canary value may be more than enough
information to allow an attack to proceed. All the canary values
are related through a deterministic computation that an attacker can
reproduce.
As a second attack (credit to Tom Ptacek who thought of it), you
can simply trick the program into reusing the same canary value.
Because there are a finite number of canary values that are reused,
an attacker can cause the program to make enough function calls to
reuse the canary value for the procedure that the attacker wishes
to exploit. For example when processing text there may be a number
of function calls associated with each character or each line.
This might be all the leverage that is needed by the attacker.
Finally the precomputed canary values may be a target themselves.
If there is an overflow in the data or bss segments preceeding
the precomputed canary vector, an attacker can simply overwrite
all the canary values with a single value of his choosing, effectively
turning off stack protection.
> Crispin Cowan, Research Assistant Professor of Computer Science
> PO Box 91000 | digital: crispin@cse.ogi.edu
Tim N.