A Comment on Bugtracking

On November 20, 2000, I was sent an e-mail by someone who called himself Zorgon. It read:

CGIForum is a free forum. We can set `thesection’ parameter to view files on the vulnerable system with privileges of the user “nobody”. This is caused from OutputHTMLFile function in cgiforum.pl script where $section (= $thesection ) isn’t checked (never besides in this script).} etc.

The message indicates that this person had not only detected the problem, but also understood its cause and very probably could have fixed it without my help. The words “never besides in this script” are also true, but perhaps irritating because all I had to do was to add a single line to fix the problem. On November 23, I a new version of CGIForum.

Being curious, I did a search on Google today. I entered Markus Triska and was surprised about the results. I found Zorgon’s original message to me on half a dozen sites. A few sites list the original report exclusively, whereas some sites only tell you that an updated version exists, like the archives here.

The vast majority of sites, however, only inform you about the problem, or at least about some problem. Some reports have errors, and some are simply wrong. This one for example begins with the words “Markus Triska’s CGIForum is a commercial CGI script”, which it simply isn’t and never was. This one is even more radical, stating that “DCForum is a commercial cgi script from Markus Triska”. I wonder where they get their news from.

The point is that I really appreciate the work of bughunters. Of course I would like to know as soon as possible whether the programs I use have security flaws. I’m honestly thankful for every bug that someone finds in my programs. I also understand the greed for being the first to report a bug.

On the other hand, if I discovered a bug, I would think very carefully if I should not inform the author before I submit a report to a security-site on the net. For what do you gain – except being first – when suddenly everyone knows the bug, but no alternative is available? Would it then not have been better if the author had had a few days more to work without pressure on a clean solution? Why not live in Acknowledgements and Thanks-sections in place of spiteful dreams of angry programmers who introduce new bugs while panically fixing the old?

A note on bugtracking-lists: Everyone can blindly copy every announcement and report from the net, bundle and publish them. Even a program can do that. But what is it good for? Do you really excpect someone to learn a list by heart in order to say someday: “CGIForum? Hm, wait—yes, I once saw it in a bugtracking-list. Don’t use it.” To my mind, it’s more likely that a person who wants to use a program will do some research on the web anyway. In this case, a list which offers minimal information per package, but this in great density, buys you exactly nothing.

Proper maintenance of information that changes from day to day is a hard and exhausting, yet often unrewarded task. Consequently, it’s not often done, and few bugtracking-lists are trustworthy. I found out that CGIForum appearshere and here, although the problem was fixed a long time ago. The maintainer of the latter list calls himself arbon. On June 14, I sent him a message stating that the issue was long gone. There was no reaction.

Finally, remember that I was facing a bug that was really easy to fix. Under certain circumstances, I would not have received Zorgon’s e-mail or I probably would not have had the oppurtunity to react properly. In this case, the only chance to save the users of CGIForum from a vulnerable system would have been to announce that they should stop using it and switch to commercial programs instead. Is this what you want?

Share this
You are reading

A Comment on Bugtracking