Talk:Buffer overflow

Article Checklist for "Buffer overflow"

Workgroup category or categories	Computers Workgroup [Editors asked to check categories]
Article status	Developing article: beyond a stub, but incomplete
Underlinked article?	Yes
Basic cleanup done?	Yes
Checklist last edited by	--Eric M Gearhart 09:54, 12 April 2007 (CDT)

To learn how to fill out this checklist, please see CZ:The Article Checklist.

---

Editors please comment on what more this article needs for approval

The CZ community did a great job taking this article from the "embryo" I created and ironing out an encyclopedia-quality article. I'd like to ask our editors for input on what more development this article needs before it is ready for approval Eric M Gearhart

We still need someone to write about OpenBSD's W^X-bit strategy. --Nick Johnson 13:47, 19 April 2007 (CDT)

Well the whole thing with Approval status is that an article has to have an encyclopedic tone and has to cover enough relevant topics. It doesn't have to be "perfect," it has to be "worked up" enough though. The W^X-bit is one of those things that I'd think can be added to a later draft once someone that is knowledgeable happens on it, after this version got approved. Eric M Gearhart

Technical explanation not technical

For instance, nothing "marks" stack contents as either program location or data.--Nick Johnson 14:40, 11 April 2007 (CDT)

Why not correct the article then? --Eric M Gearhart 14:51, 11 April 2007 (CDT)

In some architectures--SPARC is one, I think--data memory and program memory are segregated, so the stack is always different from code. It's mainly in the x86 architecture that it's been easy in the past to write a virus by overwriting the part of the stack that contained the return address; the newly inserted return address actually may point to bad code (which gets loaded into the stack as data but then used later as code). Or something like that. In a SPARC architecture, return addresses for procedure calls do not live in the stack at all (but rather, in special registers) so things like buffer overruns in the stack were somewhat less likely to launch a virus.Pat Palmer 18:36, 19 April 2007 (CDT)

More specifically, in SPARC, virtual memory segments are marked as read-only if they are code. These only get loaded by the linking loader. The stack is only loaded into virtual memory segments that are writable. Code and data are just not co-mingled. I'm not sure how it all plays out in x86 except that I seem to recall the return addresses live right in the stack as data, which makes them vulnerable to tampering.Pat Palmer 18:39, 19 April 2007 (CDT)

More for software

I plan on doing some research, and then adding these things under the software section:

• StackGuard and Canary Values as implemented by a compiler

Check --Nick Johnson 09:08, 12 April 2007 (CDT)

• Memory address randomization

Check --Nick Johnson 09:08, 12 April 2007 (CDT)

• Separation of privileges

Can't decide if this belongs on this page. It's a generic security safeguard, not specific to buffer overflows --Nick Johnson 10:01, 12 April 2007 (CDT)

--Nick Johnson 08:36, 12 April 2007 (CDT)

More on Hardware/Software

By the way: OpenBSD does something called W^X (write-exclusive-or-execute). I don't really know how it works, but if anyone does, it should be added here. --Nick Johnson 08:37, 12 April 2007 (CDT)

Article growing nicely

This is why I love working on wikis... I've learned as much as I've contributed to this article. Nice job Nick. --Eric M Gearhart 09:54, 12 April 2007 (CDT)

The pleasure is mine. Thank you Eric. --Nick Johnson 10:00, 12 April 2007 (CDT)

Document structure changes

I don't think that "Tools Used During Software Development", "By The Operating System", "As Language Semantics or Library Functionality", and "As Compiler Features" should be sub-headings under "Software Debugging Tools". I have changed the structure accordingly. My reasoning: the operating system, language semantics and the library itself are not debugging tools. The compiler may be considered a debugging tool, but this operation of it is not a debugging tool. --Nick Johnson 11:30, 16 April 2007 (CDT)

Yes the main reason I originally added those sections was just to "drum up ideas" for that section... technical accuracy trumps structure any day. Eric M Gearhart

smashing the stack

I think buffer overruns can occur in the heap as well if you're using a language like C. In fact, I'm sure of it. And when you overrun the memory illegally enough to reach the border of a virtual memory segment, you get a memory segment error. So "smashing the stack" I think refers to the x86 style attack of overwriting the return address of a procedure. That is a special case of a buffer overrun. A buffer overrun is not always malicious; typically, it's just a programmer's silly error (hey, every C programmer does it at least once; it's like a teenager's mandatory first fender-bender). An aside--one reason Java became so successful is that the Java runtime automatically tries to prevent buffer overruns by inserting runtime checks, and on the whole, it does a pretty good job of doing that.Pat Palmer 18:48, 19 April 2007 (CDT)

The point being, that some architectures are much more vulnerable than others to buffer overruns. x86 is generally worse than SPARC. Also, some languages (C, assembler, and native machine language) cannot be made safe. This is so much web programming has moved to "safer" languages like Java (because you don't want your web server crashing in the middle of the night); using a strongly typed, type-safe language overcomes some of the vulnerabilities of the underlying hardware and OS. Not sure how to fold this into the article...I don't think I really know enough to write it.Pat Palmer 18:51, 19 April 2007 (CDT)