Date: Tue, 24 Jun 2003 19:35:57 +0800
From: "akcess ." <akcss@...uxmail.org>
To: bugtraq@...urityfocus.com
Subject: Re: TA-2003-06 Directory Transversal Vulnerability in iWeb Server 2


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

Powered by blists - more mailing lists