fP's already been MADE aware...nothing happened.

Fairlight fairlite at fairlite.com
Sat Apr 30 21:24:31 PDT 2005


I got curious JUST how long it's been unresolved since I -officially-
submitted it.

As you can see below, I -did- submit it to fP-Tech in November, 2003.
As you'll also note, I'm still waiting for my bloody timely response.

I knew I'd reported it.  And the util/bin thing is what I remembered as
fp/lib/install in the other post tonight.  Bad memory.  Thank God for
archives.

I note that I -never- received one comment from the vendor, public or
private, regarding this issues.  What does it take?  A listing on VulnWatch
or the like?  I'd say a year and a half is more than enough time to fix
this stuff.

mark->

----- Forwarded message from Fairlight <fairlite at fairlite.com> -----

> From: Fairlight <fairlite at fairlite.com>
> To: support at fptech.net
> Date: Wed, 26 Nov 2003 15:06:39 -0500
> Subject: Security Issues with filePro
> Cc: filePro Mailing List <filepro-list at seaslug.org>
> 
> Dear fP-Tech Support Staff:
> 
> While I do not directly license or use filePro myself, I administer and
> co-administer multiple machines for multiple parties, on which the product is 
> licensed, installed, and deployed.  My role in administration includes 
> maintaining the best security I can on these systems, for companies and
> individuals that are our mutual customers.
> 
> I feel it necessary at this time to report the following security issues
> that I believe exist with your filePro and fPCGI products running under *nix
> platforms, and ask for resolutions that I believe will benefit every user of 
> filePro.
> 
> 
> Issues:
> 
> 1) EXPORT creates files with a mode of 0666.  This appears to be
>    un-configurable from within filePro.  I have attempted to alter umask
>    settings to no avail.  The mode simply appears to be hard-coded into the
>    product.  This requires that developers using your product either add more
>    code in the form of an OPEN/CLOSE to obtain a 0600 mode, or that they use
>    SYSTEM to execute a chmod.  The former is a burden that I do not believe
>    the developer should bear.  All modes of files generated by any software 
>    should either honour the set umask, or provide an inherently secure mode.
>    The latter solution incurs processing overhead in the form of execution
>    time and resource use that should not be necessary and that degrade
>    system performance unacceptably.
> 
> 2) OPEN creates files with a mode of 0600.  While this is secure, it is
>    not always desirable, and offers the developer little flexibility
>    without incurring similar overhead to the solutions available for EXPORT.  
> 
> 3) filePro's installation and permission-setting utilities present
>    additional security risks.  To wit:
> 
> * I have observed a mode 0777 */fp/util/bin directory.  I was informed by
>   one developer that this is set at installation.  Mode 1777 should be used
>   where world-writable directories are necessary.
> 
> * I have observed that */fp/lib/config is set to mode 0666.  A check of
>   the */fp/scripts/fp.list file shows that 'setperms' will always set this 
>   file to this mode by default.  The mode should be 0644.  However, I have
>   conflicting reports from multiple developers as to whether this can
>   currently be enforced by manual means.  One developer tells me that it can
>   indeed be changed to no ill effect.  Another developer disputes this, 
>   saying that filePro does not function properly if this file is set to 0644.  
> 
> 4) I am also informed by one developer that the fPCGI product does not
>    honour its internal umask setting, and this is the cause of numerous 
>    0666-moded files on several systems that I've observed.  I was informed
>    that this particular issue is already under investigation, but include
>    it for the sake of completeness and emphasis.
> 
> To the best of my knowledge, the above details are accurate.  I have
> personally verified to my satisfaction the non-alterable nature of the
> default file creation modes for both EXPORT and OPEN, as well as inspected
> multiple fp.list files that all contain the offending 0666 for the config
> file.  I am admittedly relying on developer 'hearsay' regarding fPCGI and
> the */fp/util/bin modes.  I have observed both results, and the answer I
> got upon inquiry was that it was your software's doing.  Lacking firsthand 
> test data, I defer to the professionals that work daily with your product, 
> and presume that I was provided accurate information on those counts.
> 
> 
> Recommendations and Requests:
> 
> 1) All files and directories should be made to install with secure modes by
>    default.
> 
> 2) Would you please inform me if filePro will function 100% properly if the
>    */fp/lib/config file is set to mode 0644?  If it will not, the software
>    should be modified so that it will do so.  In either event, the fp.list
>    file should be tightened to have a mode of 0644 at a maximum.
> 
> 3) If alternate methods of controlling the default file creation modes of
>    the output functions EXPORT and OPEN (and any others of which I am not 
>    aware, or am omitting) are available, would you please supply them so that 
>    I may inform the developers with whom I work?  If there are no methods of 
>    controlling these default modes, I would strongly recommend that umask
>    settings be honoured.  This would conform with the standards of most
>    software for *nix platforms.
> 
> 4) EXPORT's default file creation mode should immediately be changed to a 
>    secure setting, at a minimum.  
> 
> 5) fPCGI's default file creation mode and override ability should
>    immediately be corrected to allow for secure settings.
> 
> 6) Any other file creation modes of which I am not aware or which I am
>    accidentally omitting should be altered in similar fashions to ensure
>    the highest level of default security possible, secondarily being
>    re-implemented to allow developers the flexibility to loosen permissions
>    at their own risk, on an "as needed" basis.
> 
> 
> Summary:
> 
> The risks of promiscuous file modes are multiple and varied, ranging from
> data interception, to covert data alteration and/or deletion, to the
> extremes of filesystem denials of service.  From all evidence available to 
> me, fllePro and fPCGI have issues which allow such activity to be indulged 
> in by anyone of a mind to do so, unless the developers are both cognizant of 
> the dangers inherent and are willing to bear the burden of incurring extra 
> overhead to work around the issues that present these risks.
> 
> Given the severity of the consequences of the mode-related potential attacks, 
> it would be my strong suggestion that at least an interim patch or release 
> with tightened file mode security be released within 2-4 weeks, and that
> all developers and known end-users be conspicuously and unambiguously made
> aware of both the current risks they face, and the availability of the
> secure solutions that should be offered.  While one developer has
> wish-listed a complete review of default file creation modes on my behalf,
> I feel that it is of significant enough importance that an interim solution 
> should be provided expediently, pending full review and the application of
> any more complicated and permanents changes in the implementation of file 
> creation modes.
> 
> Noting that the issues are security-related (and long-standing, as I
> understand from developer comments that some of these issues have existed
> for years), I also strongly believe said remedies should be provided free of 
> charge to all licensed parties of all currently supported versions of the 
> products.
> 
> That the issues are long-standing does not mitigate the danger that they
> currently pose in today's increasingly hostile computing environment.  
> Security is paramount, and these changes will greatly benefit our mutual 
> customers, including end-users that may not even be aware of the risks 
> involved.  No system can be made perfect, but one tries one's best to ensure
> as little negative exposure as possible.  The requested changes would greatly
> assist all administrators, users, developers, and systems integrators who
> work with your product in any way, by making it possible to reduce that
> exposure.
> 
> I look forward to receiving a timely response regarding the questions I pose 
> here, and which details your plans for short- and long-term resolution of 
> these security issues which affect our mutual customers.
> 
> Bests,
> 
> Mark Luljak
> Fairlight Consulting
> 

----- End forwarded message -----

-- 
Fairlight->   ||| Some people, mostly military,      | Fairlight Consulting
  __/\__      ||| would have called the entire       |
 <__<>__>     ||| situation a cluster fsck.  But     | http://www.fairlite.com
    \/        ||| that would include the possibility | info at fairlite.com
              ||| for actual pleasure being derived. |
              ||| Nay, this was surely, and without  |
              ||| any doubt whatsoever, a cluster    |
              ||| chastity.                          |


More information about the Filepro-list mailing list