Langbahn Team – Weltmeisterschaft

Talk:Buffer overflow

Former good article nomineeBuffer overflow was a good articles nominee, but did not meet the good article criteria at the time. There may be suggestions below for improving the article. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.
Article milestones
DateProcessResult
June 30, 2006Featured article candidateNot promoted
May 6, 2007Peer reviewReviewed
February 16, 2017Good article nomineeNot listed
Current status: Former good article nominee

History vs history of malice

I added some early history of buffer overflows back, and reset the title from "History of malicious exploitation" to "History." I think it's important for an encyclopedia article to give a full history, not jump in mid-stream with how people are taking advantage of the class of issue. — Preceding unsigned comment added by Emergentchaos (talk • contribs) 00:45, 30 June 2011 (UTC)[reply]


Merge from Stack buffer overflow

Stack buffer overflow is a good article, but I think a lot of the content (esp diagrams) could be placed on this page instead, there is little which is specific to stack buffer overflows. -- Tompsci 14:01, 17 August 2007 (UTC)[reply]

I disagree that this information is specific to stack buffer overflows, the details of exploiting a buffer overflow are very different for a heap overflow vs a stack overflow for example...I for one would be opposed to such a merge... --Michael Lynn 17:55, 17 August 2007 (UTC)[reply]
Agreed, but the buffer overflow article is about buffer overflows in general and all the concepts you discuss can be generalised to apply to the heap aswell, or apply already. I think some of the content which covers ground already covered by "Buffer Overflow", covers it better, especially where the diagrams are used, which are really clear and aesthetically pleasing. That's why I am suggesting a merge. Especially since the stack-based page is not wiki linked much. -- Tompsci 00:49, 18 August 2007 (UTC)[reply]
I think it might be better to add or edit the content of buffer overflows article than to try to generalize buffer overflows with stack overflow content. the reason i say this is because the details of exploiting a stack buffer overflow are *completely* different from exploiting heap overflows. so much of the literature on this subject seperates the topics thats why I don't see it too bad to seperate them here. The way i think would be best would be to discuss the generalities of what people do with buffer overflows without respect to which kind they are and without going into the details of how they are exploited, and leaving the details of exploitation to the heap overflow and stack buffer overflow articles..that would leave the buffer overflow article to discuss the details of the impact of buffer overflow in general. You'll notice that I left most of the overall security ramifications out of the stack buffer overflows article because that seemed to fit in this article much better. I'm currently working on more diagrams for heap overflows, off by one exploits, and format string bugs, that would make them all look like they all go together better i think. --Michael Lynn 08:22, 18 August 2007 (UTC)[reply]
Ok, that makes more sense to me now. But I think some of the material belongs in buffer overflow not stack buffer overflow and the stack buffer overflow material can be removed as I think your material is superior to what already exists. I'll make the relevant changes and if you disagree then we can maybe revert the changes. -- Tompsci 10:52, 18 August 2007 (UTC)[reply]
sure thing, but do keep in mind that a little bit of duplication is not always a bad thing. --Michael Lynn 11:13, 18 August 2007 (UTC)[reply]
Agreed —Preceding unsigned comment added by 70.100.173.51 (talk) 22:40, 2 October 2007 (UTC)[reply]
Why? There are a lot of articles, where subthemes are represented as separated articles. Buffer overflow is the general type consiting of a set of subtypes. With such a success we can merge, for instance, Buffer overflow and Heap overflow articles.--91.76.20.6 (talk) 07:18, 23 December 2007 (UTC)[reply]

Does "deep packet inspection" section matter?

Deep packet inspection doesn't find modern buffer overflows. The technique has been of clearly limited value since Ptacek and Newsham's paper. Should that section go away?

It should go. It has nothing (directly) to do with this subject. It could be added as a sidenote, linking to Deep_packet_inspection in reference to security implications/issues in software development, but that's a way broader issue.
83.252.234.134 (talk) 06:43, 2 December 2016 (UTC)[reply]

1 question about the Code Red worm mentioned in this article...

In this article it's been written that the code red worm exploited a buffer overflow on IIS, but didn't it just exploit the web trasversal unicode bug? I mean, if so, no buffer overflows where used in that exploit, just unicode double encoding, that is pretty more simple... GET /scripts/%252e%252e/%252e%252e/%252e%252e/winnt/cmd.exe?/c+dir+c: HTTP/1.0\r\nHost: IIS.insecure.domain.com\r\n\r\n —Preceding unsigned comment added by 80.180.208.118 (talk) 19:05, 15 October 2007 (UTC)[reply]

it would've beem extremely informative

giving the windows buffer's file names and some technical review. regards, 23:19, 8 January 2009 (UTC)

Overwriting VMTs of heap allocated objects

The Heap Exploits section could mention this method. It's possible under some object layouts.

Rep movsd (talk) 14:26, 4 March 2009 (UTC)[reply]

Overreads?

The article appears to deal solely with buffer overwrites, yet overreads can be nasty bugs too. 119.225.239.230 (talk) 20:47, 11 April 2014 (UTC)[reply]

Heartbleed bug isn't a buffer overflow as no adjacent memory is overwritten during its exploitation. — Dsimic (talk | contribs) 03:50, 14 April 2014 (UTC)[reply]
What Dsimic is trying to say is that the term "buffer overflow" is generally only used to describe a specific type of out-of-bounds write. "Buffer overreads" would be a form of out-of-bounds reads, which one would not call a buffer overflow. However, I could not find an existing article about out-of-bounds reads of any form on Wikipedia. If you feel there is a need for one, you may want to start it. — SkyLined (talk) 07:02, 14 April 2014 (UTC)[reply]
Exactly. Regarding the coverage within Wikipedia articles, Bounds checking § Index checking section provides an overview, though it could be improved further. — Dsimic (talk | contribs) 18:32, 16 April 2014 (UTC)[reply]
I have just created buffer overread redirected to buffer over-read, though which spelling is better I wouldn’t know. It is very much a stub, but includes, commented out, almost all of buffer overflow, so anyone is welcome to transform that and to discard what is irrelevant. I don’t intend to do anything more, apart from adding some links from other articles, in the next few hours, maybe not even the next few days, so anyone really is welcome. PJTraill (talk) 10:16, 24 April 2014 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Buffer overflow. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • 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. —cyberbot IITalk to my owner:Online 16:10, 25 August 2015 (UTC)[reply]

Looking good. — Dsimic (talk | contribs) 05:22, 26 August 2015 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to 3 external links on Buffer overflow. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

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.—cyberbot IITalk to my owner:Online 07:49, 27 February 2016 (UTC)[reply]

GA Review

This review is transcluded from Talk:Buffer overflow/GA1. The edit link for this section can be used to add comments to the review.

Reviewer: Maury Markowitz (talk · contribs) 21:34, 20 October 2016 (UTC)[reply]


Ok, here we go...

  • "Buffer overflows can be triggered by inputs that are designed to execute code" - this appears to be mixing two separate things. One is that buffer overflows can trigger code execution, and the other is that you may design a program to do that deliberately. Putting them both together in a single statement seems confusing.
  • "Bounds checking can prevent buffer overflows" - indeed, but it can also significantly effect performance. AFAIK this is the reason C++ did not add it, and I think that is important to mention even in the lede.
  • I really like the example section! My only concern here is the end, which seems WAY too inside baseball for this article?
  • "by overwriting a local variable that is near the buffer in memory on the stack to change the behavior of the program" - this does not parse... near...in...on...to change... Perhaps this can be rewritten?
  • "With a method called "trampolining"" - I would recommend re-writing this statement, it is very confusing to me in its current form. Particularity, "if the address of the user-supplied data is unknown, but the location is stored in a register" I can't seem to understand. Perhaps this can be (greatly) simplified?
  • "Stack-based buffer overflows are not to be confused with stack overflows." - why is this statement here?
  • "Also note that these vulnerabilities" - no! A fuzzer is worth mentioning, but that should definitely be in the Protective countermeasures, not just sort of floating about here.
  • "Barriers to exploitation" - this seems out of place too. It would seem this is a protective countermeasure too.
  • "NOP-sled" - is it NOP-sled or NOP slide? Suggest picking the later unless there's a good reason not to.

More later, gotta put the kid to bed. Maury Markowitz (talk) 23:56, 20 October 2016 (UTC)[reply]

Thanks for reviewing this! I nominated it because I couldn't find any significant flaws, so it's really great to get another pair of eyes on it. To your comments:

  • I've updated the lede to address your first two concerns. The topic of buffer overflow exploitability prevention is complex (possibly one of the most complex things we have), but I think of all the things to mention in the lede that is it. Of course there are other reasons C++ doesn't add intrinsic bounds checking, but x86 now has extensions for it... anyway:
  • I like that the example is concrete. I think if I didn't know what a buffer overflow was at all or why it was a problem, that example would do a really good job of helping me understand. I think we can probably assume someone interested in this topic has enough C to understand it? I'm not sure what else could be used to mediate the explanation - certainly it could be written in Pascal, but I think people are less likely to understand it then.
  • I've made some minor changes for clarity to the stack-based examples.
  • Reference the trampoline, yes, when I think about it, a lot of stuff is going on there. Usually exploitation now involves an improbable number of steps and many interacting components, but I've simplified it as best I can.
  • Yes, you're right about fuzzing! I moved it to a new section in the mitigations part.

The remainder needs more work than I can do right this moment; more to follow. FalconK (talk) 11:16, 22 October 2016 (UTC)[reply]

I hope you don't mind, but I made edits to the lede to further separate the concept of a buffer overflow from the concept that those can be exploited. It also defines a buffer, which seems useful - ultimately it would be great if one can read just the lede and get a feel for the entire topic, and I think this expansion helps in that regard. Please check for any technical errors or potentially confusing use of terms!
I have also mentioned ASLR in the lede, because that strikes me as one of the most common modern attempts to attack the problem, and it seems like that should be up front.
More to follow, off to work! Maury Markowitz (talk) 13:37, 24 October 2016 (UTC)[reply]
Apologies - I've been a bit busy this week with work things, but I'll be able to take this back up again once it passes. FalconK (talk) 09:41, 27 October 2016 (UTC)[reply]

Status query

FalconK, Maury Markowitz, what is the status of this review? There doesn't appear to have been any work done on the article since late October. Thanks. BlueMoonset (talk) 18:51, 19 December 2016 (UTC)[reply]

I was waiting to hear back from FK, but now I have the sinking feeling he's waiting on me? Maury Markowitz (talk) 15:41, 20 December 2016 (UTC)[reply]
Nope, waiting for some work things to be over, actually. I might have a little time to allocate for the article this week. The comments above are valid and we should address them. FalconK (talk) 23:14, 20 December 2016 (UTC)[reply]
FalconK, Maury Markowitz, it's been another four weeks, and FalconK's last edit to the article was back in October. The review will have been open for three months as of this Friday, January 20. Perhaps, if nothing has been done by then, that would be an appropriate time to close this. FalconK can always renominate at another, more convenient time. BlueMoonset (talk) 22:47, 16 January 2017 (UTC)[reply]
I'm up to my ears in CFP responses and consulting work, so it might come to that unless I magically have spare time in the next few days. That said, the feedback here remains valid. FalconK (talk) 09:49, 17 January 2017 (UTC)[reply]
Maury Markowitz, this review is now 100 days old. I think it's time to close this. Thanks. BlueMoonset (talk) 03:33, 28 January 2017 (UTC)[reply]
Yes it looks that way, oh well. Maury Markowitz (talk) 18:50, 28 January 2017 (UTC)[reply]

Programming languages (blame)

I think the "Programming languages commonly associated with buffer overflows" is both putting C and C++ in undeserved bad light (the problem is from developers using the languages, not the languages themselves), and it's given a way too (undeserved) prominent placement in the lead.

I'd like to see this re-worded, and placed towards the end of the article (if it's even to stay) - to me it currently reads like an ad for "managed" languages. 83.252.234.134 (talk) 07:09, 2 December 2016 (UTC)[reply]

Protection number 9

Is not the using of an OS which uses the segmentation of the IA-32 protected mode an effective protection against buffer overflow?! If so this can be explained as a 9th solution of protection. --93.220.240.5 (talk) 21:32, 25 September 2017 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 5 external links on Buffer overflow. 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) 20:14, 1 December 2017 (UTC)[reply]

Image in lead

Pinging @SkyLined: since they reverted: I had recently made an attempt to create an image representation of buffer overflows, and finished int yesterday. Unfortunately, I was incorrect about my understanding of overflows and it was thankfully taken back out. Coincidentally, I have found a similar vector image, that seems to be accurate,File:Buffer_overflow_basicexample.svg. SkyLined, do you think this image is suitable and correct? If so, I could insert it. If not, perhaps a correct one could be made. WhoAteMyButter (📨talk│📝contribs) 02:33, 13 November 2021 (UTC)[reply]

That looks accurate, feel free to add it. Thank you for taking the time to create it! 163.158.13.177 (talk) 10:07, 13 November 2021 (UTC)[reply]
Quelle: http://en.wikipedia.org/wiki/Talk:Buffer_overflow