Buffer overflows are currently the most common cause of security flaws in applications. Discover the techniques that professionals use to thwart this problem in this article by John Mueller.
Preventing Buffer Overflow In Visual C++ Applications
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
…&& i < BUF_MAX…
Microsoft developers?
Use the tools provided. Learn the STL, don’t use raw buffers anymore, use a vector or a string.
Gregor
Remember that for both vector and string, operator[] is unchecked, so just using a vector or string won’t necessarily prevent buffer overflows. Besides, I get the impression that programmers in the MS world are not really encouraged to use STL containers.
Someone should write a mail to the author and tell him about stl (Remember to use at insted of [] for range checked access)
exceptions, and seperation of error code from normal code.
I’ll vouch for the STL here. Even if you don’t use range-checked access, it still greatly diminishes your chances for memory errors. The first time I really used the STL was for a simulation (x-ray diffraction). Several thousand lines of code, not a single new or delete to be seen. Thanks to the algorithms, there were very few for loops (and the attendent chances of overstepping bounds in those).
I greatly prefer Qt over the STL, and Qt provides *significantly* more functionality, while exporting a great high level C++ API.
Oh great, so a gui library is now trying to replicate a templated collections and algorithms library? That makes a lot of sense. Not! I guess that’s how they can get some people to justify the $1500/developer/app. Look, we’ve now duplicated the STL. You’re getting your money’s worth.
“This particular security problem is responsible for more virus infections than perhaps all other sources combined.”
If virus = network worm, then perhaps. Blaster was big, but there have been plenty of worms NOT relying on buffer overflow in services.
“The problem is so prevalent with Microsoft Windows that Microsoft is taking a different approach to the problem with releases of products such as Windows XP Service Pack (SP) 2”
Well I certainly hope it’s better than the stack protection in Server 2003. 🙂
“The purpose of this article is to help you understand buffer overflows more clearly and to give you simple techniques you can use to reduce (or hopefully eliminate) this problem in your applications.”
Use Stackguard and Formatguard.
“The Cyberguard paper titled “Buffer Overrun Attacks” describes buffer overruns in greater detail.”
In addition, read Aleph’s article and anything by Aitel and Hoglund.
“However, in some cases, an exploit is discovered when a cracker tries typing something into a field to see what will happen. For example, a cracker might try to type a simple script to see if your application will execute it.”
A simple script for remote command execution via a stack or buffer overflow?! Maybe a DoS. Keep the terms straight, if this paragraph is about format bugs instead, you need to be clear.
“Many developers think that crackers hatch devious plots to make use of the exploits they create, but many exploits are simple—the simple act of telling the operating system to display a command prompt is enough to gain control in some cases.”
Yes a simple payload is always a worthy goal. And binding a shell to some port may not be good enough because of firewalling. Add in the fact that some payloads need to be very small, and it gets tricky. In addition, the IDS (intrusion detection system) is watching for malicious code, and the attacker must morph the shell code further. It may not be the toughest programming in the world, but they aren’t exactly baking cakes either.
“Crackers often include extra illegal characters in their input to see what happens. For example, a cracker can often create a script by adding special characters.”
I thought this was about buffer overflows, now you are mixing in format bugs.
“Web applications are more susceptible than desktop applications to this exploit, but you need to protect both.”
There are a billion ways to get local admin on a desktop.
“Many developers would never associate help with good security, but good help does improve security by making user mistakes a little less likely.”
This is half the point behind OSS.
“No matter what you do, some users will attempt to abuse the system. They’ll enter the date using the wrong format or even type something that has nothing to do with a date.”
I’ve seen a lot of bugs in desktop apps. More of an annoyance, than a security risk.
Oh great, so a gui library is now trying to replicate a templated collections and algorithms library? That makes a lot of sense.
Qt is much, much more than a “GUI library”. Qt is a cross-platform application development library. It supports database connectivity, sockets, FTP/HTTP, XML, has full Unicode support, and yes, a cross-platform GUI API.
And yes, Qt has its own counterparts of many things you’d find in the STL, such as QStrings instead of STL strings, but as the ANSI string class lacks Unicode support, why would I even bother using it when QStrings have them?
std::basic_string<wchar_t> ? (if i remember correctly)
Shouldn’t the compiler tool chain (together with OS) segregate the executable code space (begining), the heap (middle) and the stack (at the end of the memory space). In the binary format, keep track of the end of executable code space, and trap (raise an exception) the second you wish to execute code which resides in the heap/stack. Doesn’t this approach seem the most logical to permanently deal with stack overflow issues?
Sorry, I know its bad form to reply to myself. Continuing post…
Also, raise an exception the moment the stack overwrites the heap/executable code boundary. Debuggers have been trapping code when certain memory regions have been acccessed for years now.
QString is a perfect example of an API with hidden bombs. It’s conversion to c string ( ascii() ) may return a null ptr, meaning it always has to be bloody checked, something that is easy to forget, and easy to get away with for a long time. std::string always returns a valid ptr to an empty string. Much safer, no need to check…
I don’t see Qt and the STL at odds. The two are different paradigms. Qt is dynamic and object-oriented. The STL is static and value-oriented. When I’m writing GUI code, I write in the QT style using Qt classes. When I’m writing my own code, I use the STL style and STL containers.
Shouldn’t the compiler tool chain (together with OS) segregate the executable code space (begining), the heap (middle) and the stack (at the end of the memory space).
In the binary format, keep track of the end of executable code space, and trap (raise an exception) the second you wish to execute code which resides in the heap/stack.
This can’t be done without help from the processor or a runtime. All modern RISC architectures, as well as x86-64, provide support for such a system with page permissions, which allow code in kernel context to specify which operations may be performed on addresses in a given page while in process context. When properly utilized, these would allow the OS to load all code segments into pages marked executable only (meaning the instruction pointer is allowed to point to them, but no load/store operations on these pages are allowed), and stack/heap pages to be marked read/write (meaning that a jump or any other attempts to point the CPU’s instruction pointer to an address in these pages generates a trap/exception). In this way, the instruction pointer cannot point to any page which can be modified in process context, eliminating the canonical “stack smash” approach to exploiting a buffer overflow, by placing shellcode in a stack variable and overwriting the return address of a stack frame to point to the start of the shellcode.
This sort of protection is at least partially implemented on Solaris 7+/SPARCv9, which provides a non-executable user stack per default for all SPARCv9 binaries (and optionally for SPARCv8 binaries as well through a kernel variable)