improved C1X security

Discussion in 'C Programming' started by Robert Seacord, Aug 11, 2008.

  1. What functions, if added to the C1X standard, would make the C language
    more secure and why?

    Here are a couple of my suggestions:

    sigaction() - only secure way to set signal persistence
    clearenv() - important, platform-dependent capability that shouldn't be
    left to each individual programmer
    mkstemp() - allows a secure directory to be specified. this feature is
    lacking from both C99 and TR 24731
    encode_pointer(), decode_pointer() - useful in eliminating attack vectors

    Feel free to pick on mine or suggest other functions. Suggesting others
    is probably more productive. 8^)

    rCs
     
    Robert Seacord, Aug 11, 2008
    #1
    1. Advertising

  2. Robert Seacord

    Ben Pfaff Guest

    Robert Seacord <> writes:

    > What functions, if added to the C1X standard, would make the C
    > language more secure and why?
    >
    > Here are a couple of my suggestions:
    >
    > sigaction() - only secure way to set signal persistence


    C89 and C99 have so little support for signals that I am not sure
    that "signal persistence" is relevant to its environment.

    POSIX/SUS is the spec that really makes signals useful, so to me
    it makes sense that that spec also adds sigaction().

    > clearenv() - important, platform-dependent capability that shouldn't
    > be left to each individual programmer


    Can't see a problem with it, if it is sufficiently useful.

    > mkstemp() - allows a secure directory to be specified. this feature
    > is lacking from both C99 and TR 24731


    mkstemp() returns a file descriptor, which C89 and C99 don't
    have. They would need a different function that returns a FILE *
    instead.

    > encode_pointer(), decode_pointer() - useful in eliminating attack vectors


    Not sure why this would need to be defined by the system library.
    Surely you could implement it yourself in terms of bytewise
    operations on "void *"s or integer operations on uintptr_t?
    --
    Ben Pfaff
    http://benpfaff.org
     
    Ben Pfaff, Aug 11, 2008
    #2
    1. Advertising

  3. Robert Seacord <> writes:
    > What functions, if added to the C1X standard, would make the C language
    > more secure and why?
    >
    > Here are a couple of my suggestions:


    [...]

    > clearenv() - important, platform-dependent capability that shouldn't be
    > left to each individual programmer


    According to the man page on a system that has a function by this
    name, clearenv() clears all environment variables, so that getenv()
    will always NULL for any valid argument.

    This function is designed for use in a particular kind of environment,
    one in which environment variables are part of the context in which a
    process executes, and are inherited only by child processes. Other
    systems can have different models for environment variables, ones that
    are consistent what little the current C standard says about them.

    For example, a program might have permission to modify some
    environment variables but not others, or modifying environment
    variables might affect other entities (processes?) in the system, or
    certain environment variable settings might be necessary for correct
    operation.

    I think having this in POSIX would be sufficient.

    [...]

    > encode_pointer(), decode_pointer() - useful in eliminating attack vectors


    Can you explain just what these are supposed to do?

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 11, 2008
    #3
  4. Robert Seacord

    Guest

    On Aug 11, 10:22 pm, Robert Seacord <> wrote:
    > What functions, if added to the C1X standard, would make the C language
    > more secure and why?


    Off-topic in comp.lang.c (but subtly)
    Here, we discuss current standards of C. comp.std.c would be most
    appropriate for suggestions for future standards.

    <snip>
     
    , Aug 11, 2008
    #4
  5. On 11 Aug 2008 at 21:30, wrote:
    > On Aug 11, 10:22 pm, Robert Seacord <> wrote:
    >> What functions, if added to the C1X standard, would make the C language
    >> more secure and why?

    >
    > Off-topic in comp.lang.c (but subtly)


    Great.

    So the security flaws in C are "off topic"?

    So the next C standard is "off topic"?

    Just where do you people get off?
     
    Antoninus Twink, Aug 11, 2008
    #5
  6. On 11 Aug 2008 at 21:42, pete wrote:
    > Antoninus Twink wrote:
    >> So the next C standard is "off topic"?

    >
    > The next C standard, is on topic at comp.std.c


    I don't deny it.

    My point was that it's also on topic here, along with all other aspects
    of C programming.
     
    Antoninus Twink, Aug 11, 2008
    #6
  7. Keith,

    Response below:

    >
    >> encode_pointer(), decode_pointer() - useful in eliminating attack vectors

    >
    > Can you explain just what these are supposed to do?


    There will be a paper on these functions in the WG14 mailing, which
    should be out any moment now.

    I wasn't planning on proposing these (as they were already being
    proposed). I listed them as an example of what I was talking about.

    We have a short write up on these functions in The CERT C Secure Coding
    Standard here if you want to read more now:

    https://www.securecoding.cert.org/c...SC16-C. Consider encrypting function pointers

    rCs
     
    Robert Seacord, Aug 12, 2008
    #7
  8. Robert Seacord

    Richard Bos Guest

    Robert Seacord <> wrote:

    > What functions, if added to the C1X standard, would make the C language
    > more secure and why?
    >
    > Here are a couple of my suggestions:
    >
    > sigaction() - only secure way to set signal persistence
    > clearenv() - important, platform-dependent capability that shouldn't be
    > left to each individual programmer
    > mkstemp() - allows a secure directory to be specified. this feature is
    > lacking from both C99 and TR 24731
    > encode_pointer(), decode_pointer() - useful in eliminating attack vectors


    I'd like to know how any of this would have an influence on the current
    (and presumably continuing) contents of the C Standard. For example,
    what good does mkstemp() do me if I don't have chdir() as well? Why
    would I use encode_pointer()?

    Richard
     
    Richard Bos, Aug 15, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Royt
    Replies:
    2
    Views:
    773
    llothar
    Mar 16, 2008
  2. Gennaro Prota
    Replies:
    6
    Views:
    659
    Larry Evans
    Aug 25, 2010
  3. Gennaro Prota
    Replies:
    2
    Views:
    351
    Francesco S. Carta
    Aug 26, 2010
  4. Ersek, Laszlo

    posting history -- wording of C1X sequencing

    Ersek, Laszlo, Sep 23, 2010, in forum: C Programming
    Replies:
    1
    Views:
    304
    Shao Miller
    Sep 24, 2010
  5. New C1X Draft

    , Feb 24, 2011, in forum: C Programming
    Replies:
    3
    Views:
    666
Loading...

Share This Page