> I also agree wtih Tim Newsham that hygenic code that doesn't contain > any buffer overflow vulnerabilities is a preferable solution. But 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: crispinat_private Tim N.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:37:11 PDT