improved C1X security

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 <rcs@sei.cmu.edu> 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

Robert Seacord <rcs@sei.cmu.edu> 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) kst-u@mib.org <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"

On Aug 11, 10:22 pm, Robert Seacord <r...@sei.cmu.edu> 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>

>clearenv() - important, platform-dependent capability that shouldn't be >left to each individual programmer Assuming this is meant to clear the environment, of what use is this to a C program that _doesn't_ have a way of setting environment variables? (setenv() and putenv() are not present in standard C). Also, what side effects is this allowed to have? For example, is it allowed to change the time zone used by localtime() so gmtime() and localtime() behave the same? How about side effects on the locale? Standard C *permits* environment variables to affect these things, but it doesn't guarantee it. >encode_pointer(), decode_pointer() - useful in eliminating attack vectors Doesn't this require a whole bunch of public key and certificate infrastructure to actually USE? (and if it doesn't, it should).

On 11 Aug 2008 at 21:30, vippstar@gmail.com wrote: > On Aug 11, 10:22 pm, Robert Seacord <r...@sei.cmu.edu> 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?

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.

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/confluence/display/seccode/MSC16-C.+Consider+encrypting+function+pointers rCs

Robert Seacord said: > 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/confluence/display/seccode/MSC16-C.+Consider+encrypting+function+pointers Not so long ago I started reviewing the "CERT C" stuff in painstaking detail, posting the results here (and on my site), but I got so little feedback from the authors that I stopped bothering. In general, I was disappointed with the "CERT C" document, and I don't know of any reason why anything should suddenly have changed for the better. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ Google users: <http://www.cpax.org.uk/prg/writings/googly.php> "Usenet is a strange place" - dmr 29 July 1999

Robert Seacord <rcs@sei.cmu.edu> wrote: > 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/confluence/display/seccode/MSC16-C.+Consider+encrypting+function+pointers The result of DecodePointer isn't cast to the proper function pointer. I think that causes standards issues, at least as regards values the function might return. It's a real problem if the function returns a non-int type, in which case you'd have to cast the result of DecodePointer. But casting is error prone, because you circumvent the compiler. This is likely to lead to more trouble than it's worth (if its worth anything at all). Also, on all the modern environments I use, including Windows, function addresses are randomized at process instantiation, so this interface is entirely superfluous. Granted, this doesn't apply to many other environments, but that's beside the point. US-CERT's Secure Coding guidelines are beginning to get out of hand. This "guideline" borders on making the C language uncompliant w/ the C language guidelines. Way to cover your bases. Horrible, horrible idea.

William Ahern wrote: > Robert Seacord <rcs@sei.cmu.edu> wrote: >> [...] >> https://www.securecoding.cert.org/confluence/display/seccode/MSC16-C.+Consider+encrypting+function+pointers > > The result of DecodePointer isn't cast to the proper function pointer. I > think that causes standards issues, at least as regards values the function > might return. It's a real problem if the function returns a non-int type, in > which case you'd have to cast the result of DecodePointer. But casting is > error prone, because you circumvent the compiler. This is likely to lead to > more trouble than it's worth (if its worth anything at all). > > Also, on all the modern environments I use, including Windows, function > addresses are randomized at process instantiation, so this interface is > entirely superfluous. Granted, this doesn't apply to many other > environments, but that's beside the point. > > US-CERT's Secure Coding guidelines are beginning to get out of hand. This > "guideline" borders on making the C language uncompliant w/ the C language > guidelines. Way to cover your bases. > > Horrible, horrible idea. It might not merit a two-horrible rating; one or one-and-a-quarter are probably enough. But kidding aside, I'm impressed by one of the links on the descriptive page: It offers to let you "Search for vulnerabilities resulting from the violation of this rule on the CERT website." Performing the search turns up ... nothing. So does the proposed encoding and decoding address a real problem, or just an imagined problem? Are we being proactive and forward-looking in heading off trouble before it arises, or are we checking under the bed for bogeymen? -- Eric.Sosman@sun.com

Robert Seacord <rcs@sei.cmu.edu> 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