13 ms·
How security flaws work: the buffer overflow
- kriro 11y agoAlternatively (just the concept, this should not work as outlined on modern systems): http://phrack.org/issues/49/14.html http://phrack.org/issues/49/14.html
- zobzu 11y agoi like this one better.
- billyhoffman 11y agoI used to use Aleph One's article as a kind of shibboleth when interviewing candidates for security researchers. I'd just casually say "Smashing the stack..." and see if they would fill in the rest of the title. Not the best data point, but showed pretty quickly who had a self-taught (and usually practical) understanding of security vulnerabilities vs an academic understanding.
- ecesena 11y agoSome updates: Smashing the Stack in 2010 (linux, windows) - http://www.mgraziano.info/docs/stsi2010.pdf http://www.mgraziano.info/docs/stsi2010.pdf Smashing the Stack in Windows 8 - https://archive.org/details/SmashingW8Stack https://archive.org/details/SmashingW8Stack
- cm2187 11y agoThe worse is that this error only happens because we are trying to save 4 bytes. If all arrays would also store their own size we could eradicate this bug with a limited memory impact.
- saurik 11y agoYou have overlooked the CPU cost. Given that most memory objects already have at least an over-approximate size somewhere, and how we are more than happy to annotate stacks with canaries, I really don't think anyone is as concerned with the memory cost of adding a size to every array as the CPU cost of adding a read and compare to every array access.
- cm2187 11y agoI am not necessarily suggesting checking array boundaries on every array access, but at least providing an easy and safe way to refer to the array size. Array boundary checking is I think desirable but I can understand that for some applications it is an unacceptable performance hit.
- seanwilson 11y ago> Array boundary checking is I think desirable but I can understand that for some applications it is an unacceptable performance hit. Given the severe potential security implications for not using it, enabling bounds checking is a sensible default in my opinion. People always mention the speed of C for example but ignore what is being sacrificed for it.
- wslh 11y agoThis exists for years: https://msdn.microsoft.com/en-us/library/windows/hardware/ff565508(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/hardware/ff...
- ctz 11y agoIntel is adding hardware array bounds checking called MPX in skylake, so this could become a reality.
- ghuntley 11y agoOne of the best explanations ever written is the now classic "Cult of the Dead Cow issue #351 - The Tao of Windows [NT|95|98] Buffer Overflow" @ http://www.cultdeadcow.com/cDc_files/cDc-351/ http://www.cultdeadcow.com/cDc_files/cDc-351/
- drzaiusapelord 11y ago>but if you don't have automatic bounds checking like Java, I guarantee you that those 'A's are going somewhere unfortunate. 20 years later and we're still using C++. I hope Rust takes off. The status quo today is terrible.
- dmix 11y agoAlso of note is the lack of investment in exploit mitigation at the operating system and compiler level. C++ and C are not going away from our systems any time soon. Yet exploit mitigation technology still remains on the sidelines of the security world while bug squashing, AV, and IDS are flush with cash.
- drzaiusapelord 11y agoHow realistic is a compiler-level change that is 100% transparent and reverse compatible with existing codebases? I suspect this is a tough nut to crack without making fundamental changes to the language and perhaps invalidating past codebases. You might as well move to a different language then. I suspect we'll have a Rust compiler that compiles fast applications with a very minor performance hit before this happens to aging languages like C/C++.
- dllthomas 11y agoThe question is not just when we will have the tech, though. It is also when the tech will have an impact. A perfect Rust compiler only improves the safety of new (or rewritten) code.
- jakozaur 11y agoThere were so many critical vulnerabilities attributed to that... and in spite of putting tons of measures this is still potential danger. I knew projects decided to use Java instead of C++ (which got array boundary checks) mostly to limit security surface. Maybe if we could start CPU architecture from scratch, array with sizes would make more sense? Maybe even we could done it so memory segmentation would no longer be needed: https://en.wikipedia.org/wiki/X86_memory_segmentation https://en.wikipedia.org/wiki/X86_memory_segmentation Haven't figured out the details, but maybe we can even gain some performance that way.
- shanemhansen 11y agoFriendly reminder: it's not just a choice between C and Java. In order to get bounds checking on arrays it's not necessary to give up the advantages of native programming and use a virtual machine. Rust is obviously a great example. So is Go. Bounds checked arrays in languages that compile to native is not a new thing.
- Alphasite_ 11y agoSwift is another new language with it. Its getting to be the norm now.
- nickpsecurity 11y agoSmart thinking. It was already done in a dozen different ways. Two cited in my comment: https://news.ycombinator.com/item?id=10125348 https://news.ycombinator.com/item?id=10125348 Also see capability-based computer systems by levy. Free book. Pointer protection by itself can give all kinds of benefits. Modern version of that is Cambridge's CHERI processor which is open-source and already runs FreeBSD. :) https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- rawdisk 11y agoAre "buffer overflows" possible in systems without without virtual memory? I know how I would answer this question but I am curious how others would answer it. EDIT: s/possible/known to occur
- pyre 11y agoAs long as you have the ability to address memory directly, I would say that it's possible. I'm not 100% sure about how memory is allocated though. Outside of virtual memory, are the actual chunks of memory sequential, or would overflowing an offset get you a chunk of another process? (I imagine the answer might be implementation dependent)
- shanemhansen 11y agoIt's more important to have bounds checked access and to disallow pointer arithmetic. If you do that, pointers (addresses) are fine.
- scott_s 11y agoYes. Why would you think not? If you're thinking that memory for the program is less likely to be contiguous, then, yes, that is a way it may end up being less likely. But there are already techniques that do exactly that for systems with virtual memory (see https://plasma.cs.umass.edu/emery/diehard.html https://plasma.cs.umass.edu/emery/diehard.html). But as long as you have a stack frame contiguous with a previous stack frame, you're susceptible to buffer overflows, and I think that will be likely even without virtual memory. (That is, the stack frames are not that large, and are likely to be well within the contiguous block size for the memory system.)
- tptacek 11y agohttps://microcorruption.com/ https://microcorruption.com/
- segmondy 11y agoSeriously this is old news 20 years too late and not even good enough, checkout Phrack article, "smashing the stack for fun and profit" written in 96. This is what unleashed the flood gates. With sample codes to boot.
- nickpsecurity 11y agoThe Burrough's architecture (1961) had a CPU that bounds-checked arrays & pointer access. Also differentiated code and data to prevent... all kinds of security issues. Total overhead in memory was 6% w/ almost zero overhead in CPU in such a design if you run security-checks in parallel with rest of pipeline while only committing a write if security check is OK. This is the modern approach. http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr... No matter what naysayers claim, the ability to inexpensively immunize a system against buffer and stack attacks has existed for decades while being deployed commercially on 1960's-1980's era hardware. The market went for what was backward compatible with IBM, UNIX, and later DOS software plus highest raw performance at lowest price. Systems designed for excellent security and maintenance (esp written in HLL) had low market share with many getting acquired, disappearing, or having security advantages removed in later releases. It's a market thing, not a technical thing. Here's a modern example, the SAFE architecture, that's being developed by BAE & academia. http://www.crash-safe.org/assets/ieee-hst-2013-paper.pdf http://www.crash-safe.org/assets/ieee-hst-2013-paper.pdf It's actually more heavyweight as it tries to fix... computing in general haha. It specifically mentions buffer overflows and stack risks with the ways they try to immunize against them. The atomic groups with associated processing are actually lightweight a la Burrough's model. They alone provide quite the bit of protection seeing how many types of attack leverage pointer, array, or stack flaws. The other tag will cause more of a hit but could do type enforcement of calling functions. Is also very helpful given interface errors underlie most attacks on systems. I've suggested porting Oberon System and compiler to this architecture to get a fully-usable box with automated protection. And see what attacks can still get through. In any case, buffer overflows have been preventable since before they even had a name past being an example of "insufficient argument validation" (MULTICS security evaluation). They only exist because (a) market wants them to exist via how it votes with its wallet and (b) legacy software refuses to take the hit that automated protections created. The latter situation improved greatly with tools such as Softbound + CETS which enforces full safety on C code with average 50% hit, limited tools such as Control Pointer Integrity that protects pointers with a tiny hit, and tools such as ASTREE/SPARK that prove C/Ada code free of many types of errors that lead to crashes or hacks. Pretty much no uptake. There are counterexamples though. I've seen a reverse stack on x86, a DNS server (IRONSIDES) written in SPARK, security kernels that extensively used segmenting for OS-level POLA, a web application server reducing risk w/ FSM's + a separation kernel, and recently MirageOS building a whole stack in a language that prevents so many issues at compile-time while designing for isolation in partitions. So, we can do it better, some are doing it better, and I encourage others to do the same. Look for work that knocks out issues, use it, improve it, and get our baseline up to at least OK instead of FUBAR (current status).
- bootload 11y ago"The buffer overflow has long been a feature of the computer security landscape. In fact the first self-propagating Internet worm—1988's Morris Worm—used a buffer overflow in the Unix finger daemon to spread from machine to machine." I thought the daemon exploited was sendmail? ... quick search later ... so the fingerd was used. Good explanation here: ~ Eugene H. Spafford, "The Internet Worm Program: An Analysis" http://spaf.cerias.purdue.edu/tech-reps/823.pdf http://spaf.cerias.purdue.edu/tech-reps/823.pdf