Re: SYM06-013 Symantec On-Demand Protection Encrypted Data Exposure
Hello,
> This Symantec posting contains minimal security information. In December
> 2000[1] @stake modified their Bugtraq postings to include a small amount
> of security information and a link back to the @stake website where the
> full advisory resided. The intention was to have a bit more control over
> the way people viewed the advisories. They would be viewed on the @stake
> website only and not serve as content for for-profit advertising supported
> websites. The advisory could also be updated if there were errors or
> updates and it would serve as the canonical reference.
>
> Elias Levy, the Bugtraq moderator at the time, rejected the posting on the
> grounds that it contained minimal security information. His reasoning was
> that forcing people to go to an additional website was inconvenient and
> that if the advisory website ever went away the original advisory would be
> lost. He had a good point and @stake changed back to the old format.
>
> One of the ironies of the security world is Symantec purchased
> SecurityFocus and then later @stake. After purchasing @stake, Symantec
> removed the @stake advisory archive, thus bringing Elias' fear to reality.
>
> Elias' reasoning still holds true today. Companies come and go, are
> acquired or change course. Symantec should post its full advisories to
> the list and so should everyone else.
>
> -Chris
>
> 1. Bugtraq: Administrivia & AOL IM Advisory,
> http://seclists.org/bugtraq/2000/Dec/0197.html
I had initially addressed a personal response to Chris Wysopal
describing the policy with regards to this subject, but I see that
this has made the rounds so I feel that it is necessary to respond to
the list in an effort to clear things up.
It is normally our policy to restrict postings that contain very
little content and refer readers to an external site to get more
information. I do agree with the original sentiment that the list
should be the canonical source of information about the
vulnerabilities that are posted to it. Asides from the SecurityFocus
vulnerability database, there are a number of other entities which use
the list as a common point of reference (such as Mitre's CVE dictionary and the
OSVDB, among others), so it is my intent that Bugtraq can continue to serve as
an
authoritative archive for vulnerability reports. This is why on many
occasions I have rejected posts that contain too little information or
where most of the information is hosted on external site. In enacting
this type of policy, there is always the risk that such posts will not
be resent, or that they will be delayed -- and this is a risk I have
taken in numerous instances to uphold the policy that Bugtraq posts
should serve as a canonical and complete reference for a reported
vulnerability -- of course this is not always the case as many posters
do not continue to post updates after the initial report, but to the
extent that I can control this, I will endeavor to do so.
This being said, there are some occasions where exceptions have been
made. Notably, if I feel that a vulnerability was important enough or
high priority enough to go to the list immediately. Though this
example predates the list handover, this was the case with the initial
report of the WMF SetAbortProc vulnerability in December of 2005,
which was a one-liner pointing towards an exploit that compromised a
fully patched Windows box.
There is also the exception that was made in regards to Symantec
advisories. Symantec product security used to post entire advisories
to the list, but at some point a few months ago, their advisory
publishing processes had changed. The side effect of this change in
process was that the full advisories that were being sent to the list
had broken signatures. So we tried various methods to fix the process
so that the advisories would arrive with their signatures intact.
Eventually, we opted for shorter advisories since this was less error prone.
I rationalized this exception to myself by considering that this
information would be hosted on the Symantec product security
advisories page for the long term and did not really feel that there
was an imminent threat to the information disappearing any time soon.
However, Chris has made some good points, and so have requested that
the Symantec advisories contain more content, and it has been agreed
that Symantec will not be excepted from this policy in the future.
In short, I do believe that the concerns expressed by Chris Wysopal are
legitimate,
and there is always the risk of "information decay" as sites
disappear. This is actually a real issue that we have experienced in
maintaining the SecurityFocus vulnerability database and I personally
sympathize with anybody who is tasked with maintaining a large amount
of historical data that depends on external sources that are constantly
disappearing or moving around. It is unfortunate what happened to the
@stake advisory archive, and also that many other forums have
disappeared over the years.
--
Dave McKinney
Symantec
keyID: BF919DD7
key fingerprint = 494D 6B7D 4611 7A7A 5DBB 3B29 4D89 3A70 BF91 9DD7