On 2/28/2007 3:02 PM, Bob Stump wrote:
> They are unable to exploit it.
> The specail patch and/or subsequent MP's resolves the problem.
> The problem is the software does not acknowledging that the resolution
> has been accomplished.
This is an issue with both vendors. First, Veritas/Symantec is at fault
for not being able to provide an accurate running version number for
their products. As a customer community, we've been grumbling about
this for several years and they have yet to globally fix it. It's an
issue because without doing something like file checksums and file
dates, even Symantec can't tell you what version you're running.
It's a problem with Qualys because they're basing a security statement
solely on the version string they get back during their scan. I've seen
many similar issues with scanning for security vulnerabilities in open
source software where the vendor doesn't understand that distributors
like Red Hat backport security fixes into older releases of software.
Qualys could, and perhaps should, maintain checksums of all the known
images.
It's not politics - it's a real weakness in both vendor's product sets.
Both of them need to realize that secure systems can only happen with
a partnership between the vendors and the customers. All of us *MUST*
be able to accurately and definitively identify what version we're
running and what patches need to be applied. If they continue to make
it hard, our systems *will* be vulnerable and we *will* blame the vendor
for releasing products with security holes. I can't ask the admins to
check 300 client systems and verify what versions they're running (and
they have to sign on to each box to do it) - the master server has to
talk to the friggin' client anyway and it should do the asking. That's
what computers are for.
.../Ed
> >>> "Martin, Jonathan (Contractor)" <JMARTI05 at intersil.com> 2/28/2007
> 1:54 PM >>>
> Is the software saying the problem still exists because it doesn't see
> the new NBU version, or because it is exploiting the code vulnerability?
>
> Call me crazy but..... If their software says you have problem, but
> can't prove it then short of running the exploit yourself (which IMO is
> a major waste of time) then the NBU documentation should suffice. If
> their software is infact exploiting that problem and you are running a
> future release then someone needs to inform Symantec. I find the latter
> unlikely...
>
> Stupid politics...
>
> -Jonathan
>
> ------------------------------------------------------------------------
> *From:* veritas-bu-bounces at mailman.eng.auburn.edu
> [mailto:veritas-bu-bounces at mailman.eng.auburn.edu] *On Behalf Of *Bob Stump
> *Sent:* Wednesday, February 28, 2007 1:14 PM
> *To:* veritas-bu at mailman.eng.auburn.edu
> *Subject:* [Veritas-bu] qualys vulnerability
>
>
> There is a scanning software provided by "Qualys" that has a problem but
> they REFUSE to fix their scanning software. The scanning software
> reports the vulnerability discussed in this notice but fails to report
> that the proper MP was applied to resolve the vulnerability. This is
> what our security group calls a "false positive". They then require
> that paper work be submitted to negate the "false positive". I think
> the scanning software should be fixed to NOT report a vulnerability, if
> the proper resolution has already been applied. Am I wrong?
>
> Here is the initial symantec resolution
> A vulnerability has recently been discovered, which affects the
> bpjava-msvc logon process within VERITAS NetBackup (tm) 4.5, 5.0, 5.1,
> and 6.0 (including maintenance and feature packs). This vulnerability
> could potentially allow remote malicious users to execute arbitrary code.
> http://support.veritas.com/docs/279085
>
> The above resolution IS INCLUDED in subsequent maintenance packs.
>
> BTW: I asked our security group to contact the source and get it fixed
> but they said they had no confidence that the resolution from symantec
> is adequate.
> here is their website
> http://www.qualys.com/products/overview/
--
Ed Wilts, Mounds View, MN, USA
mailto:ewilts at ewilts.org
|
