OpenBSD Journal

OpenBSD source code security

Contributed by jose on from the in-print-only dept.

As seen on the OpenBSD press page , a recent review of Windows, OpenBSD and Linux source code using simple static analysis tools reveals OpenBSD's source audit mechanisms to be working well. The article appears in this month's iX magazine (from Germany) and is entitled "Apparently insecure, analysis of Windows 2000, Linux and OpenBSD sourcecode". As stated on the OpenBSD press page: A small article describing the results of examining Windows 2000, Linux and OpenBSD source code using Flawfinder. "OpenBSD is ahead, Flawfinder finds a surprisingly small number of potentially dangerous constructs. The source code audit by the OpenBSD team seems to pay out. Additionally, OpenBSD uses the secure strlcpy/strlcat by Todd C. Miller instead of strcpy etc." Looks like someone may have made use of the recent Microsoft Windows source code leak .

(Comments are closed)

Comments

  1. By Sacha () on

    Does anybody have the results lying around somewhere of this analysis..?

  2. By Chad Loder () on

    Automated tools don't mean bunk. They're useful for casting a wide net for bugs, but I don't believe that interpreting the tool's results statistically across different code bases is going to tell you anything.

    Comments

    1. By ak () ak@synflood.at on http://synflood.at/blog/

      At least they show whether somebody has made his homework and removed all the obvious constructions that are potentially dangerous from his code. And this does show one thing very clearly, namely whether the code author is actively and honestly interested in secure code.

    2. By kris () on

      correct, but finding small possible bugs can lead to larger bugs. this just shows that openbsd audits there code regularly.

      Comments

      1. By Chris Laverdure () on

        No, no...

        OpenBSD won this by chance, all coincidence!

        [/sarcasm]

        Comments

        1. By kris () on

          exactly! just how Linux won the 'most stable servers ever' contest!

    3. By veins () chehad_g@epitech.net on http://etud.epita.fr/~chehad_g/

      yup
      that's exactly what i was going to write.
      flawfinder only checks if a function is called and not in what context it was called. using strcpy() does not make a program insecure if used properly but flawfinder will report it as a potential vulnerability.

      Comments

      1. By Damien () on

        Yes but the use of strlc{cpy,cat} is removing the doubt about vulnerability.

        For example i know that pkg-config use strcpy() without checking the values. If i don't have the time to check the context my only choice would be to take an alternative that use strl*() functions.

        Comments

        1. By veins () chehad_g@epitech.net on http://etud.epita.fr/~chehad_g/

          "Yes but the use of strlc{cpy,cat} is removing the doubt about vulnerability. "

          I dont agree, it is as easy to use strl{cat,cpy} unsafely as to use str{cpy,cat}, these functions does not make the code secure because they are called.

          it is just that people who use them are usually aware of security concerns and write code with care.

          Comments

          1. By Anonymous Coward () on

            You're able to perform an overflow by using strl*() function ??
            Please show me the code.

            Comments

            1. By krh () on

              Those aren't the problem. But if your suid root application writes to the directory $VARIABLE, and $VARIABLE just *happens* to expand to something very very large, which just *happens* to get cut off at, say, /var/named/named.conf, then you're in trouble.

              Comments

              1. By Damien () on

                Come on, we speak about safe functiond and you talk about programming error.
                If you set your buffer size with an incorrect value, you can't blame strl*() functions for that. A good coder will use the system max lenght to size the buffer (for example MAXPATHLEN or PATH_MAX).

                The str*() functions are unsafe because if the string is greater than the buffer it overflow on something else.
                The strn*() functions are a bit better because they ensure that the result will fit in the buffer but it doesn't null terminate the string. So you can get a non terminated string as a result which is not safer too.
                The strl*() functions make your string fitting in your buffer and null terminate it whatever the size of your string. This is safe.

                The conclusion is that when i have two programs, one written with str*() and the other written with strl*(), i will assume that the second is safer than the first.
                Yes, you can tell me that the second could be full of holes even if using strl*(). I'll answer you that this is the second stage of the analysis of the program.

                But the more important is the following question: did you look at the code of the programs you use ?

                I take again the example of pkg-config which is widely used, do you trust the following code:

                if (name)
                con->appName = strcpy(malloc(strlen(name) + 1), name);

                I hope you're not. But it think you must have this installed somewhere on your computer(s) ...

                Comments

                1. By krh () on

                  > Come on, we speak about safe functiond and you talk about programming error.

                  We speak about secure programming. I stand by my statement.

                  Comments

                  1. By Damien () on

                    But you statement has nothing to do with buffer overflow ...

                    Also secure programming means avoiding the use of suid root.

            2. By veins () chehad_g@epitech.net on http://etud.epita.fr/~chehad_g/

              no,
              what i meant was that strl* could be used unsafely due to a programming error, just as str* could be used safely after appropriate checks. flawfinder could say a code is insecure even if str* was used safely and could say a code is secure even if strl* were used unsafely, relying on that for an audit is not sufficient. but surely, it gives a global idea on how secure the code is, as people using strl* are more likely to be informed about security issues related to improper bounds check.

    4. By double-p () pb@ on mailto:pb@

      hi chad,

      sure..

      sidenote: the author of said article *explicitly*
      states, that this is a somewhat flawed analysis
      and needs additional research of the found "bugs".

      Tho I am baffeled, where that 1 strncpy is hidden :) ..

      ciao

      Comments

      1. By Anonymous Coward () on

        "grep strncpy -R * 2>/dev/null" in /usr/src/sys
        reports things all over the place,
        wc -l says 216 in all.

        there's a bunch more in /usr/src as a whole
        but i don't hold the obsd team responsible for
        all of those (e.g. the crapload in gcc's src)

        Comments

        1. By Ben () mouring@eviladmin.org on mailto:mouring@eviladmin.org

          There are times when strncpy() is valid. You do have the structures that are not null terminated, but are length terminated.

          strcpy() are far worse.

  3. By Anonymous Hero () on

    http://valgrind.kde.org

    It doesn't run on Your os. Perhaps you can port it or use a Real development os? If you felt offended because of the latter comment, you are emotionaly attached to your os. Use the best os for the best job!

    Comments

    1. By krh () on

      Please don't troll here. It's not very polite, and it makes you (and by extension, Linux, KDE, and Valgrind) look bad.

    2. By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org

      Nice troll.

      You probably don't know it, but we have other tools that other unices don't have. Some of the stuff in our malloc, for instance. Or generalized propolice. Or W^X...

      Yep, valgrind would be nice too. Why don't you port it instead of trolling ?

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.]