No reply
. 2008-03-13: Core notifies the vendor of the vulnerability and sends
the advisory draft. The advisory's publication is preliminary set to
April 14th, 2008.
. 2008-03-13: Vendor acknowledges notification.
. 2008-03-31: Core requests information concerning Microsoft's plans to
fix the vulnerability (no reply received).
. 2008-04-16: Core requests again information concerning Microsoft's
schedule to produce a fix. The advisory publication is rescheduled for
May 12th, 2008.
. 2008-04-25: Vendor informs that they are wrapping up the investigation
and threat model analysis and that fixes will not be included in the
22/04/2009 : Sending FRISK a slightly modified POC (same field, different
value) that extracts fine and still bypasses the engine. Ask
vendor to confirm that the new engine catches the POC.
No Reply
27/04/2009 : Resending previous mail asking to check whether the patch has
been effectively closed
No Reply
advisory. However to take that decision more information about the
vendor's analysis of the vulnerability and its plans for developing a
fix is required. In particular, Core requests a list of all affected
products and versions, and also some insight on the difficulties of
fixing this issue. In the meantime, the publication of this advisory is
rescheduled to February 15th, 2011. (No reply received.)
. 2011-01-31:
Since more than 3 weeks have passed since the last communication, Core
requests an update on this issue. In particular Core requests to receive
information respect to:
RealNetworks will not provide additional details until the release is
publicly available.
. 2009-05-05:
Core requests a more precise estimation for the release of fixes (no
reply received).
. 2009-05-29:
Core requests again RealNetworks an estimated date for the release of
fixes, and technical details about the issues. In the meantime, the
publication of advisory CORE-2009-0227 is rescheduled for July 15th (no
reseed(8) performs a unsecured HTTP request to random.org for its
bits, despite random.org offering HTTPS services.
The Ubuntu Security Team took no interest when contacted by email (no
reply); the point of contact listed in the man pages took no interest
when contacted by email (no reply); and a launcher bug report was not
acted upon (https://bugs.launchpad.net/ubuntu/+source/reseed/+bug/804594).
. 2008-07-21: Core sends (for the third time) the advisory draft as a
compressed file.
. 2008-07-21: Vendor confirms reception of the reports and states that
the problem has been identified.
. 2008-07-31: Core asks for updated information about the release of
fixed versions (no reply received).
. 2008-08-04: Core asks for updated information, and reschedules the
publication of the advisory to August 11th 2008 (no reply received).
. 2008-08-11: Core makes a phone call to the vendor, asking one more
time for a release date of fixed versions. Vendor informs that new
versions will be released during the week.
https doesn't help if your host entropy pool is poorly seeded.
[SSL/TLS needs entropy for authenticity/privacy.]
> The Ubuntu Security Team took no interest when contacted by email (no
> reply); the point of contact listed in the man pages took no interest
> when contacted by email (no reply); and a launcher bug report was not
> acted upon (https://bugs.launchpad.net/ubuntu/+source/reseed/+bug/804594).
you're surprised?
[you must be new around here!]
Timeline:
2011-05-13 vendor informed via mail
(no reply)
2011-06-19 vulnerability report published
Stefan Kanthak
2007/12/07 Immediate reply by and further discussion with James Lewis
2008/01/11 Technical confirmation by Robert Welz
2008/03/18 Status report by Robert Welz
2008/07/08 Offering for re-check of the patch by Robert Welz
2008/07/09 Undefined re-scheduling of the patch
2008/08/29 Last request for actual status (no reply)
2008/09/12 Public advisory
X. CREDITS
The vulnerabilities were discovered by Marc Ruef.
Response Team (SSRT).
. 2011-06-16:
Core requests an update on this issue, in particular Core asks the
vendor for a technical analysis of the bugs, a list of affected products
and versions, and the vendor's plan for providing a fix (no reply
received).
. 2011-06-23:
Core requests once more an update.
due to quality control processes this date cannot be guaranteed.
. 2012-05-04:
Core notifies that everything is ready for publication and requests the
vendor to confirm the release date and the list of affected platforms
(no reply received).
. 2012-05-07:
Core asks again for the status of the fix.
. 2012-05-08:
. 2011-08-08:
Vendor acknowledges Core's decision and support.
. 2011-10-07:
Core asks the vendor whether fixes for this vulnerability will be
effectively released on October 11 (no reply received).
. 2011-10-12:
The advisory CORE-2011-0106 is published as user release. The
CVE-2011-1508 identifier is assigned to this vulnerability, since the
CVE id provided by the vendor is associated with vulnerabilities in
technical information about the security vulnerability, that will be
forwarded to the PaintShop Pro team.
. 2010-01-16:
Core Security Technologies sends the advisory draft, containing a
technical description of the vulnerability (no reply received).
. 2010-01-27:
Core Security Technologies reminds Corel that its advisory is scheduled
for publication on February 1st, 2010, and that the advisory will be
published as "user release" if Corel doesn't reply with a plan for
2008/07/25 Identification of the vulnerability by Marc Ruef
2008/07/28 First information to D-Link via web form
2008/07/28 First reply by D-Link support via support@service.dlink.biz
(ticket id 1375981)
2008/07/29 Providing our config for further analysis
2008/08/06 Request for actual status (no reply)
2008/08/29 Another request for actual status
2008/08/29 Response could not verify the problem
2008/09/01 Detailed explanation of the exploitation
2008/09/01 Responder could still not understand the problem
2008/09/08 Public disclosure of the advisory
*Report Timeline*
. 2007-12-18: Core Security Technologies notifies the MPlayer team of
the vulnerability (no reply received).
. 2008-01-04: A new notification of the vulnerability was sent to the
MPlayer team (no reply received).
. 2008-01-18: A new notification of the vulnerability was sent to the
MPlayer team.
. 2008-01-18: The MPlayer team asked Core Security Technologies for
Response Team (SSRT).
. 2011-06-16:
Core requests an update on this issue, in particular Core asks the
vendor for a technical analysis of the bugs, a list of affected products
and versions, and the vendor's plan for providing a fix (no reply
received).
. 2011-06-23:
Core requests once more an update.
|
