31–40 of 48 posts
Alternatively (just the concept, this should not work as outlined on modern systems): http://phrack.org/issues/49/14.html
Smashing the Stack in 2010 (linux, windows) - http://www.mgraziano.info/docs/stsi2010.pdf
Smashing the Stack in Windows 8 - https://archive.org/details/SmashingW8Stack
Earlier quoted context omitted.
>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.
Also 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.
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++.
One 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/
>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.
The 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.
It's not just their size, but wouldn't all arrays need know the address of their first element too? For example, consider a simple char buffer: char buf[512]; where we want to read x number of bytes from a file descriptor starting from a offset other than the first element: read(fd, buf + 256, sizeof(buf)); // Whoops, incorrect sizeof, buffer overflow! Could the compiler still detect this buffer overflow error withou…
Many, many, many moons ago, C strings won out over Pascal strings. If the competition was somehow re-run from scratch today, with modern machines, it would be no contest: Pascal strings would win. But there was a time when every byte was precious. And not just "a bit precious", but very precious.
Earlier quoted context omitted.
Also 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.
How 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…
Earlier quoted context omitted.
How 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…
The 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.
I'll bet there are lots of legacy codebases that would actively resist using such a compiler technology for C/C++ because of unknown behaviours happening in their codebase (and because there is no test suite, or just poor test coverage).
One 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/
>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.
Alternatively (just the concept, this should not work as outlined on modern systems): http://phrack.org/issues/49/14.html
I 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.
Earlier quoted context omitted.
It's not just their size, but wouldn't all arrays need know the address of their first element too? For example, consider a simple char buffer: char buf[512]; where we want to read x number of bytes from a file descriptor starting from a offset other than the first element: read(fd, buf + 256, sizeof(buf)); // Whoops, incorrect sizeof, buffer overflow! Could the compiler still detect this buffer overflow error withou…
The solution does involve storing a length, and this is called a Pascal string: https://en.wikipedia.org/wiki/String_%28computer_science%29#... Many, many, many moons ago, C strings won out over Pascal strings. If the competition was somehow re-run from scratch today, with modern machines, it would be no contest: Pascal strings would win. But there was a time when every byte was precious. And not just "a bit precious…
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
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).