Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

More secure software

By cras in Technology
Sun Feb 04, 2001 at 10:51:24 AM EST
Tags: Security (all tags)

A lot of the current software is full of security holes. The same old software appears all the time in news having yet another problem from yet another audit when you thought from the number of publicity and audits for it it couldn't possibly have a single hole more. And once in a while pops up a hole from some fundamental software you thought had all its security holes found years ago.

Could anything be done to stop this? I can think of a couple of things that could help some.

I'm offering money for finding security holes from my pet project, irssi. I know D. J. Bernstein does the same for qmail and djbdns. And TeX's author for any bug, but that's a bit too much for me :) These four projects are the only software I know of offering money for finding bugs. And just three different people.. I can't really believe I'm only the third to do so?

Open-source developers often code for fun. I don't know about the rest of the people, but the fun part for me is to code the best software with the best source code (well, try to at least :). The money prize is there just for telling others that I really do believe my code is secure, and will be secure.

I'm sure if more projects gave away money for found security holes, the security of all software would be a lot better than it is now. Software not giving money and still having security holes would be taken over by software that is known to be secure from numerous code audits. And the higher the prize, the more I would trust the project.

To find the secure software, we would need a site listing the secure software. A well known site. If there's one already, it isn't well enough known since I've never heard of it. It's now hard to pick up new software from a huge list of choices when you hardly know anything of any of them. People will probably select the one that is the most well known, or maybe has the most features. If that list had also security related information (number of holes, date of last hole, prize for found holes) for each product, the choice might be different. Maybe Freshmeat could be modified for this?

And one last thing I want to rant about is the security sites listing the holes. It's kind of annoying to me that software that has security holes get mentioned everywhere gaining lots of publicity, even if slightly bad, while the software that has never had a single hole is never heard of anywhere. It would almost be worth it to deliberately plant a hole in one release and then shout about it everywhere after a few weeks.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Freshmeat
o irssi
o Also by cras

Display: Sort:
More secure software | 23 comments (19 topical, 4 editorial, 0 hidden)
You address the symptoms but not the cause. (4.22 / 9) (#3)
by Carnage4Life on Sun Feb 04, 2001 at 12:20:19 AM EST

The suggestions in your article all address the symptoms of badly designed software instead of the cause. The first and most important lesson I ever learned in my Software Engineering class is that You Cannot Test Quality Into Software. If a piece of software is poorly designed and broken, all the testing and bug fixing in the world will not change this and instead will lead to spaghetti code.

To put it simply, the main problem is that most programmers have never been taught how to write secure code. Most of use use insecure library functions like strcpy, strcat and scanf with disregard for how many security holes have been caused by these functions and others like them that assume that they will only be sent valid data.

The only solutions that will work are tackling the problem at its root. For instance, schools and programming textbooks need to start emphasizing writing secure code more and more including reasons for why some functions should never be used. Also switching from using "portable assembly language", C , for writing complex end user applications and using safer languages like Java is also a good way to stop most security holes in software.

Fixing symptoms is all we can do now (2.00 / 1) (#9)
by cras on Sun Feb 04, 2001 at 05:17:06 AM EST

No, the suggestions were trying to make the badly designed software disappear. Authors of badly designed software couldn't possibly keep the prize too high or at least for too long (unless they're rich enough to afford it of course). Authors of well designed software on the other hand probably trust their code more, and could give larger amounts of money for found security holes, and possibly would never have to pay it to anyone.

As for sites showing the number of security holes etc., it doesn't really make a difference if some software has had 7 holes and another one 15, but if one has had 7 holes and another 0 holes it's pretty clear which one is more secure (yes, assuming they're all mature software).

And there's a little to be done at the moment for the cause of the problems. Current coders won't change their coding behaviour until writing bad code becomes despised. C will still be the standard language for a long time, no other language is as portable and as powerful as it. But the current C coders that do create good secure code could already have their software clearly shown somewhere for the others.

[ Parent ]

strcpy, strcat and scanf (none / 0) (#22)
by UrLord on Tue Feb 06, 2001 at 10:09:06 PM EST

*Disclaimer: I am not a programmer*

I believe OpenBSD added more secure/easier functions to replace these. I remember seeing something about it in an interview with BSD developers.

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

All software is not Open Source. (3.66 / 3) (#4)
by babylago on Sun Feb 04, 2001 at 12:59:15 AM EST

I'm offering money for finding security holes from my pet project, irssi. I know D. J. Bernstein does the same for qmail and djbdns. And TeX's author for any bug, but that's a bit too much for me :) These four projects are the only software I know of offering money for finding bugs. And just three different people.. I can't really believe I'm only the third to do so?

Maybe in Open Source. Microsoft and Apple, to name two off the top of my head, routinely issue bonuses for bug-squishing to their employees, particularly as they approach release deadlines.

Does that make their software more secure?

[ Blog | Hunnh ]

There's quite a difference (none / 0) (#8)
by ajf on Sun Feb 04, 2001 at 04:00:59 AM EST

Offering bonuses for bug fixes is one thing, but the qmail and TeX offers are a case of their respective authors saying "this software is correct" - it doesn't make the software better, they're saying the problems don't exist.

"I have no idea if it is true or not, but given what you read on the Web, it seems to be a valid concern." -jjayson
[ Parent ]
A few tips (4.28 / 7) (#5)
by kcarnold on Sun Feb 04, 2001 at 01:10:24 AM EST

A thorough security audit on a piece of code is nothing short of a royal pain in the butt. There's a metric heckuvalot of stuff you need to remember and keep track of, and programmers are only human, last I checked. "Number of reported holes" is a crudely accurate measure of a program's security, but it's all we have for now. So here's a few tips for writing and maintaining secure code from one who violated them almost purposefully:

  1. Read the man pages for the functions you're using. strcat, strcpy, gets(!!!), scanf, and a bunch of other common library functions write to buffers. Buffer overflow is probably the most common security hole in any program. Make sure that you know exactly what the largest possible string the function could store in your buffer is and remember to add 1 for the trailing NULL. If this is a bother, use the STL string class of C++ or write your own (I'd go with the former), or use a language where buffers are a nonissue, like Java, LISP/Scheme/elisp, or shell script (the latter presents its own issues; it's generally not a good idea to run anything important or privilaged in shell because executing a command is too similar to passing it as an argument to something; a good number of Perl scripts are vulnerable to this as well).
  2. Never trust the user. Assume that the user is evil and malicious and out to kill your program and murder its firstborn child until proven otherwise. Paranoia is a good thing; the more sanity checks, the more likely you are to avert security holes, and it has the benefit of catching bugs easier also. Then you can go back and remove the paranoia (or #ifdef DEBUG it) when you have proven that the case you're checking for cannot possibly take place. Proving such with a language like C is difficult because of its close proximity to the buffer and memory. Scheme and other LISPs tend to be easier to prove because their constructs are very well-defined and program flow tends to be more easily dealt with (just prove that a function will always do the right thing given any inputs, and if you have avoided side-effects as much as possible, this is pretty much all the checking you need), but they are a lot more of a pain to deal with for real apps (though several major programs, including festival and sawfish, prove that it is quite possible). Java has a virtual machine that acts a lot like a generalized conventional processor, but the language itself hides much of the problems with that. It's still hard to prove things about because of the side-effects of almost any given bit of code. If proofs intimidate you, just leave the sanity checking in there; written correctly it doesn't slow things down all that much.
  3. Define, in plain English (or whatever your native language is), what each significant seciton of code does before you even start to write it. This is good programming practice in general, and prodcues easier-to-understand code. Just look at ogg123, the command-line Vorbis player. I don't do that very much, and look how much of a mess the code is. I'm working on it though... This affects security because you tend to define your inputs and outputs more clearly, and think through what your data is and what you're doing with it before you start working with it. If that data contains "malicious" code, keeping it boxed up is much easier if you define what it is and where it's supposed to be ahead of time.
  4. Avoid stupid mistakes. Like using the insecure (the man pages will tell you!) *tmp*(3) (mkstemp and tmpfile being exceptions here). Or *printf(user-supplied data, arguments) (the format-string overflow).

I have more, and so do other people, but I really have to go to sleep now. Later, dudes ;)

Netscape (2.50 / 4) (#6)
by delmoi on Sun Feb 04, 2001 at 03:40:15 AM EST

Netscape offers $1000 for any security flaw. and a free t-shirt
"'argumentation' is not a word, idiot." -- thelizman
What does the t-shirt say? (2.50 / 2) (#11)
by itsbruce on Sun Feb 04, 2001 at 06:39:05 AM EST

If it says "I write crap software!" or "Sneeze and I'll crash!" then I'm all for it.


It is impolite to tell a man who is carrying you on his shoulders that his head smells.
[ Parent ]
nsengineersareweenies (none / 0) (#14)
by camadas on Sun Feb 04, 2001 at 02:30:27 PM EST

or what was the string anyway .

[ Parent ]
Some ideas on security (4.33 / 3) (#12)
by slaytanic killer on Sun Feb 04, 2001 at 11:33:51 AM EST

On the subject of security, I think of an interview with Theo de Raadt where he says that security is a byproduct of quality. An almost accidental byproduct. The better quality the design, the better the security is. (There's a Slashdot interview which expands on this.)

In my own experience, security holes in software are usually guaranteed in early releases. People rush; at times people with better ideas than implementations code things with unfortunate holes. So we're looking at scenarios where people will have to fix things after release.

The main help for that is good design. Inputs should be separated from the internal logic, so you're not hunting around applying patches in strange places. Things ideally should be able to be ripped out and quickly replaced without bad consequences. And a good design makes it easier to create redesigns, if there was some unseen conceptual flaw.

Also, it would be nice if the API comments are decent. Often, someone other than the original author is going into the code to fix mistakes. That person should be able to trust her sense of code navigation. And on another upside, it may define more strictly what a module does, so modularity is enforced. Even before release, that lets people know where to put things; programmers might make strange hacks to get something working, because they did not know some module takes care of such problems cleanly. People are not so advanced that we can generally see the implications of code; most people still think best in human language, and so language will overall convey meaning better than code.

Addendum: Side effects (4.00 / 1) (#13)
by slaytanic killer on Sun Feb 04, 2001 at 02:12:43 PM EST

Functions can either just return some value and do nothing else, or they have side-effects. Side-effects are just some action a function takes, that isn't just about returning values. It might be as subtle as locking something temporarily, or as obvious as putting something to the screen. Make sure those side-effects are documented or obvious. The people who work with you will thank you.

[ Parent ]
So what is irssi, anyting? (4.00 / 1) (#15)
by kbob on Sun Feb 04, 2001 at 05:04:03 PM EST

I read the whole front page of the irssi web site, and I didn't get even a glimmer of a clue as to what irssi is.

I do know that irssi

  • has had a lot of CVS changes lately
  • has the aforementioned security wager
  • is releasing early and often
  • can be used from WAP phones
but there's no info on what it is in the first place. Why not put one sentence that give the new arrival a clue? Something like,
IRSSI is a greaseflow automation and tracking system for lube shops and fast food restaurants.
or whatever it really is.



Click the 'about' link (none / 0) (#16)
by leviathan on Sun Feb 04, 2001 at 07:00:42 PM EST

If you click there, you'll find it's a modular IRC client. I think it's reasonable to keep read-once information one click away from the front page (took me about 2 seconds max to find it).

I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert
[ Parent ]
I found what could be considered a security bug (4.00 / 1) (#17)
by trog on Sun Feb 04, 2001 at 07:31:16 PM EST

The bug is not in the code; it is in the protocol the code implements: IRC. IRC is transmitted in plaintext, just as telnet and ftp are. Any info entered using the client can be easily sniffed. So, passwords entered to gain access to restricted irc channels can be captured. In the crypto/security world (where I am involved professionally in code auditing), this is known as a sideband attack.

Why is this important? Most (clueless) people use only one or two passwords for everything. It is a good bet that the password used for access to irc are used for other things.

The IRC protocol also has no way of authenticating packets, so someone could spoof and create a "man in the middle" attack, mask as the original messenger, and ruin his reputation.

As an aside to this, many script kiddies hang out in IRC channels, just waiting for people to connect, so they can commence to portscanning, causing other disruptions. IMAO, IRC should be avoided at all costs.

My solution to this? Don't build a program, even a securily written one, on top of a non-secure protocol if it can be helped. Code security is much more than well written code; it must take into account the whole picture.

SILC (none / 0) (#19)
by cras on Sun Feb 04, 2001 at 07:44:42 PM EST

IRC is all we've got right now. But irssi isn't IRC protocol specific, there's already support for SILC which is a secure protocol, and already in a usable state.

[ Parent ]
Re: SILC (none / 0) (#20)
by trog on Sun Feb 04, 2001 at 09:28:20 PM EST

But irssi isn't IRC protocol specific, there's already support for SILC which is a secure protocol, and already in a usable state.

IMAO, the responsible thing would be to drop all support for IRC, and concentrate exclusively on SILC. In this way, you encourage the use of not only a secure program, but a secure protocol, similar to how ssh has almost completely phased out telnet (at least, in the *NIX world).

[ Parent ]

Secure programming - could be done... (5.00 / 2) (#18)
by hofmann on Sun Feb 04, 2001 at 07:35:31 PM EST

Open-source developers often code for fun. I don't know about the rest of the people, but the fun part for me is to code the best software with the best source code (well, try to at least :).

Well, it would be great if all developers would have the drive to create perfect, secure software, but it is just the case the not all open source developers see this as the really fun part. It is possible to write bug free software, but that means thorough design and picky auditing of the code, and some people tend to spend their time on new features, speed issues,... more likely. (Ok, that's me, but I am sure I am not alone :)

That said, following some rules, creating safe code is very doable. There are quite some resources on the web targeted at this topic. To name a few:

  • The SECPROG mailing list at securityfocus.com. Subscribe. The purpose of this list is discussion of secure programming techniques, with the results being incoporated into an HTML document describing regular problems/solutions. The draft can be viewed at securityfocus.
  • The book "Secure Programming for Linux and Unix HOWTO", available online.
  • (in)famous BUGTRAQ mailing list, a vast resource of programming mistakes to avoid. Subscribe.

  • Geh (5.00 / 1) (#21)
    by trhurler on Mon Feb 05, 2001 at 06:03:57 PM EST

    I go to download irssi, and I find out that you're as guilty as anyone. I don't believe for a second that there are no holes, but a team of ten programmers working for a year couldn't be sure. Here's why:

    First off, you use autoconf, which means I can't even figure out what your dependencies are in any general manner. This means there isn't just one program - there is one program per configuration option combination multipled by the number of platforms irssi runs on. I have no way of verifying what interfaces you're running against, and you haven't specified what standard you wrote to, if any, so I can't check the validity of the way you use those interfaces. If I had to guess, I'd say you probably wrote to the Linux man pages, which is to say, to no standard at all.

    Second, you ignore common and important things like putting function return values on the line before the function name so that ^functionname is a valid regular expression to find a function name, thus making it essentially not worth my time to even try to read your code at a system level, thus making it impossible to understand, and thus making an audit insanely difficult. I could run indent, but indent has bugs that almost any sizable body of code tends to bring out, causing subtle or not so subtle errors.

    Third, you use the evil and much reviled camel case, which, while it may be pleasant in textbooks, is a vile curse upon those of us who actually read code on a monitor in a reasonable font size. It literally hurts.

    Fourth, while your code is "modular," there is no overview document specifying what does what, what the interfaces between the pieces look like, and so on. I could spend more time than this program is worth just trying to gather up that information.

    Fifth, there's stuff written in Finnish. Sorry, but while many Finnish speaking people are good programmers, most good programmers are not Finnish speaking people.

    Sixth, you use perl. Once you include perl, you can forget about a security audit; perl itself is unauditable, no matter what anyone tells you, which means that anything written in perl is of questionable security no matter how good the author is.

    Seventh, you have gratuitous fluff like "themes." While kiddies may love this, the code complexity it creates is useless to bother reading for audit. Programs should either be inconsequential with respect to security or else they should not contain fluff features.

    Eighth, even you are forced to admit on your web page that you cannot verify that your code works given a hostile server. Whether this is protocol related or your fault I am not certain, but I am certain that if it is not secure against a hostile server and it uses plaintext, then it is not secure in any meaningful sense no matter what you have done. Therefore, an audit is somewhat senseless.

    Ninth, your program is loaded up with GNU library dependencies. Since those libraries are about as well written as my colon is odor-free, your program is insecure. There is no point in ferreting out errors in your code when it is linked against such a horrid mess of bad code anyway; after I was done, the result, even if I did my work perfectly, which is of course not possible, would be an insecure program.

    Tenth, your documentation is out of date. Once again, this makes it harder to actually learn about your program. Fortunately, this is little matter since it is so inadequate that even were it up to date, it would be of little use.

    Eleventh, it is an irc client. Therefore, it is insecure:)

    'God dammit, your posts make me hard.' --LilDebbie

    no real problems (5.00 / 1) (#23)
    by cras on Wed Feb 07, 2001 at 01:21:58 PM EST

    Looks like you try not only to be sure there's no security problems, but that there's no bugs at all anywhere. I don't need to be sure irssi doesn't crash if certain condition is met, I only want to be sure no-one can execute any arbitrary code through irssi and there's hardly any other possibility to do that than buffer overflows, and there's none of those. But I guess I'll have to answer some of those points:

    1) Irssi is portable, and autoconf makes it portable. Does it really matter if irssi does something one way or another depending on the system as long as both work the same way? Yes, I've used mostly Linux man pages but also UNIX98 man pages when something seems to be done differently between OSes (curses functions mostly I think). I don't think there are many non-POSIX functions used, and none of which affect security in any way.

    2, 3) Just a matter of taste. Get better regexps.

    4, 10) Yes. I don't like writing documentation. But that doesn't really mean the code sucks, only that it's harder to get into it.

    5) Only part of TODO file. Nowhere else. Does it really matter if you can't read a few of the suggested features?

    6) Perl isn't used anywhere internally, only when some external script is loaded. And I don't think user can exploit those scripts unless you're a very bad perl programmer.

    7) Themes and other fluff are only small parts of the code that affect nothing else (that's the modularity part). My first goal isn't security but about creating the best IRC/whatever client. I'll try not to put too much bloat in but things like themes are essential, almost everyone want it to be different and doing it the ircii way would be horrible for user.

    9) "Loaded with GNU libraries"? You mean GLib, what else? Yes, lib-popt is another which really is bad code, but do you count it as a security risk parsing command line options? GLib's code is pretty good and it's string functions are certainly more secure than using libc's snprintf() etc.

    I don't think you can find any sort of real security issue, you're just horrified that irssi isn't a small simple program with a few thousand lines of code.

    [ Parent ]

    More secure software | 23 comments (19 topical, 4 editorial, 0 hidden)
    Display: Sort:


    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!