[email protected] (Mike Schwab) writes: > Most of your Micro$oft and Linux errors are due to the C language > defining an end of string as x'00', and the programmer forgetting to > check the lenght of the input against the buffer. The the hacker > sends a malformed string to that function and overlays the program > code and takes control.
buffer length related problems dominated through the 90s ... misc past posts http://www.garlic.com/~lynn/subintegrity.html#buffer much of desktop evolved in purely stand-alone enviornment ... with some early (3270) terminal emulation. then was added, private, business, closed, "safe", network support ... with lots of applications & files that included automated "scripted" enhancements. At the 1996 MDC (held at Mascone) there were huge number of banners about moving to internet (simple remapping of the networking conventions w/o the corresponding countermeasures involved moving from "safe" environment to extremely "hostile" environment; periodic analogy with going out airlock into open space w/o space suit). However, the constant subtheme (at '96 MDC) was "protecting your investment" ... referring to all the scripting capability. Starting early part of this century, such exploits began to clipse the buffer length problems ... along with the heavy weight security convention of analyze/filtering incoming files against an enormously bloated library of possible exploit "signatures" old post doing word frequency analysis of CVE "bug" reports ... and suggesting to mitre that they require a little more formal structure in the reports (at the time, I got pushback that they were lucky to get any reasonable verbage): http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE more recent reference to CVE ... which has since moved to NIST http://www.garlic.com/~lynn/2011d.html#8 Security flaws in software development note that the original mainframe tcp/ip protocol stack had been done in vs/pascal ... and suffered none of the buffer length exploits found in C-language implementations. there were other thruput and pathlength issues with that implementation ... but I did the RFC1044 enhancements for the implementation ... and in some testing at Cray Research ... got sustained channel throughput between Cray and 4341 ... using only modest amount of 4341 processor. misc. past posts mentining RFC1044 support http://www.garlic.com/~lynn/subnetwork.html#1044 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
