Talk:Buffer overflow protection

Latest comment: 6 years ago by InternetArchiveBot in topic External links modified

Gentoo and ProPolice

edit

"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)Reply

Also Propolice has changed it name to Stack-Smashing_Protector aka ssp --2mcm 21:43, 3 May 2005 (UTC)Reply

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)Reply

Why is this marked as in need of cleanup?

edit

It looks fine to me. Graue 15:27, 23 May 2005 (UTC)Reply

I've tried to clean this up a little

edit

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 ?

edit

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)Reply

example of canary

edit

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. 142.16.23.254 00:33, 11 August 2007 (UTC)Reply

Someone else made this change in 2010. Putting it back... .froth. (talk) 04:35, 17 January 2012 (UTC)Reply

reference to immunix paper is spam?

edit

the cited immunix paper [1] is hardly spam. immunix was a DARPA-funded research project which produced the original stackguard. other benchmark sources: [2], [3] Tfinn 03:02, 17 August 2007 (UTC)Reply

Guard page?

edit

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)Reply

Yep, what he ^ said. Where're the guard pages? — Preceding unsigned comment added by 119.157.6.28 (talk) 11:36, 8 August 2017 (UTC)Reply

Rename article to "stack protection"?

edit

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)Reply

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. 66.188.116.58 (talk) 15:44, 6 February 2015 (UTC)Reply
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)Reply
edit

Hello fellow Wikipedians,

I have just modified 4 external links on Buffer overflow protection. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 10:48, 10 November 2016 (UTC)Reply

edit

Hello fellow Wikipedians,

I have just modified one external link on Buffer overflow protection. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:05, 14 December 2017 (UTC)Reply