OpenBSD Journal

Safe programming libraries?

Contributed by jose on from the fix-your-code dept.

anonymous writes: "Earlier I posted a question about Cyclone, a memory-safe variant of C. Continuing on the safe tools theme, I have another question: It seems to me that the good old Standard Library is full of functions that are prone to security problems (strcpy, strcat, for example), and it is also somewhat inadequate in string manipulation and other routines. libc is showing its age. Are there any alternatives or additions to the standard lib which include a rich set of safe string functions and other security-enhanced, useful functions? I found one called Safestr . Are there any others I should compare it to? Or should I roll my own stuff?"

We've posted about the SafeStr library before , and it's only getting better. Anyone been using it?

(Comments are closed)

Comments

  1. By coldie () on

    whatever happened to, or what is the status of c9x?

    Comments

    1. By Frank Denis () j@pureftpd.org on http://www.pureftpd.org/

      C9X is officially the what the C language is supposed to be for a while.

      However :

      1) It doesn't provide any safe str* replacement.
      2) OpenBSD's C library has zero support for new C functions.
      3) GCC 2.95 has very limited support for new C keywords and types.

      In fact, C9X is quite useable on recent Linux systems but when it comes to writing portable applications, it's still not an option yet.

  2. By raiten () julien.touche@lycos.com on mailto:julien.touche@lycos.com

    openbsd provides alternative to strcat & co.
    see strlcat & co

    Comments

    1. By Ralph Siegler () admail@rsiegler.org on mailto:admail@rsiegler.org

      These functions may be somewhat safer in certain contexts, but of course it's still possible to make all kinds of bad memory access mistakes using them. What's really needed is a whole new framework for allocation & use of data structures, and then the question would be if kernel and system code developers would tolerate the performance hit of a truly safe set of libraries.

  4. By supabeast () on http://supa-james.livejournal.com

    How hard would it be to just create a fork of the libraries that just don't include the bad functions-or even better, convince the original library maintainers to just phase them out entirely? What better way to stop people from using a broken tool than to just take it away!

  5. By Scott Parish () srp@srparish.net on http://srparish.net/

    Tom Lord's Hackerlab (http://regexps.srparish.net/src/hackerlab/) has some rather nice aspects to it. Its definately worth a look.

  6. By Anonymous Coward () on

    This one looks pretty good, except the LGPL license:

    http://www.and.org/vstr/

    Specifically this page is interesting:

    http://www.and.org/vstr/security.html

  7. By Anonymous Coward () on

    > Or should I roll my own stuff?

    Roll your own if you can. Ken Thompson says, "You can't trust code that you did not totally create yourself." http://www.acm.org/classics/sep95/ justifies that statement.

    Comments

    1. By gopher () on http://www.h07.org

      he also tells you not to trust compilers that you didn't create for your own. bad idea.

    2. By Anonymous Coward () on

      I've learned by experience that I can't trust my code either. Bugs and security vulnerabilities will show up in ALL code. Writing your own code removes all the experience and compiled knowledge of the libraries' writers, bugfixers and maintainers.

      Be very sure you want to roll your own and live with the results before starting down that path.

  8. By djm () on

    OpenBSD libc has safer replacements for str{cpy,cat} which don't require you to rewrite the entire application that you use them in. Some other platforms are adopting them too - all of the BSDs have them, but unfortunately the Linux glibc developers are unwilling to implement them (see this amusing post, for example: http://sources.redhat.com/ml/libc-alpha/2000-08/msg00061.html). This is little problem for portable software, as OpenBSD libc is a treasure-trove of good, portable code :)

    Comments

    1. By Anonymous Coward () on

      Actually I thought one of the posts makes an interesting point. Wouldn't it have been better for the strl* functions to terminate with an error rather than truncate? I'm guessing there is a good reason they don't I'm just not seeing? Anybody?

      Comments

      1. By Anonymous Coward () on


        Terminating with an error would probably

        (a) break too much code;
        (b) be non POSIX conformant in "style" (e.g. although the strl* functions are not POSIX defined, they are similar to str* functions which are POSIX defined, so need to preserve similar semantics);
        (c) given (b), then it's arguable that existing code should already be designed to handle long strings before being given to str*;

      2. By djm () on

        They don't have to return an error, because they make it so easy to detect truncation. Often you don't need to care about truncation. If you do, then you can test "strlcpy(a, b, sizeof(a)) >= sizeof(a)" and bomb.

  9. By yoyo () on

    C is error prone. Admit it and you could live better.

    IMHO little stuff *needs* to be coded in C.
    I'd love to see more people using VHLL in projects where cpu time is not so critical.
    Or someone should add SafeLevels in C as the ones found in ruby :))

    Comments

    1. By Boarding in Calgary () on

      I realize this is just a workaround and doesn't solve the problem per se, but what about phasing out C?

      Lately C is getting slammed constantly, but languages like C++ do avoid these hazardous functions (avoid being key word). Another alternative maybe be doing a code audit on a .NET or Java interpreter/JIT. Niether ofcourse guarantee anything but just a suggestion.

      Comments

      1. By Anonymous Coward () on

        phase C out!? you foul heathen, what the hell is the matter with you?!

        i was just discussing this with a friend the other night. sloppy C programmers have at least another five years to screw things up.

      2. By riffraff () on

        C++ and STL are probably less error prone that c and libc.
        Still, you can see that there is lot of wrong C++ code out there (cough..windo..cough..apps..cough)

        It would be lovely to have a working Open Java JIT vm.. too bad SUN is not supporting OBSD.
        Many people still don't understand How powerful java+hotspot is, they just notice the long start up time.

        BTW, if the application is not cpu intensive, I still think python or ruby are the right choice(no, not perl :-)

    2. By Anonymous Coward () on

      Everyone here will say that I am a troll, but I think that most stuff, especially stuff that handles dangerous network input, should be in Java. C is not appropriate for most of what it is used for, including most of the operating system. Performance is not such an issue anymore in these days of cheap Opteron systems. Don't whine about how Java is slow on your Pentium 66. Who cares. I'm not interested in operating systems for museum computers.

      Comments

      1. By Anonymous Coward () on

        The problem with Java used in this fashion is that it just isn't 'write once run everywhere' like Sun advertised. You need a good (great?) JVM on the platform to make good, fast java apps. Then there's the problem of interfacing with non-java code. Yes, it can be done, but it has always been and continues to be a PITA.

        As to museum computers, do we really need 2.6Ghz machines running personal routers and firewalls?

    3. By Tony () aschlemm@comcast.net on mailto:aschlemm@comcast.net

      If people that write C/C++ code actually took the time to do it properly in the first place. As a guy that's done C and C++ code for nearly 20 years I still encounter what I consider "crap" code. My biggest gripe is that I still see alot of C/C++ code being written that isn't safe in terms of memory bountaries. One of the most useful operators in C/C+ is "sizeof". Unfortunately many of the programmers that write C/C++ code can't be bothered to use "sizeof" unless something actually requres a size_t value of some sort.

      For formatted output I see alot of code using sprintf() which is bad IMHO. Anyone needing to use sprintf() should consider using snprintf() instead since it allows a buffer size to be specified which helps alleviate allot of buffer overflow problems.

      I've also done quite a bit of Java work over the last 7 years and while it improves things in some ways it isn't perfect and introduces its own set of problems.

      Comments

      1. By Anonymous Coward () on

        "Why can't people just program correctly." That's like saying, "If people would just drive correctly, we wouldn't have accidents." It's true, but even highly-trained professional drivers have accidents. The best explanation I have heard of this situation is as follows: Let's say that, for every line of code you have a probability of X of making a critical memory or buffer mistake. Even if you can get X very very low by being an excellent programmer, if you write enough lines of code, eventually, there will be a mistake. Some people say "I'm so good, I don't make these mistakes ever", but experience has shown that these people are self-deluded. Mistakes do happen.

        If the probability of a critical mistake in a single line of code is X, then the probability of a piece of software having a critical vulnerability is X * the number of lines of code. That's simple math. If we agree that X can never get to zero, then there are two choices:

        One is to make only very small applications. That's what NASA does, for example.

        The other is to make small applications such as virtual machines that allow large bodies of code to run that don't manipulate memory. That's what Java does. Evil malicious hackers or incompetent idiots or monkeys can write trillions of lines of Java code, and we still know, with absolute certainty, that as long as the JVM is correct, there won't be any buffer overflow exploits. The probability of a mistake (X * lines of code) in a small JVM implementation is constant, so these trillions of lines of crappy or mallicious code don't need to be verified.

        This is all simple math. As we can see from the various holes in OpenSSH, even the most skilled people out there do make mistakes. X is never zero. Let's instead use tools to isoalte the mistakes, like a VM.

        I know that there are plenty of self-deluded people out there who still say "learn how to program and don't make mistakes." That is nonsense.

        Comments

        1. By Tony () aschlemm@comcast.net on mailto:aschlemm@comcast.net

          Yep and even a language like Java can't save monkey's from themselves and Java most certainly does manipulate memory on a programmer's behalf every time "new " is called.

          I've been called in to work on a number of large Java projects over the last 7 years and the JVM failed in other ways even if buffer overflows were no longer a problem. Even in a protected evironment like Java programmers (monkeys) must not make mistakes! I've seen my share of lousy Java code where memory leaks abounded. All it takes is one sloppy programmer to place an object into a container and forget to remove it and now that gets repeated N times over the life of the run. After a certain amount of time, a system, that is supposed to run for months or years can't since the JVM has grown to a huge size (many 100's of MB) and eventually starts throwing OutOfMemoryErrors. In other cases I've seen systems that are nearly completely useless since multiple JVM's are consuming nearly 100% of all CPUs on a multi-CPU system.

          It's then a very long, drawn our process running memory debugging tools that allowed heap snapshots to be taken so all of the places where objects were allocated and stranded could be found and Java coding changes could be made to the system. As I said in my previous post, Java opens up another set of problems. People come into Java thinking that just because it does garbage collection that they are now free to not worry about memory allocation issues anymore.

          At least with C/C++ programmers I've never seen any of them delude themselves into thinking they never had to take any responsibility for their memory allocation in their code and everyone always used memory debugging tools on their code to make sure their code wasn't leaking memory.

          I believe that Java has its uses in certain areas but it is far from a programmer's panacia. For certain types of systems that are required to have months or even years of uptime for handling real-time event processing I don't feel that Java is up to that task yet. Even Sun doesn't have that much faith in Java for certain mission critical areas since I believe that they have placed some restrictions on using Java for things like life support machines, air traffic control, and weapon systems. HP even goes so far as mentioning not using Java controlling any nuclear facilities in their license for their JDK.

          Comments

          1. By Michael van der Westhuizen () on

            So, in summary (and yes, I'm agreeing with Tony):

            Programmers, regardless of the language or their skill level, need to take responsibility for the correctness of their code.

            Different (language) environments carry different pitfalls - developers need to be aware of them and be more careful making sure they do not fall into those traps.

            I agree with a lot of the negative and the positive sentiments expressed in the comments to this post, but most of all: no language is a panacea for all the worlds problems.

            If you want the safety, you take the performance hit and lose the control you could otherwise enjoy over your environment. You do, however, get a lot of other benefits - nobody is disputing that.

            If you want the power and freedom of lower level languages it comes with a bigger price: responsibility. C, like UNIX, assumes one thing only: that _you_ know what you're doing.

            At the end of the day mistakes will be made in both environments - but in C it's more likely those mistakes could cause security issues.

            Yes, it's a matter of picking the right tool for the job. For UNIX development (as in: the kernel and all base OS tools) I still believe that tool is C. Others may disagree, but that's their choice.

            I also don't see much point in discussing what tools a project like OpenBSD should use. What right does anybody who (like me) does commit code to OpenBSD CVS have to make that call? None. (To all) Put your code on the line and prove what you're saying about security et al. and maybe, just maybe, someone will listen.

            At the end of the day it's a case of 'the right tool for the job', and 'a bad workman blames his tools'. It's not my call to make, but I'd rather learn from my mistakes and continue to use C than switch to a higher level language that is less suitable for OS development.

            But that's just my opinion...

  10. By Anonymous Coward () on


    http://www.gnu.org/directory/security/net/libsafe.html

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]