Re: safestr alpha (Safe C String Library)

On Tuesday, February 11, 2003, at 09:54 PM, kevind@esi.com.au wrote:

> On Tue, Feb 11, 2003 at 11:01:25AM -0800, Kim Reece wrote:

Fair enough. I've been keeping pretty quiet, letting John field the mails both privately and on the list, but at this point, it feels to me like we're getting to the point of beating a dead horse. I think the discussion has been useful and helped John and I solidify a solution for the error handling problem.

One point that I don't think has been made to date is that the vast majority of errors that the library can throw are programming errors--errors that should never occur in production level code. There are exceptions, of course. Most notably, dynamically growing a string could yield an out of memory error. Let's take a quick look at the possible errors in the version that has been released:

1. Expected a safestr_t and got a NULL instead
2. Expected a safestr_t and got something that isn't a safestr_t (which could potentially even cause a read access violation or unaligned data access)
3. Attempting to modify an immutable string
4. Attempting to resize a non-resizable string
5. Out of memory attempting to resize a string
6. Could not open /dev/urandom (or create a crypto context on Windows)
7. Formatting string errors (including misuse of format modifiers; overflowing int on width, precision, or C99 argument specifier; or using %n)
8. Possible double free attempt in safestr_free()/safestr_release()
9. Index out of bounds in safestr_charat()/safestr_setcharat()

So there are nine basic errors, at least eight of which can be considered programming errors (out of memory being the straggler here).   Arguably, #3, #4, #7, and #9 (perhaps also #8, but that's a bit more of a stretch) could signal a possible attack. For any of the errors possibly thrown when an attack happens, what are you going to do programmatically to defend against or recover from the attack? There's really not much you can do. Not safely anyway because the integrity of your application has been compromised, and you have no idea to what extent. We're back to one possible error that you might be able to do something about, and that's this out of memory problem (persistent little bugger, ain't it?)

My personal feeling is that the default behavior of the library should be to abort on any one of these errors. However, it is reasonable to provide a callback mechanism for anybody that does want to make use of it. This callback should receive an error code, the problem string, and the function that's throwing the error. If the callback returns, return an error code to the caller. My strong advice would be for any callback to print an appropriate message, maybe make a log entry or something (though the ability to do so reliably at this point is shaky at best), and abort.

It would seem reasonable to handle out of memory conditions in an alternate manner, but you can already do this (mostly--you still can't return an error code and avoid the abort yet) using safestr_setmemfns() and providing a replacement for malloc()/realloc() that handle the out of memory condition (maybe by freeing some reserved memory or something).

To sum up: At this point, we do plan to add a callback mechanism for errors. The default callback if none is specified will simply print an error message and abort, much like what already happens at present. If a callback is set and it returns, an error code will be returned from the function that threw the error, leaving it up to the caller to deal with, though the caller will not be given any details of what type of error occurred. It will be up to the callback function to make that information available, possibly by some kind of errno type global variable.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

> Calls to the various string routines share a lot of common error
Received on Wed Feb 12 17:00:19 2003