Talk:Buffer overflow: Difference between revisions
imported>Pat Palmer (→Technical explanation not technical: I think it's mainly an x86 thing) |
imported>Pat Palmer (→Technical explanation not technical: oops forgot to sign) |
||
Line 22: | Line 22: | ||
:Why not [http://en.citizendium.org/wiki?title=Buffer_overflow&action=edit correct] the article then? --[[User:Eric M Gearhart|Eric M Gearhart]] 14:51, 11 April 2007 (CDT) | :Why not [http://en.citizendium.org/wiki?title=Buffer_overflow&action=edit correct] the article then? --[[User:Eric M Gearhart|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. | ::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.[[User:Pat Palmer|Pat Palmer]] 18:36, 19 April 2007 (CDT) | ||
== More for software == | == More for software == |
Revision as of 17:36, 19 April 2007
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 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
- Computers Category Check
- General Category Check
- Category Check
- Advanced Articles
- Nonstub Articles
- Internal Articles
- Computers Advanced Articles
- Computers Nonstub Articles
- Computers Internal Articles
- Developed Articles
- Computers Developed Articles
- Developing Articles
- Computers Developing Articles
- Stub Articles
- Computers Stub Articles
- External Articles
- Computers External Articles
- Computers Underlinked Articles
- Underlinked Articles
- Computers Cleanup
- General Cleanup
- Cleanup