OpenBSD Journal

Purging of dangerous string functions

Contributed by jose on from the string-function-inquisition dept.

tony was one of a few to write:
"The OpenBSD team is currently purging the source of as many instances of dangerous string functions (strcpy, strcat, sprintf, etc) where they can. They will be replacing them with the the bounds-checking family of these functions (strlcat, strlcpy, snprintf, and asprintf) "where applicable."

Theo has asked everyone to help test the new code out when 3.4-snapshots become available.

MARCs archive of the email is here: Theo's Message "

The diffs between these files will be an excellent illustrative tool of how to migrate from functions that don't do bounds checking to ones that do. This is highly suggested reading for people that are interested in learning how to do this (because it's not always as simple as strcat() -> strlcat()).

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    3.4-snapshot? that's jumping the gun a bit. Those will be 3.3-current snapshots. 3.4 (if it's even called that) won't be in snapshot form for ~6 months when 3.4-beta is available, but, it could be 4.0 for all we know :)

    Comments

    1. By tony () tony@libpcap.net on http://libpcap.net

      Meh, you knew what I meant. ;)

      I was thinking pre 3.4 not post 3.3 which got me all clusterfscked. I meant 3.4 snapshots as in the releases before 3.4 for some reason. Ah well.

    2. By Frollochy () on

      Not exactly. Snapshots are just precompiled -current builds that they put together once in awhile and send out a call to testers. They can come as soon as a few days after -stable is released.
      Beta's are what come out and I believe they are essentially snapshots of -current that are created every so often after the code has been suspended for new features and they are bugtesting in preparation for the release.

      Comments

      1. By jolan () on

        No.

        3.3-beta
        3.3
        3.3-current <-- we're here now
        3.4-beta
        3.4 <-- in ~6 months
        3.4-current

  2. By Anonymous Coward () on

    It is official; Netcraft confirms:

    str(cat|cpy) is dying. One more crippling bombshell hit the already beleaguered str* community when IDC confirmed that str market share has dropped yet again, now down to less than a fraction of 1 percent of all function calls...you get the idea :)

    Comments

    1. By Anonymous Coward () on

      LOL

    2. By Anonymous Coward () on

      made me laugh my ass off :)

  3. By Anonymous Coward () on

    That's strange. I thought that those functions were purged at the time when Todd added strl{cpy,cat} into the OpenBSD source (back when Todd and Theo published their USENIX paper). Guess I was wrong.

    Comments

    1. By Miod Vallat () miod@openbsd.org on mailto:miod@openbsd.org

      No, no, you are confusing with microbsd, who removed all calls to unsafe string functions ten years ago!

      (sorry... could not resist)

      Comments

      1. By Anonymous Coward () on

        Narf!

  4. By Anonymous Coward () on

    i think gcc optimizes these functions too

    Comments
    1. Comments

      1. By Anonymous Coward () on

        And replaced with?

        Comments

        1. By Anonymous Coward () on

          just scared off

        2. By Anonymous Coward () on

          OpenWatcom? (www.openwatcom.org)

        3. By Anonymous Coward () on

          http://www.cs.bell-labs.com/sys/doc/comp.html once the license is sane.

        4. By awk fu () on

          fortran!

        5. By Anonymous Coward () on

          Intercal

    2. By Anonymous Coward () on

      In what sense? Strl* are definitely -not- in glibc, do you mean that gcc performs optimizations on the strl* functions during compile time then?

  5. By Anonymous Coward () on

    I've never investigated the use of strlcat, strlcpy, etc myself, but is there any chance that replacing the old ANSI string invocations throughout the tree with strl* might introduce some new security flaws, even buffer overflows? Yes or absolutely not?

    Comments

    1. By tedu () on

      if the bounds check is incorrect, using strlcpy won't help. but that's no worse off than no bounds check at all.

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

      Yep, there's a chance.

      However, this purge is done very carefully, and the code is replaced with clearer code. Those safe functions are just simpler to write code correctly for.

    3. By Anonymous Coward () on

      In addition to what Marc Espie said there's some gcc instrumentation being done that should catch most stupid errors using those functions.

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