Safer and Better C

[bazad]

Hi,

I am not using C all the time. I have a general understanding of C
and nothing else. The recent reply to use strlcpy and strlcat showed
me that I am not aware of the best and safe techniques. Is there any
place where I could learn more about safer and better C (on FreeBSD)?


Thank you

 

[CBFalconer]

I am not using C all the time. I have a general understanding of C
and nothing else. The recent reply to use strlcpy and strlcat showed
me that I am not aware of the best and safe techniques. Is there any
place where I could learn more about safer and better C (on FreeBSD)?

Do not start a new thread without a reason. This should have been
a reply to something in some other thread, with sufficient material
quoted and attributed for us to put things in context.

C is inherently unsafe. By monitoring this newsgroup you will now
and then find out about ways of appeasing the lurking tigers.
Beyond that you just have to be aware of what is going on.

 

[E. Robert Tisdale]

I am not using C all the time.
I have a general understanding of C and nothing else.
The recent reply to use strlcpy and strlcat showed me that
I am not aware of the best and safe techniques.
Is there any place
where I could learn more about safer and better C (on FreeBSD)?

Type

man strlcpy

or

man strlcat

at your FreeBSD prompt.

 

[Minti]

Hi,

I am not using C all the time. I have a general understanding of C
and nothing else. The recent reply to use strlcpy and strlcat showed
me that I am not aware of the best and safe techniques. Is there any
place where I could learn more about safer and better C (on FreeBSD)?


Thank you

Read this thread

http://books.slashdot.org/article.pl?sid=04/10/12/1811259&tid=102&tid=190&ti
d=130&tid=6

a couple of days back. Says that a complete chapter on secure C.

HTH

 

[William Ahern]

Hi,

I am not using C all the time. I have a general understanding of C
and nothing else. The recent reply to use strlcpy and strlcat showed
me that I am not aware of the best and safe techniques. Is there any
place where I could learn more about safer and better C (on FreeBSD)?

Read the FAQ--http://www.eskimo.com/~scs/C-faq/top.html--twice. You can't go
wrong there. You're likely better off using the existing interfaces properly
than looking for "safer" interfaces.

On a related note, Theo and Company of OpenBSD fame--arguably the ones who
most popularized the functions--will admit that strlcpy() and strlcat() are
_not_ the preferred solutions. memcpy() is even better, because the
occasions when you do not know the length of your source string should be
few and far between. strlcpy() and strlcat() should be a last resort. It's
also worth noting that the C99 semantics of snprintf() are very similar and
more widely available (FreeBSD's snprintf() is one such implementation, I
believe).

strlcpy() and strlcat() are fairly unique in that they're additions to
C--albeit platform specific extensions and not very portable--which play
fair with and generally fit in well amongst the wider body of C code. Using
fancy libraries can often create more problems than they solve, because they
don't fit well with the existing corpus of C source and the points of
contact require considerable attention to detail.

For more secure applications overall--like chroot() and privilege revocation
techniques--in FreeBSD, comp.unix.programmer is probably a better bet.

 

[Mark F. Haigh]

Hi,

I am not using C all the time. I have a general understanding of C
and nothing else. The recent reply to use strlcpy and strlcat showed
me that I am not aware of the best and safe techniques. Is there any
place where I could learn more about safer and better C (on FreeBSD)?


Thank you

The most common security problems are buffer overflows. Simply put,
this means writing more data into a buffer than there's space for.
You'd do yourself a favor by learning how some of these exploits work.
I know there's a couple of old Phrack articles around, as well as an
article over at SecuriTeam, entitled 'Writing Buffer Overflow Exploits -
a Tutorial for Beginners':

http://www.securiteam.com/securityreviews/5OP0B006UQ.html

However, note that discussions of the information in that article are
off topic here.


Mark F. Haigh
(e-mail address removed)

 

[CBFalconer]

.... snip ...

strlcpy() and strlcat() are fairly unique in that they're additions
to C--albeit platform specific extensions and not very portable--
which play fair with and generally fit in well amongst the wider
body of C code. Using fancy libraries can often create more
problems than they solve, because they don't fit well with the
existing corpus of C source and the points of contact require
considerable attention to detail.

Their implementation is NOT platform specific and totally portable,
and thus they can be used anywhere by supplying an implementation.
I have done so, written in purely standard C. See my page in sig.

 

[John Bode]

Hi,

I am not using C all the time. I have a general understanding of C
and nothing else. The recent reply to use strlcpy and strlcat showed
me that I am not aware of the best and safe techniques. Is there any
place where I could learn more about safer and better C (on FreeBSD)?


Thank you

I don't know of any specific resources, but here are some personal
guidelines in no particular order (note that I don't necessarily
follow these *all* the time, depending on the situation and how
deluded^H^H^H^H^H^H^Hconfident I am in my own abilities that day):

1. Initialize all variables to a known value.
2. Check all return values from library functions.
3. Don't use gets().
4. During development, set the warning level on the compiler to its
highest setting. Review and eliminate each warning.
5. Don't cast an expression *just* to eliminate a warning.
6. When comparing against a constant expression for equality, put the
constant on the LHS (i.e., if (SOME_CONSTANT == x)); this will catch
any problems where you typed "=" when you meant "==".
7. Abstract out tedious, repetitive, and/or low-level tasks. IOW,
don't call malloc() directly from your application code, but wrap it
in a function that performs error checking and initialization of the
memory being returned.

 

[Keith Thompson]

6. When comparing against a constant expression for equality, put the
constant on the LHS (i.e., if (SOME_CONSTANT == x)); this will catch
any problems where you typed "=" when you meant "==".

[...]

This one is controversial. Personally, I find the (5 == x) form
grating; I'd rather use (x == 5) and just make sure I get the operator
right. (This has been discussed to death here before.)

 

[Mike Wahler]

6. When comparing against a constant expression for equality, put the
constant on the LHS (i.e., if (SOME_CONSTANT == x)); this will catch
any problems where you typed "=" when you meant "==".

[...]

This one is controversial. Personally, I find the (5 == x) form
grating; I'd rather use (x == 5) and just make sure I get the operator
right. (This has been discussed to death here before.)

#define equals ==

if(x equals y)
;



-Mike

 

[William Ahern]

Their implementation is NOT platform specific and totally portable,
and thus they can be used anywhere by supplying an implementation.
I have done so, written in purely standard C. See my page in sig.

Ah, yes. That statement was poorly worded. I include OpenBSD's strlcpy() and
strlcat() code in many of my projects. I just meant that it's not available
on many platforms--e.g. Linux--and if you don't want to go through the
trouble of including it yourself snprintf() often suffices.

FWIW, the OpenBSD crowd writes very portable code (not fans of GCC'isms). I
keep a compat library around which I reuse for most of my development (I
especially like Niels Provos' sys/tree.h header for easy-peasy splay and
red-black trees).

 

[CBFalconer]

.... snip ...

1. Initialize all variables to a known value.
2. Check all return values from library functions.
3. Don't use gets().
4. During development, set the warning level on the compiler to
its highest setting. Review and eliminate each warning.
5. Don't cast an expression *just* to eliminate a warning.
6. When comparing against a constant expression for equality, put
the constant on the LHS (i.e., if (SOME_CONSTANT == x)); this
will catch any problems where you typed "=" when you meant "==".
7. Abstract out tedious, repetitive, and/or low-level tasks. IOW,
don't call malloc() directly from your application code, but
wrap it in a function that performs error checking and
initialization of the memory being returned.

I agree with all except #1, which can mask a failure to suitably
initialize later.

 

[Kenny McCormack]

6. When comparing against a constant expression for equality, put the
constant on the LHS (i.e., if (SOME_CONSTANT == x)); this will catch
any problems where you typed "=" when you meant "==".

[...]

This one is controversial. Personally, I find the (5 == x) form
grating; I'd rather use (x == 5) and just make sure I get the operator
right. (This has been discussed to death here before.)

#define equals ==

if(x equals y)
;

Heh.

But don't most compilers catch (warn about) this anyway, these days?

That is, they want you to change:

if (x = 5)
to:
if ((x = 5))

 

[Guillaume]

But don't most compilers catch (warn about) this anyway, these days?

That is, they want you to change:

if (x = 5)
to:
if ((x = 5))

What will the compiler catch if you have a multiple test, like:

if ((x = 5) && (y == 6))

 

[Keith Thompson]

What will the compiler catch if you have a multiple test, like:

if ((x = 5) && (y == 6))

gcc doesn't.

 

[Kelsey Bjarnason]

gcc doesn't.

int main()
{
int x = 3, y = 4;

if ( y = x )
;

return 0;
}

gcc -Wall test.c
test.c: In function `main':
test.c:5: warning: suggest parentheses around assignment used as truth
value


Apparently, it does. Just not with the default warning levels... but
you'd never fail to use at least -Wall during development, would you?

 

[Arthur J. O'Dwyer]

gcc doesn't.

[...]
Apparently, it does.

Try again, this time with the line Guillaume asked about. Keith's
absolutely right.

On the other hand, gcc /will/ warn you if you leave off the redundant
parentheses in Guillaume's example. Which some people might see as an
advantage to leaving them off (my preferred style in many cases as it
reduces clutter), but really I don't consider "mistyping == as = or
vice versa" to be a statistically significant problem in the first place.

-Arthur

 

[Jonathan Adams]

int main()
{
int x = 3, y = 4;

if ( y = x )
;

return 0;
}

gcc -Wall test.c
test.c: In function `main':
test.c:5: warning: suggest parentheses around assignment used as truth
value

I believe they were referring to the latter construction:

if ((x = 5) && (y == 6))

which is not caught (at least not with -Wall on gcc 3.4.2).

Cheers,
- jonathan

 

[Ben Pfaff]

if ( y = x )
;

Are you paying attention?

 

[Keith Thompson]

Guillaume <"grsNOSPAM at NOTTHATmail dot com"> writes:

What will the compiler catch if you have a multiple test, like:

if ((x = 5) && (y == 6))

gcc doesn't.

[...]
Apparently, it does.

Try again, this time with the line Guillaume asked about. Keith's
absolutely right.

On the other hand, gcc /will/ warn you if you leave off the
redundant parentheses in Guillaume's example. Which some people
might see as an advantage to leaving them off (my preferred style in
many cases as it reduces clutter), but really I don't consider
"mistyping == as = or vice versa" to be a statistically significant
problem in the first place.

The parentheses aren't redundant (if that's really supposed to be "="
rather than "=="). If you leave them out:

if (x = 5 && y == 6)

is equivalent to

if (x = (5 && y == 6))

Of course if you correctly use "==" rather than "=", they are redundant:

if (x == 5 && y == 6)