From owner-freebsd-questions Tue Apr 18 20:57:56 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA04524 for questions-outgoing; Tue, 18 Apr 1995 20:57:56 -0700 Received: from arthur.cs.purdue.edu (root@arthur.cs.purdue.edu [128.10.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA04509 ; Tue, 18 Apr 1995 20:57:39 -0700 Received: from moriarty.cs.purdue.edu (root@moriarty.cs.purdue.edu [128.10.2.69]) by arthur.cs.purdue.edu (8.6.10/PURDUE_CS-1.3) with ESMTP id ; Tue, 18 Apr 1995 22:57:33 -0500 Received: from localhost (wam@localhost [127.0.0.1]) by moriarty.cs.purdue.edu (8.6.10/PURDUE_CS-1.3) with SMTP id ; Tue, 18 Apr 1995 22:57:32 -0500 Message-Id: <199504190357.WAA09930@moriarty.cs.purdue.edu> To: jfieber@cs.smith.edu (John Fieber) cc: nc@ain.charm.net (Network Coordinator), freebsd-security@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: httpd - security problem? (question, not a statement) Date: Tue, 18 Apr 1995 22:57:31 -0500 From: wam@cs.purdue.edu (William McVey) Sender: questions-owner@FreeBSD.org Precedence: bulk John Fieber wrote: >There was a bug in the NCSA http server which has since been >fixed. I'm not currently aware of any problems with the CERN >server. Actually, the one "hole" that an exploit script was written for (and published) was fixed. The NCSA http server still has lots of sloppy code that are indicate security problems. (ie, lots of strcpy as opposed to strncpy, sprintf's into fixed buffers with no range checking, etc.) I've appended a copy of a mail message posted to bugtraq that details just one of the other vulnerabilities. There are others, I'm sure. -- William McVey System Support Staff Computer Science Department Purdue University ----- Begin included message (copied without permission) ----- From: Paul Phillips Date: Tue, 11 Apr 1995 20:59:05 -0700 Message-Id: <199504120359.UAA03182@nic.cerf.net> Newsgroups: comp.infosystems.www.providers,comp.security.unix Subject: Still security holes in NCSA httpd 1.3R Keywords: security httpd www Cc: bugtraq@fc.net, www-security@ns1.rutgers.edu Precedence: bulk NCSA has been claiming at that their patch to httpd, which fixed the hole in strsubfirst, was sufficient to fix the stack overflow bug discovered by Thomas Lopatic. This is incorrect. There is at least one more instance of the same problem, this one in log_reason. NCSA has provided a performance reason not to #define MAX_STRING_LEN to HUGE_STRING_LEN (i.e. you will enter swap hell) and they are correct about that, but unfortunately that doesn't magically make the hole go away. >>> begin code traversal >>> When accept is handed some data, httpd.c calls process_request in http_request.c: 213: process_request(0,stdout); process_request allocates url[HUGE_STRING_LEN] for parsing out the URL. It calls getline in util.c to obtain the info from the socket: 104: if(getline(l,HUGE_STRING_LEN,in,timeout)) process_request now decides what the method is, and calls the relevant function. Take GET for example: it calls process_get in http_get.c with the url as an argument: 143: process_get(in,out,m,url,args); Let's say it's a standard document, so process_get calls send_node with the url as an argument (still possibly HUGE_STRING_LEN long) 195: send_node(url,args,in,out); Now send_node does various checks. Let's say the file does not exist: send_node wants to log it, here: 122: log_reason("file does not exist",file); where file is the passed url, still possible 8192 characters. log_reason is in http_log.c, and quite short: void log_reason(char *reason, char *file) { char t[MAX_STRING_LEN]; sprintf(t,"httpd: access to %s failed for %s, reason: %s", file,remote_name,reason); log_error(t); } The file can be 8192 characters, but it's sprintfed into a 256 character buffer. >>> end code traversal >>> This particular traversal is just an example, log_reason is called from several places with overlarge buffers. I pointed this out to the httpd people at NCSA, who promised a patch but haven't acted with much alacrity. Frankly I am very skeptical that any patch will fix all holes until I finish checking out all the code. When 1.4 is released to the public I will examine it in depth as soon as possible. Regards, -- Paul Phillips paulp@cerf.net ----- Begin included message -----