Talk:Buffer overflow protection
|This is the talk page for discussing improvements to the Buffer overflow protection article.
This is not a forum for general discussion of the article's subject.
|WikiProject Computer Security / Computing||(Rated C-class, Mid-importance)|
Gentoo and ProPolice
"Gentoo Linux uses ProPolice according to gcc -v:" Wouldnt that be better put as "Gentoo will use the ssp patch for gcc by default" Since gentoo's packages arent binarys. Stack-Smashing_Protector puts it in a better way --2mcm 21:43, 3 May 2005 (UTC)
It might be worth mentioning that any cannary based stack guard technique that only guards against overwriting the function return pointers will be incomplete in many cases. this is because these systems usually allow the saved frame pointer to be overwritten, this allows an attacker to, in effect, hijack the pointer to the stack used for the calling routine...to see more about how this is a serious security issue see the article on off-by-one overflows as the exploitation is essencially the same... --Michael Lynn 23:37, 20 March 2007 (UTC)
Why is this marked as in need of cleanup?
It looks fine to me. Graue 15:27, 23 May 2005 (UTC)
I've tried to clean this up a little
By merging various articles such as StackGaurd and StackGhost and most of the information from ProPolice into this, and moving things around and elaborating on them. Any thoughts? I'd like to also merge ProPolice into this and make it a redirect, but I'm not sure the two have equivalent information. -- Andyluciano 19 Aug 2005 05:24 (UTC)
- Okay, they pretty much have equivalent information now. -- Andyluciano 19 Aug 2005 5:45 (UTC)
what about /GS ?
There are description of several FOSS implementations but nothing about the /GS (guardstack) option of microsoft compilers, I think it would be a worthy addition. Trou 21:39, 22 May 2007 (UTC)
example of canary
The revision of 20:42, 3 August 2005 changed the value 13 to 3 with a justification that does not apply to the example. The example shows that there are 13 bytes from the address of "d" to the address of the "b". More than 3 but fewer than 13 written to "d" will corrupt "c" without overwriting the pointer "b". I changed this back to 13. 126.96.36.199 00:33, 11 August 2007 (UTC)
- Someone else made this change in 2010. Putting it back... .froth. (talk) 04:35, 17 January 2012 (UTC)
reference to immunix paper is spam?
I came to this article via the redirect guard page (found under sprintf). This article here currently does not explain what a guard page is. Can someone explain? Thanks, --Abdull (talk) 13:53, 10 March 2010 (UTC)
Rename article to "stack protection"?
Everything in this article only refers stack protection, not to buffer overflow protection in general. I think this article should be renamed to "stack protection" or maybe even "stack-smashing protection", because that's the common parlance in GCC circles. Opinions? MalcolmInglis (talk) 09:58, 27 September 2013 (UTC)
- If renamed, I would advocate "stack overflow protection", though "stack smashing protection" would also be okay. However, I think the thing to do would be to rework the article. The section on compiler flags and stuff is specific to preventing stack smashing attacks, but the general idea is more broadly applicable. I think some heap allocators put canaries between blocks, and there are hardening systems that will put them within objects and between buffers, as well as others that will use more powerful guards to protect against over*reads*, which aren't hindered at all by canaries as described by the current article version. These have varying tradeoffs between implementation simplicity, added security, and performance overhead of course. Point being: except for the compilers discussion, only the presentation is *really* stack-specific. I might take a shot at reworking things at some point. 188.8.131.52 (talk) 15:44, 6 February 2015 (UTC)
- I think "buffer overflow protection" is the more common term, and including heap overflows here is a good idea, unless we want another article on that. But the intro really needs a work-over to avoid redundancy and include the distinction between heaps and stacks etc more naturally. ★NealMcB★ (talk) 12:40, 20 July 2016 (UTC)