lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20040215141233.GA10666@c9x.org>
From: j at pureftpd.org (Jedi/Sector One)
Subject: Buffer overflow in mnoGoSearch

Product : mnoGoSearch
Date    : 02/15/2004
Author  : Frank Denis <j@...eftpd.org>


   ------------------------[ Product description ]------------------------

  From the web site :
  
  mnoGoSearch (formerly known as UdmSearch) is a full-featured web search
engine software for intranet and internet servers.

  mnoGoSearch for UNIX is a free software covered by the GNU General Public
License and mnoGoSearch for Windows is a commercial search software version.

  Home page : http://www.mnogosearch.ru/


      ------------------------[ Vulnerability ]------------------------

  Every document is stored in multiple parts according to its sections
(description, body, etc) in databases. And when the content has to be sent
to the client, UdmDocToTextBuf() concatenates those parts together and skips
metadata.

  Unfortunately, that function lacks bounds checking and a buffer overflow
can be triggered by indexing a large enough document.
  

	 ------------------------[ Details ]------------------------

  From src/doc.c of the latest release (3.2.15) :              
               
int UdmDocToTextBuf(UDM_DOCUMENT * Doc,char *textbuf,size_t len){
    size_t  i;
    char    *end;
    
    textbuf[0]='\0';    
    udm_snprintf(textbuf, len, "<DOC");
    
    end=textbuf+strlen(textbuf);    
    for(i=0;i<Doc->Sections.nvars;i++){
        ...                                             
        sprintf(end,"\t%s=\"%s\"",S->name,S->val);
        end=end+strlen(end);
    }
    strcpy(end,">");
    return UDM_OK;
}
                                                        
  'len' is fixed to 10K in searchd.c . S->val length depends on the length of
the original document and on the indexer settings (the sample configuration
file has low limits that work around the bug, though).

  Exploitation should be easy, moreover textbuf points to the stack.    


    ------------------------[ Affected versions ]------------------------

  mnoGoSearch 3.2.15, 3.2.14 and 3.2.13 have been verified to be vulnerable,
previous versions may also be affected.

  
       ------------------------[ Workarounds ]------------------------

  The max size of every section is configurable un the document sections of
the indexer.conf :

Section body                    1       8192
Section title                   2       128
Section meta.keywords           3       128
Section meta.description        4       128
...

  Make sure that the last value of each section is below 10 kilobytes.
  
  If you need to use a larger value (which can be handy for the body section
to get accurate extracts without using stored), the size of the buffer is
defined in src/searchd.c, in do_client(), around line 216. Change the
textbuf[] size to something that matches the maximum size of your sections.


      ------------------------[ Vendor status ]------------------------

  Vendor was notified on Jan 8 with mails to devel@...gosearch.org.
  Other vulnerabilities were reported as well.
  No answer was ever received and no fixed version seems to be available yet.


-- 
 __  /*-    Frank DENIS (Jedi/Sector One) <j at 42-Networks.Com>    -*\  __
 \ '/    <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a>    \' /
  \/  <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a>  \/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ