This bug is old. All Tripbit have managed to do is find a new way of exploiting an old/known bug. Eg by sending the '../' string in unicode format rather than sending it normally. The bug was originally found by subversive from the Security Freaks and the original advisory can be located at: http://securityfocus.com/archive/1/318775 Of course if tripbit had bothered to check out the validity of their find before posting it then they would already know this... Oh and while i'm here i might as well mention that there is two rather blatent local buffer overflow vulnerabilities in the Tripbit (rather insecure) "Secure Code Analizer". Both of which are picked up by the scanner if checking its own source. It seems funny to me (and rather stupid) that posidron did not bother to scan his own source for bugs before releasing it on their group site. It also seems funny to me that no other members of the group noticed the bugs considering tripbit is supposedly a 'security group' and if im not mistaken auditing sourcecode is something that 'security groups' do especially considering how obvious these vulnerabilities are. But anyway your probably all dying for me to fill you all in so lets get down to biznas! Securecode.c: http://www.tripbit.org/releases/securecode.c Details: akcess@cia:~$ cat -n securecode.c 1 /* 2 * Secure Code Analizer v1.0 3 * 4 * Tripbit Security Development 5 * Author: posidron 6 * Website: tripbit.org 7 * 8 * 9 * ABOUT 10 * 11 * This tool scans your source code to different dangerous functions, 12 * like strcpy(), gets(), getenv(), sscanf() etc. 13 * 14 * 15 * OPTIONS 16 * 17 * [+] single source file -s [SOURCE_FILE] 18 * 19 * 20 * FEATURES 21 * 22 * [+] several source files -m [SOURCE_FILE, SOURCE_FILE ... ] [...] 40 int main(int argc, char *argv[]) 41 { 42 int counter=3; 43 char buffer[1024]; [...] 49 strcpy(buffer,argv[2]); ^^^^^^^^^ BLATENT [IN]SECURECODE.C LOCAL BUFFER OVERFLOW #1!@%$ ^^^^^^^^^ STRCPY(BUFFER, ARGV[2]);... ? WHAT IN GODS NAME WERE ^^^^^^^^^ YOU SMOKING WHEN YOU WROTE THIS... ? [...] 70 int single_source(char *buffer) 71 { 72 char puffer[256]; 73 int counter = 1; 74 FILE *source_file; 75 source_file = fopen(buffer, "rt"); [...] 84 while(fgets(puffer, 1024, source_file) != NULL) ^^^^^^^^^ BLATENT [IN]SECURECODE.C LOCAL BUFFER OVERFLOW #2!@%$ ^^^^^^^^^ PUFFER ONLY 256 BYTES BIG BUT MAX SIZE THAT WE CAN ^^^^^^^^^ PASS TO PUFFER IS 1024... FOR THOSE OF YOU OUT THERE ^^^^^^^^^ THAT AREN'T GOOD AT MATH 1024 DOES NOT GO INTO 256, ^^^^^^^^^ WHICH MEANS IF WE MAKE SOURCE_FILE BIGGER THAN 256 ^^^^^^^^^ THEN KABOOM! SEGMENTATION FAULT... ;D And there you have it. Not one but TWO blatent vulns in a program designed for the purpose of finding them, might just be me but i find this quite ironic, don't you... ? Well done posidron, keep up the good work! akcess -- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze
This archive was generated by hypermail 2b30 : Tue Jun 24 2003 - 10:02:50 PDT