On Tue, 21 Jul 2009, Michal Zalewski wrote:
> The code created an oversized list, which does not seem to be that far
> from creating an overly nested DOM tree, or drawing an oversized CANVAS
> shape, or any other creating-too-many-things-for-the-renderer-to-handle
> attacks... but really, I'm not
On Tue, 21 Jul 2009, Thierry Zoller wrote:
> Yeah, security is too complex. Dude, the fix was to LIMIT the the
> number of elements. This is not rocket science.
I believe Michal and I are having the conversation in a larger context.
What you found is valid on its own merit and got addressed, wh
On Sun, 27 Jul 2008, Georgi Guninski wrote:
> this is the lamest way to social engineer 0days i have ever seen!
Nice to hear from you, Georgi.
Of course, people don't have to go through MITRE to obtain CVE numbers,
and as I alluded to previously, we can (and do) assign CVEs without
knowing spec
On Sun, 27 Jul 2008, Georgi Guninski wrote:
> this is the lamest way to social engineer 0days i have ever seen!
Just so people won't have a rational reason to believe I was dodging
something: one thing I forget to mention in my original response is that
the CVE team does not share pre-disclosure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CVE requests can be sent to [EMAIL PROTECTED] or to me directly. My PGP
key is below, or accessible from the MIT public key server.
Alternately, you can request them from Candidate Numbering Authorities
(CNAs) which include the security teams at Red
On Fri, 25 Jul 2008, [UTF-8] Jan Miná�^Y wrote:
> > The commands do not have to be written there between (1) and (2), they
> > can be in the file long before the ./configure was started -- just
> > because the script does care whether it can write to the file at all.
> > So unlike stated in the a
On Tue, 27 May 2008, security curmudgeon wrote:
> No mention of CVE-2008-1035 in the [CORE] advisory other than the header
> CVE name reference. BID seems to have split the three vulnerabilities,
> but given two of them the same CVE. CVE does not have descriptions open
> yet.
The descriptions ar
On Tue, 21 Aug 2007, 3APA3A wrote:
> 6. Ivan Nl (http://uNkn0wn.eu) reports vulnerabilities in
> Linkliste 1.2, Butterfly online vistors counter 1.08, mcLinksCounter
> 1.2, My_REFERER 1.08.
>
> Original messages in English are available from
> http://securityvulns.com/sour
On Fri, 17 Aug 2007, Pranay Kanwar wrote:
> Frankly i now feel, that its not SecNiche's fault entirely, it has got a
> lot of encouragement from its past invalid and absurd claims.
>
> Such as
>
> _JWIG Context Dependent Template Calling Denial of Service Vulnerability._
> http://nvd.nist.gov/nvd
On Wed, 15 Aug 2007, security curmudgeon wrote:
> OSVDB did not begin agressively tracking and cataloging myth/fake
> vulnerabilities until earlier this year.
CVE began a similar practice by using a "** DISPUTED **" or "** REJECT **"
string in the descriptions.
> OSVDB will add legitimate vulne
[sorry for any duplication]
Regarding the JWIG issue: this seems more like a description of a
*class* of vulnerabilities that could apply to an application written
in JWIG, if the application allows an attacker to influence the
contents of a template (which seems quite possible). CVE does not
ha
Regarding the JWIG issue: this seems more like a description of a
*class* of vulnerabilities that could apply to an application written
in JWIG, if the application allows an attacker to influence the
contents of a template (which seems quite possible). CVE does not
handle vulnerability classes (t
Stefano Di Paola said:
>1. I search on google for import_request_variables advisories
>(nothing found)
>2. I search on php.net in changeLog for fixes (nothing found).
I can see why you weren't able to find anything. However, there have
been a number of disclosures that are probably related - bu
Not to reduce the high signal-to-noise ratio on this thread, but I
suspect there are lots of "eval injection" vulnerabilities in
Javascript-heavy applications, but they don't seem to be reported to
the usual places, or maybe people just call them XSS. Perl, PHP, and
other interpreted languages ha
Some interesting work.
For those who haven't made the connection yet - concurrency issues
probably go far beyond just web browsers. It's a safe bet that *any*
software that's multi-threaded, multi-process, event-based, or
asynchronous could have these sorts of issues. Traditional data
manipulat
>There was discussion last week in the Full-Disclosure about XSS
>vulnerabilities in reply to XSS vulns in PayPal and Gadi Evron
>suggested creation of a separate mailing list for just XSS
>vulnerabilities.
This is definitely a growing gap in our current knowledge. I don't
think it's being track
--
Dynamic Evaluation Vulnerabilities in PHP applications
--
Following is a brief introduction to a growing class of serious
vulnerabilities in PHP applications. They can allow execution of
ar
In a post-disclosure analysis [1] of a security issue announced by
rgod [2], Siegfried observed that the reported XSS actually originated
from a file inclusion vulnerability, in which the XSS was reflected
back from an error message when the file inclusion failed:
>About the xss, it is an xss in
Mark Cox of Red Hat has published a blog entry that identifies how
they learned about vulnerabilities in their products:
http://www.awe.com/mark/blog/security/200603211056.html
Note his disclaimer that "we only list the first place we found out
about an issue, and for already-public issues thi
In a forum well-known for its unpredictable noise-to-signal ratio, not
to mention the occasional ad hominem attack, it was rather surprising
not to see a single response to this inquiry on Full-Disclosure.
I have received 10-15 diverse, private responses and will do my best
to summarize, in about
This is a series of open questions to people who consider themselves
to be vulnerability researchers. Hopefully this will open a number of
fruitful public discussions.
1) What is the state of vulnerability research?
2) What have researchers accomplished so far?
3) What are the greatest challen
In the "Internet Explorer drag&drop 0day" thread, Gadi Evron said:
>In my opinion, this comes to prove 0days are USUALLY a "myth" (WMF
>being a good example of a real 0day),
It's not necessarily that 0-days are a myth, it's that people have
been using the term "0-day" to mean two separate things
Florian Weimer said:
>> Unless things have changed since I went through the process, the
>> authority involved does not extend to Debian in general but only to
>> specific individuals.
>
>Certainly, at Debian, only certain individuals issue CVEs. I can't
>tell if this is Debian's choice, or a res
David Litchfield recently provided a detailed description of a number
of vulnerabilities in Oracle PLSQL Gateway. He showed how, each time
the blacklist defense was modified, he was able to find a new variant
that worked around the more restrictive blacklist.
This type of pattern has emerged tim
On Sat, 7 Jan 2006, Georgi Guninski wrote:
> - The Board has agreed that CNAs should not reserve candidates for
> people who do not practice responsible disclosure (candidates would
> be assigned *after* publication). I hope that this document, or a
> later version, will become part of the
done with it.
On Fri, 6 Jan 2006, Georgi Guninski wrote:
> On Fri, Jan 06, 2006 at 02:53:56PM -0500, Steven M. Christey wrote:
> > According to the definitions proposed by Brian Martin of OSVDB, CVE is in
> > fact a database - HOWEVER it is a highly specialized one intended for
On Fri, 6 Jan 2006, Georgi Guninski wrote:
> hahaha:
> http://cve.mitre.org/about/
> A Dictionary, NOT a Database
> (note the CAPS)
> so which way is it "NOT" or "A database"?
Hi Georgi, I've missed you.
According to the definitions proposed by Brian Martin of OSVDB, CVE is in
fact a database -
Open Letter on the Interpretation of "Vulnerability Statistics"
---
Author: Steve Christey, CVE Editor
Date: January 4, 2006
All,
As the new year begins, there will be many temptations to generate,
comment, or report on vulnerability s
I was just browsing the Red Hat bug report for the mod_imap XSS issue
(CVE-2005-3352).
In it, they included a disclosure timeline (possibly from Apache, this
is not clear).
I've only seen a handful of disclosure timelines by a vendor. But in
my opinion, it should be more widely adopted by those
On Sat, 3 Dec 2005, Chris Umphress wrote:
> Almost all of the statements refer to a number of programming
> languages if thought is not put into the program. Security requires
> thought.
Agreed, but every once in a while we run across things that people don't
usually think about.
> >The pos
It was mentioned this week, but not in my paper, so it didn't hurt for it
to be mentioned again :)
- Steve
On Sun, 4 Dec 2005, Stan Bubrouski wrote:
> On 12/3/05, Michael J. Pomraning <[EMAIL PROTECTED]> wrote:
>
> > For Perl projects, I'd also nominate syslog(), from the standard Sys::Syslog
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Format String Vulnerabilities in Perl Programs
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Author: Steve Christey
Date: December 2, 2005
**
Table
In a post "SEC-CONSULT-SA-20051021-0: Yahoo/MSIE XSS", Bernhard
Mueller said:
>SEC-Consult believes that input-validation thru blacklists can just be
>a temporary solution to problems like this. From our point of view
>there are many other applications vulnerable to this special type of
>problem
On Tue, 23 Aug 2005, KF (lists) wrote:
> That is a patch for my vulnerability from 2 months ago...
> http://www.digitalmunition.com/DMA%5B2005-0614a%5D.txt
> http://www.digitalmunition.com/virobot_ex.pl
>
> Hopefully you didn't miss the advisory. =]
It's already listed in CAN-2005-2041, but poin
>The vulnerability is caused due to unsafe extraction of compressed
>archives (e.g. ACE, ARJ, CAB, LZH, RAR, TAR and ZIP) into a temporary
>directory before scanning. This can be exploited to write files into
>arbitrary directories when scanning a malicious archive containing
>files that have "/..
security curmudgeon said:
>Consider that we already have government coordination for
>vulnerabilities. In fact, did you know we have it half a dozen times
>over?
>
>...
>
>Little overlap? You bet there is.
The CERT, CVE, and ICAT efforts are complementary.
CERT deals with large-scale disclosure
Regarding a particular vulnerability database, Xavier Beaudouin
<[EMAIL PROTECTED]> said:
>They push advisory without testing and respect the usual way to inform
>developper as it should.
(name omitted simply because it could have been about any vuln
database.)
No doubt a lot of what I'm about
37 matches
Mail list logo
