header pictures for dedicated hosting services header image of world
Guests Visit the FreeBSD Forums  •  Login to the FreeBSD Forums  •  Register for FREE

String cleanup results on OpenBSD


Registered: Jan 2002
Posts: 2,711

String cleanup results on OpenBSD

OpenBSD's Theo De Raadt provides an update on his team's efforts to remove potential buffer overflows by always calculating what the bounds of an operation are.

[Read email update]

To: misc@cvs.openbsd.org
Subject: string cleanup results
From: Theo de Raadt <deraadt@cvs.openbsd.org>
Date: Sat, 19 Apr 2003 13:54:53 -0600

Some of you might have noticed that we have been doing a 'string
cleaning'. (I should probably apologize for this northern-hemisphere
specific pun).

That means that we have been going through the tree cleaning out all
calls to sprintf(), strcpy(), and strcat(). Instead, these things are
being rewritten to use asprintf(), snprintf(), strlcpy(), and

As a result, I can tell you that we have removed at approximately 2000
occurances of these functions. I cannot provide exact figures since
that would require hand-counting the actual diffs from 8 weeks ago ;)
Source code grep'ing is not always accurate.

The goal is to remove potential overflows, by always calculating what
the bounds of an operation are. In doing so, some code is now
converted from an overflow to a truncation. In followup work, we wish
to continue investigating all cases of truncation in the tree, and see
what we can do better in those cases where truncation is undesirable.
Sometimes you want to handle it, sometimes it is ok, sometimes it is
really nasty. Obviously, that's an even bigger job than what we have
done here, since the tree was already full of truncations. Current
theory held by most is that most of these are innocious, but who
knows.. I want us to clean them (but I do not want us to go insane

Obviously there is the possibility that this huge effort has
introduced a minor bug here or there, but it much more likely that we
have squished many much more major bugs.

I would estimate that more than 20 developers have been involved in
this process which we started in earnest about 6 weeks ago.

We are obviously not doing this to some parts of the tree which we
borrow from other projects. In particular, the gnu part of the tree
might remain largely dirty. However, we have done this in httpd and
openssl, and will maintain those tree components ourself if need be.
We have also convinced the bind people to move in this direction, and
they have incorporated these functions into bind -- that work is not
finished however. Since sendmail already has renamed versions of
strlcpy and strlcat, we have tried convincing them to move completely
in this direction as well, and I think that they are doing that work

Of the programs that are in our base set, and under consideration, we
have a few that still call these functions:

routed, dump, restore, awk, indent, lam,
make, xlint, bind, openssl, ppp, rtadvd

Pretty small list eh.

There might be a few more, but I am sure you can comprehend the
direction. Of course, we have completely purified our libraries of
these functions as well, except that libc still provides them (in
accordance with standards and... well, expected behaviour).

The remaining ones are very difficult. afs, gcc, binutils, etc.

I must also say that in the last week we've fixed some that are
incredibly difficult. Some of them were definate buffer overflows.
Sometimes we hit a piece of code in a program that just about made
us cry. A few changes involved 10 or more people before we settled
on a correct change. Crazy stuff.

In a week or so there will also be changes made to ensure that the
kernel is completely clear of these functions too, but we are waiting
for the i386 ELF W^X work to settle into the tree.


04-21-2003, 08:33 AM

Join Date: 2002
Posts: 1,485


this is very nice. openbsd's focus has always been fixing the most fundamental bugs before they become exploits.
Go and tell the king that the sky is falling in when it's not (maybe not).

chat.taucher.net, #bsd



04-21-2003, 10:24 AM
Port Monkey

Join Date: Jul 2002
Location: Lennox,
SD -- its pronounced
"LEE-NUKS" >:-)
Posts: 397

...the real question I have is how many buffer k1dz are out there checking out the CVS tree and diffing against previous versions trying to find the "definate buffer overflows" Theo mentions! That's frightening, because I'm sure some of those buffers are in code that is in use lesewhere too!

...I absolutely admire these efforts. I just wish everyone would make similar efforts!
04-21-2003, 10:39 AM
Port Monkey

Join Date: Feb 2003
Posts: 349

not hard to find in other programs, just cat *.c | grep strcpy and check out what's going on, if it's ever possible to remotly overflow a buffer. I "helped" a little bit with this conversion proecess, mainly in that i pointed out some stc* functions, tried to fix them, but my fixes diff's didnt work, so 2 or 3 other people gave it a shot and the changes finally went into the tree.

A simple example to see the difference between safe uses of str* functions verses strl or strn functions would be to look at x-chat's source. The only potentiall unsafe instance i saw in x-chats source is in the dcc source where the file name is copied into a buffer without checking it's bounds. The problem with exploiting that is that UNIX places limitations to how long a filename can be. So if you can fake the filename of a file that you send to someone on x-chat you could possible remotly crash it.

But hey, whado I know, i'm still a C newbie.
04-21-2003, 01:33 PM


Looking for our FreeBSD Forums? We have moved them off our main page,just follow the link to our FreeBSD Forums page.


Privacy Policy

Please note:
(1) FreeBSD is a registered trademark of The FreeBSD Foundation.
(2) WEBSERVER CONSUMER GUIDE is in no way affiliated with The FreeBSD Foundation