[VIM] disclosure timeline (Core: Wonderware)

Wed May 7 16:07:33 UTC 2008

http://seclists.org/fulldisclosure/2008/May/0095.html

*Report Timeline*

. 2008-01-30: Initial contact email sent by to Wonderware setting the
estimated publication date of the advisory to February 25th.
. 2008-01-30: Contact email re-sent to Wonderware asking for a software
security contact for Wonderware InTouch.
. 2008-02-06: New email sent to Wonderware asking for a response and for
a software security contact for Wonderware InTouch.
. 2008-02-28: Core makes direct phone calls to Wonderware headquarters
informing of the previous emails and requesting acknowledgement of the
notification of a security vulnerability.
. 2008-02-28: As requested during the phone call, Core re-sends the
original notification mail, stating that an advisory draft describing
the vulnerability is available since January 30th. The publication of
the advisory is re-scheduled to March 24th.
. 2008-02-28: Vendor acknowledges the email notification.
. 2008-02-28: Core sends the advisory draft to Wonderware support team.
. 2008-02-29: Vendor acknowledges reception of the report and states
that it understands the seriousness of the problem and that its
development team will look into it.
. 2008-02-29: Vendor asks for a copy of the proof of concept code used
to demonstrate the vulnerability.
. 2008-03-03: Core sends proof-of-concept code written in Python.
. 2008-03-05: Vendor asks for compiler tools required to use the PoC code.
. 2008-03-05: Core sends a link to http://www.python.org where a Python
interpreter can be downloaded.
. 2008-03-10: Vendor requests more information about the network and the
firewall settings used during the tests and inquires about conformance
(or lack thereof) of the tested network with the vendor's security
policies and recommendations.
. 2008-03-10: Vendor asks for details about how the advisory will be
published.
. 2008-03-12: Core responds that the workstation running the vulnerable
service had no firewall activated in the tests, but since the Wonderware
SuiteLink Service allows incoming connections it is assumed that the
corresponding port should be allowed to receive inbound session
establishment packets. Core offers the vendor the opportunity to include
additional information in the "vendor information" section of the
advisory. Core explains that the advisory will be published on Core's
website and sent to security mailing lists. Core also reminds the vendor
that the publication date of the advisory has been moved from February
25th to March 24th, and explains that it is willing to discuss a new
publication date on the basis of having concrete plans, with a specific
date for the fix release.
. 2008-03-21: Vendor indicates that it will be unable to commit to
releasing fixes by March 24th and requests publication of the advisory
to be delayed to create a fix for vulnerable customers. The development
team is investigating how long it will take to make such a fix
available. The vendor indicates that the previous questions about
firewall setup referred to the vendor's recommended practices to secure
networks on which their systems run using firewalls and IPsec.
. 2008-03-21: Vendor indicates that it is issuing a Tech Alert to its
customers to address the issue. Details about the vulnerability have
been minimized in the Tech Alert. The vendor expresses concern about the
level of detail included in Core's advisory and requests that those
details be removed from the advisory because they give more detail than
what is needed to make people aware of the issue, and may lend itself to
use by people who might want to exploit it. Early estimates put the
delivery time for a fix at approximately three months, and the estimate
is not final. Vendor asks Core to delay any publication until it is able
to have a software fix ready.
. 2008-03-21: Core asks if the three-month estimate should be assumed to
have begun since the vendor's initial acknowledgement of Core's
notification -- which puts the estimated date for the release of a fix
at the end of May -- or since the date of the last email received (fix
released at the end of June). Core indicates that as of today it still
has no confirmation from the vendor that the vulnerability was
replicated and identified, and that the fix is already under development
or testing, and that is the information needed to re-schedule the
publication date. Core is expecting to receive that information from the
vendor, but in the meantime publication of the advisory is re-scheduled
to March 31st 2008. With regards to the questions and requests about the
contents of the security advisory, Core indicates that Core's technical
publications are aimed at providing legitimate security practitioners
worldwide with the technical details necessary to understand the nature
of the security issues reported; so they are able to devise, by their
own judgment, the risk mitigation approach that fits them the best. For
that purpose, Core believes that it is fundamental that they have
precise and accurate technical details about security issues -- as
Wonderware itself has demonstrated with the request for further
technical details and proof-of-concept code -- and that the whole
reporting and disclosure process is transparent for scrutiny of all
interested parties.
. 2008-03-21: Vendor acknowledges Core's email and provides a copy of
the issued Technical Alert 106 and indicates that will provide more
information by March 25th 2008.
. 2008-03-26: Vendor confirms to have replicated the issue reported and
indicated that the Tech Alert 106 sent to customers confirms and
recognizes the issue. The Tech Alert also points out what measures can
be taken to mitigate risk. A project has been charter and is in progress
to fix this issue and properly QA the fix. With regard to the contents
of Core's report, it says that stating that a Denial of Service of
SuiteLink communication can be created from a remote node sends a
corrupted data packet seems to be sufficient to make people aware. The
vendor says that is having trouble understanding what the value is in
providing specific detail as to what technical issue is happening and
asks for clarification to understand how this information would benefit
organizations. The vendor acknowledges that the proof of concept code
did help to replicate the issue and that without it, it would have
needed more time to identify it from the report alone. The concern is
that the details provided in the report may give a hacker a specific
direction to look for the vulnerability. Finally, the vendor indicates
that will have a better estimation for the rlease date of a fix by
Friday March 28th, 2008.
. 2008-03-27: Core acknowledges the vendor's email and indicates that is
looking forward to having the new estimate by Friday.
. 2008-03-28: Vendor informs that it has brought the estimated release
date in to May 2nd. If things go well during QA, they may be able to
bring that date in sooner and vendor requests that Core postpone
publication until that time.
. 2008-03-28: Core re-schedules publication of the advisory to May 2nd
2008 and says that it considers this date final unless the vendor
indicates any deviation from the current estimate with at least a week
in advance of the publication date, in which case Core would re-evaluate
postponing publication up to 5 working days. With regard to the previous
inquiry about the advisory's content, Core states that the purpose of
publishing security advisories and the rationale used to define their
content is simple and hopefully, once explained, both reasonable and
understandable. Core publishes advisories not only to make users aware
of the existence of a given vulnerability but also to facilitate its
mitigation by either official or any other means that the security
community and/or the vulnerable user population may devise. In order to
do so, Core has learned over the course of 13 years working in this
particular field that it is fundamental to provide precise and accurate
technical information about problems. It is that information that can
help other security practitioners to determine how to prevent
exploitation, detect attacks or to verify that a fix or workaround is
actually functioning properly. Thus, Core believes that it is necessary
not only to indicate the mere existence of the bug, but also to explain
how to uniquely identify it in the vulnerable software (to avoid
confusion with all other known bugs or to differentiate it from others
that may be discovered in the future). It is also important to determine
how the vulnerability could be used by potential attackers so that
proper detection mechanisms can be built, for example firewall rules, or
IDS and antivirus signatures. While Core recognizes that this may
provide some additional data to would-be attackers, clearly it also
provides preciously needed information to the defenders thus, leveling a
field on which Core believes the attackers are initially at advantage.
. 2008-04-01: Vendor acknowledges previous email and indicates that it
will provide a new update as soon as is available.
. 2008-04-28: Vendor informs Core that a fix for the vulnerability in
SuiteLink has been released.
. 2008-04-28: Core acknowledges previous emails and requests an official
vendor statement for the security advisory and more details about the
vulnerable packages and versions.
. 2008-04-29: Vendor provides an official statement and indicates that
versions of SuiteLink prior to 2.0 patch 01 are vulnerable. Multiple
products use SuiteLink.
. 2008-04-30: The advisory is ready for release, but the publication
date is re-scheduled to May 5th because May 1st is a public holiday in
many countries (International Workers' Day) and Core does not usually
publish advisories on Fridays (to avoid IT work on weekends).
. 2008-05-05: CORE-2008-0129 advisory is published.