--- Barrie Heck <[EMAIL PROTECTED]> wrote: > We fully respect the conditions of the GPL and in fact have contributed > greatly ourselves towards the development of applications based on perl, as > well as many others. This specific requirement is security related, where a > user with any intelligence, could read the source and make use of a security > issue created by using sudo. > > Regards > > Barrie
Aack! You've come up with one of the worst reasons to hide your code. I apologize in advance for what I'm about to write. It's not directed at you. This is taken verbatim from lesson 3 of my CGI course (http://www.easystreet.com/~ovid/cgi_course/lesson_three/lesson_three.html): START------------------------------------------ Security by Obscurity Security by Obscurity (SbO) relies on the following premise: since crackers don't know what security holes might be present on my system, they can't exploit them. Analogies are dangerous in that they tend to oversimplify situations, but I'm going to give you an analogy that explains this concept perfectly. Robbers will ignore my place because the front door is closed and they don't know it's unlocked. Does that sound really stupid? Good. When it comes to security, you should clamp down like a pit bull on a politician's thigh. Umm... well... perhaps a kinder, gentler analogy would be better, but the "pit bull" is a good indication of the level of attention that you should pay to this issue. One point of clarification: SbO does not mean that you should just let people have any information that they want. SbO attempts to rely on luck. You hope that crackers don't find the loopholes. By paying proper attention to security, you can remain relatively confident that the loopholes are not there, but there is no need to give out too much information in the event that you missed something, or that a new vulnerability is discovered. I suppose that in a perfectly secure environment, you could let everyone know what Web server you are running, the OS it is running on, the Perl version you are using, a full list of user names, etc. However, that would be a Bad Thing. Play your cards close to your chest. One mistake you'll often find in CGI scripts is the following: use CGI::Carp qw(fatalsToBrowser); What that line does is display all errors to your browser in addition to writing them out to the log. I use it quite heavily when I am writing and debugging CGI programs. However, when the program is ready and it's time to move it into production, some programmers do not remove it. The problem with that line is that if a would-be cracker manages to crash your script, all sorts of information shows up in the browser window. Since bugs, by definition, are unplanned, you have no idea what information you would be giving out. Lock your scripts down tight, but don't help out crackers by giving them information that they do not need. Even if your script is perfectly solid, you often have little control over what happens to it in the future. END------------------------------------------ What I hear you saying is that you have a known security issue and, rather than fixing it, you want to hide it. This is not a good thing to do. If all you're trying to do is hide the problem, but you're not too concerned about seeing the code for which there is no problem, post the relevant code here, at an appropriate newsgroup, or on Perlmonks and let many pairs of eyes help you. Cheers, Curtis "Ovid" Poe ===== "Ovid" on http://www.perlmonks.org/ Someone asked me how to count to 10 in Perl: push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//; shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
