| New User, Welcome! Login |
Next Page >>
vendors
> full disclosure and responsible full disclosure) can be good in
> appropriate
> situation. And I use that type of disclosure which is suitable for every
> particular case.
>
> Taking into account that 3 from 4 vendors answered me (except Microsoft)
> and
> Google had already non affected Chrome 4, and Mozilla and Opera promised
> to
> fix it (we'll see when and how they do it), then you can see that my
> approach works. And responsible full disclosure can force browser vendors
As I already wrote you and Adam earlier, every type of disclosure (including
full disclosure and responsible full disclosure) can be good in appropriate
situation. And I use that type of disclosure which is suitable for every
particular case.
Taking into account that 3 from 4 vendors answered me (except Microsoft) and
Google had already non affected Chrome 4, and Mozilla and Opera promised to
fix it (we'll see when and how they do it), then you can see that my
approach works. And responsible full disclosure can force browser vendors to
attend more at security of their software.
Patches take time. The do not occur over night. Furthermore it may
take a day for the vendor to respond to you.
This isn't about past issues, this is about this issue. A single day did
not pass between when you emailed these vendors and when you posted
here. Have you considered giving these vendors time to respond? I do
not find that 99% of them don't, rather I find that they do. Should you
have issues, would you consider emailing me first so I can introduce you
to contacts?
consumption. Which is working in many browsers, including their last
versions. So browser developers with their neglect to this problem make
possible attacks on the whole users' systems. It was one of leitmotifs of my
advisory.
> can I respectfully ask that you give vendors time to respond before
> posting?
This informing of vendors was an exclusion. During 2007-2009 I informed many
browser developers about many vulnerabilities (as DoS, as others) and gave
them a lot of time for fixing in many of that cases. But they almost always
A frequent example for unknown content-types is "image/bmp", which is created by
PHP's (< 5.3.0) getimagesize API function[4].
This is - the obvious XSS issue aside - used for phishing attachs[3].
As file -- especially image -- uploads are a standard feature in forum scripts,
we took the opportunity to survey popular forum script, whose vendors
claim to be
security conscious, regarding their handling of file uploads with regard to
handling mime sniffing.
We surveyed MyBB (1.4.5), SMF (1.1.18 / 2.0RC1), phpBB (2.0.23/3.0.4),
FluxBB (1.3),
I mentioned this issue to at least one guy @ PSIRT.
Nevertheless, it has to tell what it takes for a vendor to be aware. I
have had some experience in the past in which I notified an issue to
vendors (more than one issue, more than one vendor), and they showed no
concerns. One year later they ended up publishing advisories in response
to the same issues, but reported much later than when we had reported them.
> So you tell you discovered this issue as
> Thank you. Now if you could wait for patches before disclosing I'd be
> even happier.
Susan, you are welcome.
I would be happy to wait for patches of browser vendors, but as already
told you in details, it's not possible due to behavior of browser vendors.
All they mostly ignore such holes, all they don't count DoS as
vulnerabilities, they called them "stability issues" and so don't attend to
them seriously (and not fixing or fixing slowly). I don't respect such
statement as "stability issues" for DoS holes, and during 2008-2010 I worked
>> Thank you. Now if you could wait for patches before disclosing I'd be
>> even happier.
>
> Susan, you are welcome.
>
> I would be happy to wait for patches of browser vendors, but as already
> told you in details, it's not possible due to behavior of browser vendors.
> All they mostly ignore such holes, all they don't count DoS as
> vulnerabilities, they called them "stability issues" and so don't attend
> to
> them seriously (and not fixing or fixing slowly). I don't respect such
Versions: Cisco CSS 11500 - 08.20.1.01
Cisco ACE 4710 - Version A3(2.5) [build 3.0(0)A3(2.5)
(Other versions may be affected)
Severity: High (in specific configurations)
Author: George D. Gal <ggal (a) vsecurity . com>
Vendor Status: Cisco CSS vulnerability remains unpatched, workarounds
available
Cisco ACE workarounds available
CVE Candidate: CVE-2010-1575 - Certificate Spoofing Flaw
CVE-2010-1576 - HTTP Request Parsing Flaw
Reference: http://www.vsecurity.com/resources/advisory/20100702-1/
[VULNERABILITY INFORMATION]
Class: Hidden functionalities, command-injection, weak encryption
[AFFECTED PRODUCTS]
The vulnerabilities described in this advisory are related to a firmware shared
among several devices of different vendors. Unfortunately, we have not been
able to identify the actual firmware manufacturer: we asked the name of the
firmware manufacturer to the vendors, without any success (see section
"DISCLOSURE TIME-LINE" for details).
We confirm the products of the following vendors are affected:
18.05.2010 - informed developers: Mozilla, Microsoft, Google and Opera.
Found on the 16th
Blogged on the 17th
Told vendors on the 18th
Posted here on the 18th
Granted I can denial of service a browser just by loading up a horrible
add in or just using a browser, but as a customer of each of these
vendors, can I respectfully ask that you give vendors time to respond
2009-02-16: oCERT investigated for other potential affected projects
2009-02-20: maintainer provides updated patch
2009-02-20: reporter provides new patch fixing memory leak
2009-02-21: maintainer provides fixed beta version
2009-02-23: reporter confirms fixes
2009-02-24: contacted affected vendors providing combined security patch
and beta version, recommending the latter
2009-03-02: patch found to break functionality, contacted affected vendors
advising to use only beta version
2009-03-03: reporter provides additional patch based on feedback, patch
provided to vendors
Severity:
High (Remote Code Execution)
Vendor:
Multiple Vendors
Systems Affected:
Applications with FLAC Support
Overview:
> As part of the project "Security Assessment of the Internet Protocol
> version 6 (IPv6)" [CPNI-IPv6], we devised a number of techniques for
> circumventing the RA-Guard protection, which are described in the
> following sections of this document. These techniques, and the
> corresponding tools to assess their effectiveness, had so far been
> made available only to vendors, in the hopes that they could
> implement counter-measures before they were publicly disclosed.
> However, since there has been some public discussion about these
> issues, it was deemed as appropiate to publish the present document.
this surprised me for two things.
Vulnerable Products:
- HTC devices running Windows Mobile 6
- HTC devices running Windows Mobile 6.1
Non vulnerable products:
- HTC devices running Windows Mobile 5.0
- Other vendors’ Windows Mobile devices
References: http://www.seguridadmobile.com/windows-mobile/windows-mobile-security/HTC-Windows-Mobile-OBEX-FTP-Service-Directory-Traversal.html
Summary:
HTC devices running Windows Mobile 6 and Windows Mobile 6.1 are prone to a directory traversal vulnerability in the Bluetooth OBEX FTP Service. Exploiting this issue allows a remote authenticated attacker to list arbitrary directories, and write or read arbitrary files, via a ../ in a pathname. This can be leveraged for code execution by writing to a Startup folder.
________________________________________________________________________
Release mode: Tried hard to coordinate - gave up
Reference : [GSEC-TZO-26-2009] - One bug to rule them all
WWW : http://www.g-sec.lu/one-bug-to-rule-them-all.html
Vendors :
http://www.firefox.com
http://www.apple.com
http://www.opera.com
http://www.sony.com
http://www.nintendo.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[libc:fts_*():multiple vendors, Denial-of-service ]
Author: Maksymilian Arciemowicz
SecurityReason.com
Date:
- - Dis.: 21.10.2008
- - Pub.: 04.03.2009
I. BACKGROUND
Autonomy KeyView SDK is a commercial SDK that provides many file format
parsing libraries. It supports a large number of different document
formats, one of which is the Word Perfect Document (WPD) format. It is
used by several popular vendors for processing documents. For more
information, visit the URL below.
http://www.autonomy.com/
II. DESCRIPTION
the last couple of years, researchers were still working on security
problems in the core protocols.
The discovery of vulnerabilities in the TCP/IP protocol suite usually
led to reports being published by a number of CSIRTs (Computer Security
Incident Response Teams) and vendors, which helped to raise awareness
about the threats and the best mitigations known at the time the reports
were published. Unfortunately, this also led to the documentation of the
discovered protocol vulnerabilities being spread among a large number of
documents, which are sometimes difficult to identify.
Timeline:
2008-12-16: OpenSSL Security Team requests coordination aid from oCERT
2008-12-16: oCERT investigates packages affected by similar issues
2008-12-16: contacted affected vendors
2008-12-17: investigation expanded to DSA verification
2008-12-17: BIND, Lasso and ZXID added to affected packages
2008-12-18: contacted additional affected vendors
2009-01-05: status updates and patch dissemination to affected vendors
2009-01-05: confirmation from BIND of issue and fix
Timeline:
2008-08-05: initial report and proof of concepts received.
2008-08-18: affected software survey completed by oCERT.
2008-08-18: externalinput.php/Popoon author contacted.
2008-08-19: Horde author contacted.
2008-08-19: initial patches for Horde and Popoon supplied by vendors.
2008-08-19: reporter calls out additional possible vectors in externalinput.php.
2008-08-20: secondary fixed for externalinput.php supplied.
2008-08-20: attempted to contact CakePHP.
2008-09-04: final Horde patches supplied.
2008-09-04: potentially affected oCERT members and vendor-sec notified.
DESCRIPTION
InstallShield Update Agent connects to and communicates with centralized
Acresso (formerly Macrovision) FLEXnet Connect servers for updates and other
product information on a periodic basis. From the vendor's site:
FLEXnet Connect lets you electronically deliver applications, patches,
updates, and messages directly to your users' systems.
When connecting with this service, the client agent reports its product GUID,
implementation. Even in the last couple of years researchers were still
working on security problems in the core protocols.
The discovery of vulnerabilities in the TCP/IP protocols led to reports
being published by a number of CSIRTs (Computer Security Incident Response
Teams) and vendors, which helped to raise awareness about the threats as
well as the best mitigations known at the time the reports were published.
Much of the effort of the security community on the Internet protocols did
not result in official documents (RFCs) being issued by the IETF (Internet
Engineering Task Force) leading to a situation in which "known"
projects.
Simple Google hacking queries reveal that hundreds of thousands of
SWFs are vulnerable on the Internet, and a considerable percentage of
major Internet sites are affected. We are only reporting XSS
vulnerabilities that have been fixed by the vendors.
THE PROBLEM
Many web authoring tools that automatically generate SWFs insert
Attacks on clients’ browsers have always been the real threat for everyone.
And here vulnerabilities have been not only in the browser but also in plug-ins.
Bank-clients, business software, antivirus software – all of them use ActiveX (for IE)
for clients and here have been and are still many vulnerabilities.
Vendors make steps to defend us from it. Software vendors patch vulnerabilities and OS vendors
use new mechanisms to prevent attacks at all. But security researchers are trying to find way to bypass these mechanisms.
The new versions of browsers (Internet Explorer 8 and FireFox 3.5) use permanent DEP.
And the new versions of OS use the ASLR mechanism. All this makes the old methods of attacks impossible.
But on BlackHat DC 2010 the interesting way to bypass DEP and ASLR in browsers (not only)
and Just-In-Time compilers was presented. This method is called JIT-SPRAY. But here was no one public PoC until now.
English:
http://www.pcworld.com/businesscenter/article/189868/chuck_norris_botnet_karatechops_routers_hard.html
When I raised this issue before in 2007 on NANOG, some other vetted
mailing lists and on CircleID, the consensus was that the vendors will
not change their position on default settings unless "something
happens", I guess this is it, but I am not optimistic on seeing activity
from vendors on this now, either.
CircleID story 1:
>
> English:
> http://www.pcworld.com/businesscenter/article/189868/chuck_norris_botnet_karatechops_routers_hard.html
>
> When I raised this issue before in 2007 on NANOG, some other vetted mailing
> lists and on CircleID, the consensus was that the vendors will not change
> their position on default settings unless "something happens", I guess this
> is it, but I am not optimistic on seeing activity from vendors on this now,
> either.
>
> CircleID story 1:
Oct 31, 2007
I. BACKGROUND
MacroVision InstallShield is an installer solution utilized by many
software vendors in order to ensure that their products are delivered
and setup properly on the end-user systems. InstallSheild includes
support for an optional component called the "Update Service". This
service allows vendors to notify clients of product patches and
updates, and allow them to be easily installed. More information on
this product is available on the vendor's site at the following URL.
> At what point in time did you try contacting any of the vendors for
> these issues?
the vendors of the affected softwares have not been contacted.
> How do you propose a manufacturer fix an issue?
in the security field a public vulnerability is a dead vulnerability,
anyone who has found and released at least one security bug in his life
You appear to assume that because no one else has reported these vulns
publicly that no one else has discovered them. This is false logic; proof
is not satisfied by a lack of evidence to the contrary.
To be clear, I do appreciate researchers who spend their time seeking and
reporting security issues and sometimes "just bugz" in vendor software -
it's this sort of independent scrutiny that keeps the vendors honest and on
their toes.
Where I take issue is with the false notion that public reporting leads to
anything more than an increased threat potential for the customers
Next Page>>
|
|
|
