Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > improved C1X security

Reply
Thread Tools

improved C1X security

 
 
Robert Seacord
Guest
Posts: n/a
 
      08-11-2008

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
 
Reply With Quote
 
 
 
 
Ben Pfaff
Guest
Posts: n/a
 
      08-11-2008
Robert Seacord <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      08-11-2008
Robert Seacord <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      08-11-2008
On Aug 11, 10:22 pm, Robert Seacord <(E-Mail Removed)> 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>

 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      08-11-2008
On 11 Aug 2008 at 21:30, (E-Mail Removed) wrote:
> On Aug 11, 10:22 pm, Robert Seacord <(E-Mail Removed)> 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?

 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      08-11-2008
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.

 
Reply With Quote
 
Robert Seacord
Guest
Posts: n/a
 
      08-12-2008
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/co...ction+pointers

rCs
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      08-15-2008
Robert Seacord <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
New C1X Draft lawrence.jones@siemens.com C Programming 3 02-25-2011 03:09 AM
posting history -- wording of C1X sequencing Ersek, Laszlo C Programming 1 09-24-2010 12:43 AM
On alignment (final committee draft for C++0x and n1425 for C1X) Gennaro Prota C++ 2 08-25-2010 11:43 PM
On alignment (final committee draft for C++0x and n1425 for C1X) Gennaro Prota C++ 6 08-25-2010 04:37 PM
Who knows more information about the next ISO C standard "C1x" ? Royt C Programming 2 03-16-2008 01:05 PM



Advertisments