[Vtigercrm-developers] Potential Security Vulnerability

[Brian Devendorf]

Setting it unreadable will make it difficult if a user needs to reuse  
it down the road. Documenting that they need to reinstall those  
files, though, should be easy.
User login checking won't work, because they are needed before the  
system is configured. The nice thing about deleting them is it  
provides a way for someone to reset the admin password if it is lost.  
They can upload the install directory and reset the password.

The only other secure way I can think of is to allow it without  
authentication until the initial configuration is done. There needs  
to be a setting in config.php (or somewhere else) that sets this  
flag. Once the flag is set, the installation files are only  
functional if the admin is logged in. This would work as well.

Most php apps I have dealt with have deletion of installation files  
as a step in their documentation for installing the package. I don't  
think deleting them is that drastic of a move. But I open to any  
truly secure options.

Brian

On Feb 21, 2006, at 2:05 PM, Sergio A. Kessler wrote:

> I think deleting the whole folder is very rude.
>
> what about setting it unreadable for the httpd user ?
>
> or check it every time a user log in, then in case is readable for the
> httpd user, put a big red pretty disturbing label at the top ? (I've
> seen this in others systems)
>
> /sak
>
> On 2/21/06, Brian Devendorf <developer at infointegrated.com> wrote:
>> I just created a ticket in Trac for a potential security  
>> vulnerability in
>> vtiger:
>> http://vtiger.fosslabs.com/cgi-bin/trac.cgi/ticket/25
>> I also created a post in the forums as well:
>> http://forums.vtiger.com/viewtopic.php?t=5704
>>
>> Here are the details:
>> I know that most good systems admins would delete the install  
>> directories (I
>> always do), but we are likely to have quite a few of the "uninitiated
>> admins" installing vtiger. I would hate to leave vtiger open for  
>> attack. The
>> install docs do not mention removing the install directory either.  
>> A hack on
>> a vtiger install would not look good if it received any kind of  
>> press. This
>> worst case scenario would force my company to switch to offering a  
>> different
>> product. I really don't want to do that.
>>
>> Here are the contents of the ticket I submitted:
>> If the install directory stays on the server after installation,  
>> an informed
>> individual could change the admin password without any trouble at  
>> all, they
>> could also view the mysql database and username information. With the
>> current change in the branch, they could also change the SQL database
>> (readonly tags removed). If the files in the install directory are  
>> removed
>> after install, this risk will not exist. I have a diff that adds  
>> simple
>> deletion of the install directory after completion of Setup Step 5.
>>
>> Here is the diff file I created for the branch:
>>
>>
>>
>> Please feel free to implement a solution to this risk however you  
>> feel it
>> should be. My diff above is a bare bones solution to the problem.  
>> It does
>> work, but I'm sure it could be done better. This was just a  
>> solution I put
>> together in a few minutes to address what I believe is a critical  
>> hole.
>>
>>
>> _______________________________________________
>> This vtiger.com email is sponsored by: Zoho Writer. Are you still  
>> using your
>> desktop word processor for typing documents? Try the AJAX enabled,
>> collaboration-friendly online word processor, Zoho Writer for FREE  
>> instead!
>> http://zohowriter.com/?vt
>>
>>
>>
>>
>
> _______________________________________________
> This vtiger.com email is sponsored by: Zoho Writer. Are you still  
> using your desktop word processor for typing documents? Try the  
> AJAX enabled, collaboration-friendly online word processor, Zoho  
> Writer for FREE instead!
> http://zohowriter.com/?vt