Slashdot Mirror


Fix the Bugs, Secure the System

LiquidPC writes: "OpenBSD's Louis Bertrand has put his MUSESS 2002 presentation online, entitled Fix the Bugs, Secure the System. Does an overview of OpenBSD, then explains Format String Ugliness, Buffer Overflows, The Wrong Way to Fix Overflows, along with numerous other things."

4 of 334 comments (clear)

  1. Secure programming by Kiwi · · Score: 4, Informative
    One of the most common security problems is buffer overflows; the way I worked around this was to write a special string library where the strings had meta data; including the maxiumum length a given string could have.

    One of the problems with secure programming is the inertia in the computer industry; most of the operating systems in widespread use today (The *nix clones and DOS derivitives, these days) we developed in a time when security did not matter; *nix has a crude root-or-not security model and MS-DOS has no conception of security at all.

    Personally, I think the solution is a model which has a real security model, such as EROS. The "audit the code so that it is perfect code without bugs" approach to security does not always work, even with OpenBSD.

    - Sam

    --

    The secret to enjoying Slashdot is to realize that it should not be taken too seriously.

  2. Secure programming HOWTO for Linux and UNIX by SteelX · · Score: 5, Informative

    While we're on this topic, this Secure Programming HOWTO for Linux and UNIX might be of interest. It's a pretty comprehensive book. And best of all, it's free! :-)

    1. Re:Secure programming HOWTO for Linux and UNIX by dwheeler · · Score: 5, Informative
      Thanks for the plug! My book, Secure Programming for Linux and Unix HOWTO, is free, and it's open source/free software (GNU FDL).

      I've also just posted my presentation on how to write secure programs; it's the presentation I gave at FOSDEM 2002 last week. Note that these presentations have different (overlapping) goals; Louis Bertrand's presentation is primarily about OpenBSD (e.g., how it's developed), while my presentation is primarily about how developers can develop secure programs. My presentation, like the book, is at http://www.dwheeler.com/secure-programs.

      --
      - David A. Wheeler (see my Secure Programming HOWTO)
  3. Re:Why not just mark the stack non-executable? by YU+Nicks+NE+Way · · Score: 5, Informative

    Standard buffer overflow exploits don't execute the stack. The most common form (so-called single instance exploits) alter the return point from a subroutine so that a particular command (also stored by the malicious code) gets executed. (E.g. in a Unix system, the attacker climbs around until he finds a call to exec, and branches to the exec with a call to /bin/sh in the right place on the stack.) The second most-common form consists of exploits that cause a function pointer to be replaced in a heap variable. Even if these exploits required the insertion of executable code -- and I don't know of any cases where they do -- a non-executable stack won't help against a heap attack.