New Messages
Please send letters via email to saletter@rdpub.com.
From: David Owen I am sure that lots of people will have told you this, but your information regarding Linux was a bit inaccurate. The "latest and greatest" is a bit of a funny concept for Linux. There are two parallel releases that are "current" in the Linux world; there are the 1.2 series kernels and the 1.3 series. The 1.2 series is the "production" quality and is currently on 1.2.13 and has been for a while. It is probably due for a new release soon. The 1.3 series are developer's kernels and are where all the exciting development is happening. You think about what you want/need and take your choice.
David Owen P.S. The 1.3 series is progressing so fast that the release number seems to change daily. I built a 1.3.15 kernel that works with all the stuff I need, just about, and a 1.2.13 kernel as my "production" kernel. Well, I knew that -- at least I think I did. In all truthfulness, I haven't been able to find the story that mentioned the "latest and greatest" version. No matter. Thanks for reminding us all of the Linux version convention. --rlw
To: saletter@rdpub.com I was reviewing the Administrator Menu Program in the March 1996 Sys Admin magazine and found several potential security problems that could result in a compromise of a system running that program. I felt obligated to inform you of the problems so you could inform your readers. In the file amp.c (Listing 1), there is the following code in execute()
/*Executeamp.sscript*/ frcode=system(cmdstr);
Many problems exists in using the system() function call from within a setuid program. Most of the problems can be traced to the fact that a user's environment is still intact while system executes the program. This allows users to play games with shell environment variables like IFS, PATH, LD_LIBRARY_PATH, and numerous other security sensitive variables. Page 75 of Practical Unix Security explains one classic attack against the /usr/lib/preserve utility that used system() from within a setuid program. Also of worry are the shell scripts invoked by amp. Each of these shell scripts would allow a person with admin access to the application the possibility of getting to an interactive root shell. For one, none of the scripts use full pathnames, or even reset the PATH to a known value. This could allow people to insert their own personal directory of programs that would get executed (as root) before the standard system directories get searched. All the admin scripts listed have this problem. Basically, any input entered by a non-root id should be very carefully analyzed to determine if there are any security problems with it. As another example, the adduser shell does not look at the entered userid at all to determine if the userid is valid or not. For all we know, a user running your app could enter a username including colons that could get them root (à la "myroot::0:0:"). And as a final nit, in amp.c there is a strcmp. In this particular case it would be hard to exploit, but in general you should avoid strcmp in favor of strncmp within setuid executables. The strcmp function suffers from the same problem gets() does in that there is no buffer length checking. It is distressing to see the same class of bug that was exploited with the Internet Worm still creeping into privileged code.
-- William McVey Thank you very much for sharing your analysis. I fear that a great deal of what we publish has similar security weaknesses. I appreciate your taking the time to identify and explain the problems with this code. It makes a nice little tutorial for those of us with weak security backgrounds. You can write me anytime! --rlw
|