Re: Security bugs in Excite for Web Servers 1.1

[clair () SERVER SOLUTIONINC COM (Gurjeet Clair)]

Long time reader, first time poster, love the show Dr.Laur.. er Aleph..:)

Today I saw <Michael Gerdts> say:

> On November 11 I reported the folloing problmes to ewsbugs () excite com.  I
> have only recieved an automated reply.

 Sometimes it helps if you repeatedly poke em with the pointy end of a stick,
if they care enough:)

> I have found numerous security concerns with EWS 1.1 which can lead to an
> ordinary user being able to gain control over EWS.
>
> Problem: The installation program installs several files with world-write
>     permissions.  This is bad because one of them (Architext.conf)
>     contains the encrypted password which is used for all authentication.
>     Because of this, any user with shell or non-anonymous FTP access
>     to the web server could modify the encrypted password.
>
> Solution: At install time, ask the administrator for the username or uid
>     that CGI scripts are run as.  Make the excite installation directory
>     restrictive enough such that only this user can get into the directory
>     and make sure that no files are world-writable.  Because of other
>     concerns (such as dictionary attacks) this file should not be
>     world-readable.

Well, I found in the AT-admin.cgi file, the script repeatedly calls for
a perl function called "append_line_to_file" from the "os_functions.pl" file
in EWS' perllib directory. IE:

("$attr{'ArchitextRoot'}/Architext.conf", "AdminMail $form{'at_email'}")

 Didn't seem too bad at first, but while looking at the function it calls
another EWS grown function called "make_files_readwriteable", which looks
like this:

sub make_files_readwriteable {
    local($files) = @_;
    return 1 if ($ews_port eq 'NT');
    return system("/bin/chmod a+rw $files"); <---- EVIL!
}

Ahh, theres the litte culprit right there! The "chmod a+rw $files".  Well
one fix is to use "chmod 0600 $file" (i think u+rw) OR not use the system call
itself and use the built in perl functions to set permissions.  Of course this
only creates the permissions as the user that the webserver runs as.

 Also if the the directory is somehow writable by the a user theres a symbolic
link type problem with the "append_line_to_file" function, since what it
actually does is rename the old file (in this case Architext.conf.old) and then
creates the new file (Architext.conf) and copies things over.

  After skimming the whole functions file, it seems to me theres quite a few
little gems like the previous mentioned functions in there.  Its like
Link from Zelda running through the forest and collecting Rupee's eh?


> Problem: All authentication after the initial access to AT-admin.cgi relies
>     solely on the encrypted password.  Since any user with shell or FTP
>     access can read Architext.conf, it is trivial for local users to
>     gain administrative privileges over EWS.>
>     [snipped for lengthiness]
> Solution: I am not an expert in web security.  There certainly must be
>     better solutions.

Perhaps my transmitting a new hash of the password each time? Many solutions
to this that goes beyond my simple understanding.

[chop chop chop]
> --
> Michael Gerdts
> UNIX Systems Administrator
> Computer-Aided Engineering Center
> University of Wisconsin - Madison


--

 Gurjeet Clair (clair () solutioninc com,@ug.cs.dal.ca, tf () dp org)
 Programmer, Network and Systems Admin, SolInc Ltd. (part time student)
 "C code.  C code run.  Run code, run! Please??" - Barbara Tongue
 "The Internet is full. Go away."  - Joel Furr