Potential Security Vulnerability

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Potential Security Vulnerability

Brian Devendorf-2
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 

install_cleanup.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Potential Security Vulnerability

Sergio A. Kessler-2
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 <[hidden email]> 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 
Reply | Threaded
Open this post in threaded view
|

Re: Potential Security Vulnerability

Brian Devendorf-2
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 <[hidden email]> 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

_______________________________________________
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 
Reply | Threaded
Open this post in threaded view
|

Re: Potential Security Vulnerability

Sergio A. Kessler-2
I've never seen a php package that deletes the install folder, never
(and I've installed a lot of them).
most of them *tell you* to delete it (or rename it), tough, that's
very different.

and most of them, when you log in, tell you something like this:
"Hey, your install folder is still accesible !  delete it or make it
unaccesable"
(this is the check on login I was talking about)

$install_folder = 'install';
if (file_exists($install_folder)) {
   echo "stupid admin !";
}

/sak


On 2/21/06, Brian Devendorf <[hidden email]> wrote:

> 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 <[hidden email]> 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
>
> _______________________________________________
> 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 
Reply | Threaded
Open this post in threaded view
|

Re: Potential Security Vulnerability

Mike Fedyk
I like this better than deleting the folder automatically.  Anyone that
has any issue will now have to be told how to put it back.  Imagine the
forums...  Oh God no! ;)

Let's keep it to a warning.

Sergio A. Kessler wrote:

>I've never seen a php package that deletes the install folder, never
>(and I've installed a lot of them).
>most of them *tell you* to delete it (or rename it), tough, that's
>very different.
>
>and most of them, when you log in, tell you something like this:
>"Hey, your install folder is still accesible !  delete it or make it
>unaccesable"
>(this is the check on login I was talking about)
>
>$install_folder = 'install';
>if (file_exists($install_folder)) {
>   echo "stupid admin !";
>}
>
>/sak
>
>
>On 2/21/06, Brian Devendorf <[hidden email]> wrote:
>  
>
>>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 <[hidden email]> 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
>>>      
>>>
>>_______________________________________________
>>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 
>
>  
>
_______________________________________________
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 
Reply | Threaded
Open this post in threaded view
|

Re: Potential Security Vulnerability

Brian Devendorf-2
I have created a new proposal for addressing this issue. My new patch  
creates a config_lock.php file upon completion of the last  
installation step.

When the install.php file is called directly: If config.php is setup  
with a database (existing config check) and a config_lock.php file  
exists in the vtiger root, then it redirects back to index.php.

The config_lock.php file has text indicating it needs to be deleted  
to enable the install functions.

As an additional precaution, the scripts that are in the install  
directory are coded to prevent direct execution if the lock file  
exists in the parent directory (vtiger's root).

I have already created a patch for this and updated my previous  
ticket (#25) in Trac. There is little time to RC and I'd like to have  
a solution in 4.2.4. I feel that it is important to provide a certain  
level of security for even the most inexperienced installers. I think  
this does that... and does it without deleting the install directory.

Comments are welcome (but please do so quickly, so that I have time  
to get a solution into 4.2.4).
Thanks.

Brian


On Feb 21, 2006, at 4:25 PM, Mike Fedyk wrote:

> I like this better than deleting the folder automatically.  Anyone  
> that
> has any issue will now have to be told how to put it back.  Imagine  
> the
> forums...  Oh God no! ;)
>
> Let's keep it to a warning.
>
> Sergio A. Kessler wrote:
>
>> I've never seen a php package that deletes the install folder, never
>> (and I've installed a lot of them).
>> most of them *tell you* to delete it (or rename it), tough, that's
>> very different.
>>
>> and most of them, when you log in, tell you something like this:
>> "Hey, your install folder is still accesible !  delete it or make it
>> unaccesable"
>> (this is the check on login I was talking about)
>>
>> $install_folder = 'install';
>> if (file_exists($install_folder)) {
>>   echo "stupid admin !";
>> }
>>
>> /sak
>>
>>
>> On 2/21/06, Brian Devendorf <[hidden email]> wrote:
>>
>>
>>> 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 <[hidden email]> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
> _______________________________________________
> 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 
Reply | Threaded
Open this post in threaded view
|

Re: Potential Security Vulnerability

Mike Fedyk
I have made a few comments about this patch to Brian on IRC and a couple
things have changed.

Brian Devendorf wrote:

>I have created a new proposal for addressing this issue. My new patch  
>creates a config_lock.php file upon completion of the last  
>installation step.
>  
>

The new file name is "install_lock"

>When the install.php file is called directly: If config.php is setup  
>with a database (existing config check) and a config_lock.php file  
>exists in the vtiger root, then it redirects back to index.php.
>
>The config_lock.php file has text indicating it needs to be deleted  
>to enable the install functions.
>
>As an additional precaution, the scripts that are in the install  
>directory are coded to prevent direct execution if the lock file  
>exists in the parent directory (vtiger's root).
>
>I have already created a patch for this and updated my previous  
>ticket (#25) in Trac. There is little time to RC and I'd like to have  
>a solution in 4.2.4. I feel that it is important to provide a certain  
>level of security for even the most inexperienced installers. I think  
>this does that... and does it without deleting the install directory.
>
>Comments are welcome (but please do so quickly, so that I have time  
>to get a solution into 4.2.4).
>Thanks.
>
>Brian
>
I like the patch, but would like to see if others agree it is the right
way to go before merging.

Mike
_______________________________________________
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