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]

bazad wrote:

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.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[E. Robert Tisdale]

bazad wrote:

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]

"bazad" <no****@noreply .not> wrote in message
news:1097780068 .uMbmVua0IQ4XTi xLRe9hpg@terane ws...

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...102&tid=190&ti
d=130&tid=6

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

HTH

[William Ahern]

bazad <no****@noreply .not> wrote:

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.progr ammer is probably a better bet.

[Mark F. Haigh]

bazad wrote:

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/securityre...OP0B006UQ.html

However, note that discussions of the information in that article are
off topic here.
Mark F. Haigh
mf*****@sbcglob al.net

[CBFalconer]

William Ahern wrote:

.... 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.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Keith Thompson]

jo*******@my-deja.com (John Bode) writes:
[...]

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.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mike Wahler]

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

jo*******@my-deja.com (John Bode) writes:
[...]

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]

CBFalconer <cb********@yah oo.com> wrote:

William Ahern wrote:

... 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.

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).