Talk:Buffer overflow/Archive 1

message: Removed from an earlier version of this article, becuase it 'sounds like Cyclone advocacy':
:Various techniques have been used to make buffer overflows in C programs less likely. Cyclone is a modified version of the C programming language which uses type information and run time checks to reduce the likelihood of buffer overflows and other memory corruption issues. Systems such as stackguard provide protection against the most common techniques for exploiting buffer overflows by checking that the stack has not been altered when a function returns. 
Why remove the Cyclone reference, and not the stackguard reference? Why remove either? It is only mild advocacy at worst (my interest is only as a potential Cyclone user, for the reasons stated above) and is directly releveant to the topic. -- The Anome
I suspect that both Cyclone and stackguard are only single instances of ideas that have been tried several times. If anyone can put a name to, or give other examples of, these approaches, then I think they both have a place in the article. Mentioning Cyclone alone does seem a bit out of place in so short an article, given that it's apparently a new system with no extensive real world use. -- Matthew Woodcraft
Okay, how about this as a set of categories:
Attempts to solve the buffer overflow problem:
* Languages with in-built run-time bounds checking (Pascal, Python, Java)
* Retrofit run-time bounds checking for unsafe languages 
* Libraries that catch certain cases of buffer overflow at run-time
* Static analysis to catch buffer overflows at compile time
* Code analysis tools designed to catch common buffer overflow vulnerabilities
* Operating system features designed to limit the damage of buffer overflow and other exploits
* Software testing regimes designed to find buffer overflow bugs, whether systematically or at random
See also the comments in http://catless.ncl.ac.uk/Risks/21.84.html#subj10 
-- The Anome
Nice idea. Implement it as you want. I don't know if it will be probably better to make a new page "Attempts to solve the buffer overflow problem" and let "buffer overflow" page describe the problem. What do you think about this?
-- Tuxisuau
:Feel free to split the page up if it feels "too large". (I don't think it's gotten to large yet, or I would have done it myself.) --DavidCary 01:00, 6 Nov 2004 (UTC)
thread_title: Programming language issues

message: Is there some reason that buffer overflow shows the stack growing in completely the *opposite* direction as stack (computing) ?
For a moment, I thought Aha ! I know how to solve the buffer overflow problem ! Simply grow the stack in the opposite direction, so the "extra data" simply flows off the garbage end of the stack.
Alas, now that I've thought about it some more, I see the buffer overflows can happen no matter which way the stack grows. (If the stack grows towards larger addresses, problems no longer occur when buffers allocated *after* the function call overflow. However, buffers allocated *before* the function call, and passed to the current function for filling, can overflow and overwrite the return address one way or the other, no matter which way the stack grows.)
I think I'm going to change the example to show the stack growing in the "standard" direction (left-to-right), unless someone objects.
(Of course, then I'm going to have to have buffer allocated *before* the function call.).
--DavidCary 01:00, 6 Nov 2004 (UTC)
thread_title:  right-to-left or left-to-right ? 

message: Perhaps someone can think of a better title than myself, as this isn't the complete history of buffer overflows, only some notable ones in the past decade or so.  Also edited out the somewhat amateurish rip on M$.  Although their infamous product lines are vulnerable, our Unix variants haven't been altogether immune either.  In general, advocacy seems pretty unnecessary when discussing this technology-neutral but very relevant computational exploit technique.  cs at the university of michigan  (Unsigned comment by 68.40.167.39) 
:Well, my understanding of the history of buffer overflows is that the original Unix tools that were implemented by Ken Thomspon et al, were rife with rampant BOs.  Part of the free software foundation's claim to fame is that when they tested their reimplmentations with a "random inputs" test hoist, that their tools had far fewer buffer problems than the commercial Unix implementations. Then of course there was the Morris worm.  Over time Unix and Linux, of course, have gotten a lot better to the point where buffer overflows in the core tools are extremely rare.  As windows and internet became popular starting at a later date however, Microsoft had not yet learned the lessons that Unix already had.  So its not surprising that they have been failing over and over again throughout their entire software stack.  You can argue that MS has indeed been getting better lately, however, I think that story is far from over. Qed 12:50, 24 December 2005 (PST)
::Actually, no, I've recently had occasion to revisit a lot of 1970s Unix code, and it is remarkable how careful the old-timers were to prevent buffer overruns, in assembly language as well as C.  Most of the bad problems surfaced in code originally written by students at UCB Berkeley, which was adopted en masse by vendors when Internetworking started to become popular. — DAGwyn 23:30, 2 October 2006 (UTC)
replies: text: Well if any of that code from the 70s survived to the modern Unix kernels then what you say is simply untrue.  I found the papers in question, you can read through them for yourself: http://www.cs.wisc.edu/~bart/fuzz/ .  The fact that you can't find the bugs doesn't negate the fact that an objective randomized test can.  The papers make it clear, that all Unix vendors were roughly the same and pretty bad (with only the GNU utilities showing any distinction in stability.)  Look, one of Thompson, Richie or Kernigan put "gets()" into the C library.  So we know for sure that at least one of those guys was a poor amateur programmer at the time, that just put buffer overflows into his code. Qed 11:15, 3 October 2006 (UTC)
thread_title:  History 

message: This article doesn't read like an encyclopedia and the introduction needs rewording to improve clarity and succinctness. I'll attempt to improve it at some point. This article needs to be cleaned up, since the layout and explanation is inferior to many other sources on the internet. Our aim should be to produce something which is technically accurate and yet easy to understand. There is also a wealth of extraneous information not directly related to Buffer Overflows per se.
Tompsci 12:38, 17 December 2005 (UTC)
thread_title:  Article Style and Generality 

message: It was written that the problem of buffer overflows "can be avoided by sufficient bounds checking on user inputs" - I disagree with this, as shown by the following example:
 #include <string.h>
 
 int main(void)
 {
   char *buf1 = "12345"
   char buf2[4];
   strcpy(buf2, buf1);
 }
No user input involved, but it's still a buffer overflow.
Because of this, I've taken it out. (Note: I'm 217.147.80.73) Parasitical 13:39, 22 December 2005 (UTC)
thread_title:  User input and bounds checking 

message: From Technical Description:
:A more technical view of this would be best explained by using C or C++ to demonstrate a stack based buffer overflow. Heap based buffer overflows are another danger to consider. This example is based around x86 architectures, but works for many others.
Took it out, it's unencyclopedic.
From Executable space protection for Windows systems:
:The NX bit is used to mark pieces of data (particularly the stack and the heap) as readable but not executable, thus preventing data on an overflowed stack from being executed. The NX flag can be enabled and disabled per application, and is only currently available on some 64 bit CPUs (regardless of the OS being 32 bits or 64 bits).
Took it out, it's redundant.
:Microsoft software DEP provides additional protection takes another approach, preventing the so-called SEH exploit (using a buffer overflow to overwrite an exception handler's address pointer in order to take control).
Took it out, it makes little sense.  Exception handlers are just on the stack, like any return address.  Any write protection scheme will protect both return addresses and exception handlers.
From Use of safe libraries:
:Although in ideal cases they can prevent buffer overflows, if such libraries are designed and/or used incorrectly other security problems can occur as a result of their usage (such as undesirable truncations, data or memory leaking, making a stored reference stale upon resize, etc.).
Replaced it with a shorter sentence.
From Programming language choice:
:Sometimes it is claimed that C is a faster language, in part because it does not perform automatic array bounds checking.  This is a debatable point, since it depends on usage (it is easy to construct benchmarks or cite tests which show either that there is performance impact or that there is none).  Programs that tend to deal in blocks of data at a time will tend to be more performance limited by block manipulations rather than bounds checking, and thus not be significantly impacted by bounds checking.  However programs that deal in item-by-item manipulations and where the compiler is unable to hoist the bounds checking can measure a performance impact.  It should be noted that block based algorithms are usually faster than than comparable item-by-item based algorithms since they provide greater natural amortization of memory bandwidth (and even ALU bandwidth if SIMD instructions are available).  
:Some higher level languages may intrinsically assist the compiler in hoisting of bounds checking by the very design of the language (most high level languages make a sharp delineation between arrays and pointers whereas C does not, furthermore many language abstract the concept of a range whereas C does not, and finally many languages provide type and instance seperation of data that makes aliasing impossible whereas C does not).  In many cases this can allow a higher level language to remove a runtime check using static analysis.
:What this means is that in some cases a C program can be faster as compared with a similar C program that has bounds checking, but might not be faster than a similar Ada program which relies on the language's built-in bounds checking.  However, on the other side, the automatic bounds checking typically cannot be removed from other higher level languages (though a given compiler might provide a mechanism for removing them), so for those cases where bounds-checking are non-removable and has a performance impact, the C language can provide faster implementations.  (As with all things having to do with performance, things often don't come down to one single programming mechanism, such as bounds checking.)
Dropped the sermon, replacing it with the much simpler:
:Static analysis can remove many dynamic bound and type checks, but poor implementations and awkward cases can significantly decrease performance.
Additionally, I added a mention above that "technical, business, and cultural" reasons can make using C/C++ necessary.  The rest of this can go somewhere like bounds checking or dynamic typing, but this isn't the place for it.
Dropped the pointer swizzling ref, I think the original editor meant something else.  (I don't know why, as "swizzling" is such a precise and clear term.)  I dropped the cleanup tag, as I think it looks pretty good now.  More formal, concise.  I think it could really, really use some stack illustrations.  How old is the slashdotted tag?  What's the deal with the factual accuracy tag — any specific complaints?  I'd love to see a few pictures and a "featured article" tag replace them both. :) --Mgreenbe 23:03, 3 January 2006 (UTC)
thread_title:  A number of edits 

message: The negative buffer overflow can have vulnerability on the platform that the stack grow from low to high memory address.
My question is, Is there a platform with such stack direction?
If such platform does exists, this article may list this platform dependent information for various platform.
--Ans 07:34, 13 July 2006 (UTC)
replies: text: Buffer overflows are a problem regardless of the direction in which the stack grows and yes there are such platforms. I don't think it's neccessary to list platform specific information as we only need discuss the general case. -- Tompsci 07:01, 14 July 2006 (UTC)
thread_title:  Stack direction and platform dependent information 

message: Hello again, sorry if i might have overreacted a little bit. But...please explain why you did increase the prominience of MS in especially the section "Executable Protection" and the seperately linked article for it. Why did you decrease the PaX promininence (it was moved to the end), you even removed the reference to the PaX site. All you left was a link to the sub section ASLR on PaX. However I reorderd it, if i see that again happening i'll take appropriate steps.
: If you have a problem with me, take it up with me on my talk page, otherwise, feel free to provide quality edits. -- Tompsci 10:55, 12 August 2006 (UTC)
thread_title:  Prominence of MS 

message: :Microsoft DEP's software based approach does, opposed to the widespread believe of protecting from buffer overflows, explicitly protect from one specific exploit that occured one time only and is based on overwriting the pointer to the SEH Exception Handler.
This doesn't seem to make sense, only one specific exploit overwrites the SEH to gain control of program flow? How does it not protect from *any* buffer overflows? How does this behaviour change between software and hardware enforced DEP? Detailed information on DEP itself may be better placed in a seperate article? I think It might be best to discuss Non-Executable Memory Regions generally on this page and the operational sematics of the individual solutions and weaknesses on seperate pages. This page is intended to give a broad overview of Buffer Overflows and leave the interested reader to read other related articles. Let me know what you think. It might be useful if you registered a username so that people can tell which edits are yours and so you can be contacted via your talk page. Cheers, Tompsci 01:23, 16 August 2006 (UTC)
thread_title:  DEP 

message: I added a section on software protection through use of instruction simulation but it was completely removed - reason "not to do with buffer overflow". I think it should go back as it covers overflow of any kind of memory segment of finite length.
see above "Software testing regimes designed to find buffer overflow bugs, whether systematically or at random" for suitable heading for this category although the technique does not just aplly to testing if you are prepared to accept an overhead indefinitely or for an extended time or for critical sections of code etc.Below is the text string for it I pulled off history. It appears as though the formatting is destroyed but this is the wording.ken 16:00, 11 September 2006 (UTC)
thread_title:  Software protection (removed) 

message: - 	It is possible to prevent buffer overflow and all other types of ("STORAGE VIOLATIONS") by executing the target program in emulation mode, under control of another software program - the "monitoring program". 	 
- 	The monitoring program checks that the target program "owns" the memory location it is attempting to modify before execution. Where used, this is typically performed during the Testing and debugging stages of program development although it has been used very sucessfully in later bug detection while attempting to recreate the original bug. 	 
- 		 
- 		 
- 	If the monitoring code is well designed and reliable, this method will detect 100% of all attempts to overflow buffers, alter protected memory locations and also detect any other "illegal" operations such as attempts to execute "priviliged" instructions such as restricted Kernel (or OS/360 Supervisor calls or "SVC's") with potentially damaging consequences. 	 
- 		 
- 	The interplay of many different applications or threads competing within the same address space can create unique and infrequently occuring contentions for memory or system resources with sometimes conflicting priorities. 	 
- 		 
- 		 
- 	Without access to a monitor program during the testing phase of program development, buffer overflow or storage violations can be the most difficult of all bugs to locate. The bugs themselves may lie dormant for weeks, months or even years and only show themselves after particularly heavy usage of a program or an unusual combunation of data values. 	 
- 		 
- 		 
- 	The monitoring program adds some additional overhead to the execution of a target program but during testing or bug finding this is usually quite acceptable. If a bug is to be located after a "production" failure (that is - not in a test situation) it is often acceptable to re-run the program with the same data but under control of the monitor in order to try to detect the error. In these circumstances, a small overhead would normally be acceptable for a time. 	 
- 		 
- 		 
- 	As a "spin off" benefit to the process of storage monitoring, the monitoring program can not only halt execution before any damage is done but, by tracing each and every instruction along the path, can provide invaluable information to the programmer to locate the cause of the bug. The monitoring program normally operates at machine code level but commercial products were frequently able to display the error at pseudo source level dissassembled or even original source level. See "Products" below for examples. 	 
- 		 
- 		 
- 	Even with this level of error detection it is still possible to miss a bug that only occurs under very special circumstances because only the path actually executed by the target program is monitored for bugs. This is however akin to saying that it is impossible to explore every conceivable set of circumstances through testing - a well established fact in software engineering when there are an exponential number of possible paths through a program.
*I have removed this and your other changes for now since most of them were unnecessary and made some style changes which were incorrect. I don't see any reason not to include the above as a section in some form, but at present the tone seems a bit off and the whole section is pretty unclear. I don't have time right now, but a bit later I'll have a longer look and suggest a reformatted version. It would help if you could provide some references on this, or links to a few monitoring programs. NicM 15:27, 12 September 2006 (UTC)
thread_title: Software protection