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