Buffer overflow protection: Difference between revisions

Content deleted Content added
Citation bot (talk | contribs)
Altered journal. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 60/492
Random canaries: general wikilinking
Line 33:
''Random canaries'' are randomly generated, usually from an [[entropy (computing)|entropy]]-gathering [[daemon (computer software)|daemon]], in order to prevent an attacker from knowing their value. Usually, it is not logically possible or plausible to read the canary for exploiting; the canary is a secure value known only by those who need to know it—the buffer overflow protection code in this case.
 
Normally, a random canary is generated at program initialization, and stored in a [[global variable]]. This variable is usually [[Padding (cryptography)|padded]] by unmapped pages so that attempting to read it using any kinds of tricks that exploit bugs to read off RAM cause a [[segmentation fault]], terminating the program. It may still be possible to read the canary if the attacker knows where it is or can get the program to read from the stack.
 
===Random XOR canaries===
''Random XOR canaries'' are random canaries that are [[Exclusive or|XOR]]-scrambled using all or part of the control data. In this way, once the canary or the control data is clobbered, the canary value is wrong.
 
Random XOR canaries have the same vulnerabilities as random canaries, except that the "read from stack" method of getting the canary is a bit more complicated. The attacker must get the canary, the algorithm, and the control data in order to re-generate the original canary needed to spoof the protection.
 
In addition, random XOR canaries can protect against a certain type of attack involving overflowing a buffer in a structure into a [[Pointer (computer programming)|pointer]] to change the pointer to point at a piece of control data. Because of the XOR encoding, the canary will be wrong if the control data or return value is changed. Because of the pointer, the control data or return value can be changed without overflowing over the canary.
 
Although these canaries protect the control data from being altered by clobbered pointers, they do not protect any other data or the pointers themselves. Function pointers especially are a problem here, as they can be overflowed into and can execute [[shellcode]] when called.