LinuxFocus.org: Avoiding security holes when developing an application - Part 1Feb 18, 2001, 20:00 (0 Talkback[s])
(Other stories by Frédéric Raynal, Christophe Blaess, Christophe Grenier)
"It doesn't take more than two weeks before a major application, part of most Linux distributions, presents a security hole, allowing, for instance, a local user to become root. Despite the great quality of most of this software, ensuring the security of a program is a hard job : it must not allow a bad guy to benefit illegally from system resources. The availability of application source code is a good thing, much appreciated by programmers, but the smallest defect in a software becomes visible to everyone. Furthermore, the detection of such defects comes at random and people doing that sort of things do not always act with good intentions."
"From the sysadmin side, daily work consists of reading the lists concerning security problems and updating immediately the involved packages. For a programmer it can be a good lesson to try out such security problems. Avoiding security holes from the beginning is preferred. We'll try to define some "classic" dangerous behaviors and provide solutions to reduce the risks. We won't talk about network security problems since they often come from configuration mistakes (dangerous cgi-bin scripts, ...) or from system bugs allowing DOS (Denial Of Service) type attacks to prevent a machine from listening to its own clients. These problems concern the sysadmin or the kernel developers, but the application programmer too, as soon as he takes into account external data. For instance, pine, acroread, netscape, access,... on some versions under some conditions allowed remote access or information leaks. As a matter of fact secure programming is everyone's concern."
"This set of articles shows methods which can be used to damage an Unix system. We could only have mentioned them or said a few words about them, but we prefer open explanations to make people understand the risks. Thus, when debugging a program or developing your own, you'll be able to avoid or correct these mistakes. For each discussed hole, we will take the same approach. We'll start detailing the way it works. Next, we will show how to avoid it. For every example we will use security holes still presents in wide spread software."