| New User, Welcome! Login |
Next Page >>
holes
> Let's take one for example. Did you email secure@microsoft.com? I have
> before and 100% of the time they respond.
Yes, I did. I emailed Microsoft, like other browser vendors. I knew their
emails, because I wrote to all of these four vendors a lot of times during
2007-2010, and all of them answered many times (who more, who less). But as
I already wrote, in 99% cases they ignored to fix DoS holes (even if they
answered and told, that they agreed that it was DoS and they'd think about
fixing it).
For example Microsoft one time even answered me twice (with thanks), when I
>> Let's take one for example. Did you email secure@microsoft.com? I have
>> before and 100% of the time they respond.
>
> Yes, I did. I emailed Microsoft, like other browser vendors. I knew their
> emails, because I wrote to all of these four vendors a lot of times during
> 2007-2010, and all of them answered many times (who more, who less). But
> as
> I already wrote, in 99% cases they ignored to fix DoS holes (even if they
> answered and told, that they agreed that it was DoS and they'd think about
> fixing it).
>
mailing list. So Nant and every reader of the list must take it into
account (and send letters to my email, if they want to contact me).
And this is that example of letter from developer, which I mentioned last
week at the list. Which clearly shows, that web developers ignore advisory
about holes in CaptchaSecurityImages.php itself, and only draw attention on
advisories about their specific web applications. So in my answer I'll draw
attention to this aspect of Nant's letter.
> Some facts for those reading:
> It's because earlier I already disclosed details (at my site and to
> security
> lists) of vulnerabilities in CaptchaSecurityImages (a captcha script
> which
> is used in this CMS, as in many other CMS and web applications). So there
> were no reasons to not write details about these holes in advisory at my
> site, because all information is already public. So for all of these
> vulnerable webapps I used responsible full disclosure approach.
>
>> I don't even know what Dunia soccer is but how about you give vendors a
>> chance to make good?
(http://websecurity.com.ua/articles/security_researches_and_legislation/eng/).
It's because earlier I already disclosed details (at my site and to security
lists) of vulnerabilities in CaptchaSecurityImages (a captcha script which
is used in this CMS, as in many other CMS and web applications). So there
were no reasons to not write details about these holes in advisory at my
site, because all information is already public. So for all of these
vulnerable webapps I used responsible full disclosure approach.
> I don't even know what Dunia soccer is but how about you give vendors a
> chance to make good?
Hello Sebastien!
You can confirm it by yourself. Just find a site on XAMPP (Google can help
you with it) and check the holes using PoCs which I provided.
> and what target of xampp is it ? win32 ? linux ?
As far as I remember last year when I found all these vulnerabilities in
XAMPP, it was XAMPP on Windows servers on all those sites where I found
these holes.
Hello Hans!
First, it's not a site specific hole, it's browser specific. So issue in
browser and it'll be working at any site. And I used universal PoC (suitable
for most cases). For online testing and especially for attacking purposes
you can use any working web site (e.g. google.com).
http://www.google.com/webhp?--%3E%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
The idea of putting XSS code to the parameter (i.e. after '?') is to avoid
> application installed that FireFox knows exists on the target operating
> system. :-)
It's quite possible, because I didn't check this Cross-Application DoS in
Fifefox (due to that my FF 3.0.13 is not affected to this attack). If there
is such hole, it can be possible to make similar attack against any other
installed application which have their URI handler registered in the system.
And not only Firefox (and the system) must know about it, but the attacker
also must know about it :-).
My idea was to made blocking DoS attack on Chrome (first exploit was
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
hard to change vendors' mind on this issue, but they still ignore it.
>
> 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
Hello Thierry!
> Your saying above that this attack works if "Initialise and script
> ActiveX control not marked as safe" is ENABLED.
This Saved XSS hole works even with this option disabled (i.e. with default
settings). But when we want to use ActiveX in our code (e.g. for Code
Execution attack), than such problem occurs. It's bug in IE (when there is
preceding comment tag), which I found when researching possibility of making
CE via XSS in IE. So I found the workaround for this bug - to set up this
option to Enabled or Prompt (for Local intranet).
About your "bug to rule them all" I can tell, that it's interesting
vulnerability and interesting research itself. I have found DoS
vulnerabilities in multiple browsers many time, but I never tested in such
many browsers and systems. So you made a large research (with help of those
people who helped you with testing in different systems) - this DoS hole
exists (or existed) in so many systems: different desktop browsers, email
clients, browsers for mobile devices, game devices and possible other
devices with support of JavaScript.
Maybe some of DoS hole found by me can also work on multiple platforms, but
> Granted I can denial of service a browser just by loading up a horrible
> add in or just using a browser
DoS of the browser is already bad thing. And there are many risks for users
from DoS holes in browsers, which I wrote about in 2008 in my articles
Dangers of DoS attacks on browsers and Dangers of resources consumption DoS
attacks. But mostly browser developers ignore to fix these issues.
But in this case it's not only attack on browsers, but on the whole user's
computer - because it's blocking of whole computer and full resource
>> Granted I can denial of service a browser just by loading up a horrible
>> add in or just using a browser
>
> DoS of the browser is already bad thing. And there are many risks for
> users
> from DoS holes in browsers, which I wrote about in 2008 in my articles
> Dangers of DoS attacks on browsers and Dangers of resources
> consumption DoS
> attacks. But mostly browser developers ignore to fix these issues.
>
> But in this case it's not only attack on browsers, but on the whole
On 23.10.2009 21:16, Pavel Machek wrote:
> Hi!
>
> This is forward from lkml, so no, I did not invent this
> hole. Unfortunately, I do not think lkml sees this as a security hole,
> so...
>
> Jamie Lokier said:
>>>> a) the current permission model under /proc/PID/fd has a security
>>>> hole (which Jamie is worried about)
1. General Information
e107 is a free content management system (CMS) written in PHP language
and is available at http://e107.org/news.php . In October 2009, Bkis
Security discovered a number of XSS and Blind SQL Injection
vulnerabilities on this system. Taking advantage of these holes, hackers
can insert arbitrary malicious codes onto users' browsers, then steal
private information or carry out requests to the website to gain
complete control of the website's database.
Details: http://blog.bkis.com/e107-multiple-vulnerabilities/
On Fri, Oct 23, 2009 at 11:57:58PM +0400, Dan Yefimov wrote:
> That can hardly be called a real security hole, since the behaviour
> described above is expected, and is as it was conceived by design.
Lots of security holes can fall into that category! The code matches
its design, and works as expected... it's just that the author had no
idea what he was getting himself into. =8^)
> If the file owner in fact allows writing to it, why should Linux
> prevent that from happening?
Hi!
This is forward from lkml, so no, I did not invent this
hole. Unfortunately, I do not think lkml sees this as a security hole,
so...
Jamie Lokier said:
> > > a) the current permission model under /proc/PID/fd has a security
> > > hole (which Jamie is worried about)
> >
(I have czech version of g1; you can't simply downgrade it to
rc8/rc29, as it is prevented by CID check).
Yes, I want to get root on my shiny new t-mobile g1. I tried
exploiting dnotify hole that was fixed in 2.6.25.1... only to find out
that CONFIG_DNOTIFY is off in g1 kernel. So I made sure that
CONFIG_INOTIFY is on, and tried exploiting
6ee5a399d6a92a52646836a6e10faf255c16393e. It triggers very
reliably... with SLAB debugging on. With debugging off, it took 2+
hours to reproduce on PC. Given that I'd have to manually
About your message concerning crash in Firefox 3.0.6
(http://securityvulns.ru/Vdocument307.html). Which has similar DoS
vulnerability as Nokia N95-8 browser.
Some time ago I read your message and also checked Firefox 3.0.6 and
confirmed the crash in it. What I can tell you about this hole.
In the beginning of September 2008 I already wrote about such DoS
vulnerability in Mozilla Firefox (http://websecurity.com.ua/2421/). Which
leads to that after running of the exploit the browser begun taking 100% of
CPU resources and freezes.
As with all security-based releases, we recommend that all customers
upgrade as soon as possible in order to prevent any potential damage
resulting from the flaw being exploited.
Credits: The original finder of the security hole. (Jelsoft?)
Researched & Disclosed by: MaXe (InterN0T.net)
Official Information:
http://www.vbulletin.com/forum/showthread.php?t=319572
Timeline:
17.02.2009 - found the vulnerabilities.
23.10.2009 - announced at my site.
17.02.2009 - informed developers. Because these vulnerabilities were
mentioned in comments at my site during discussion of previous holes in
Abton, then developers should read about them already at 17.02.2009 and
should fixed them along with previous ones, but they didn't do it, so after
the official announcement of these holes, I additionally informed them.
19.02.2010 - disclosed at my site.
-----------------------------
in 2009 (as it clear from Timeline which I made for all advisories). Only
now I sent them to Bugtraq. And that time XAMPP 1.7.1 was the latest
version.
Besides, in 2009 developer of XAMPP answered me (with thanks) only at one of
seven letters and he didn't mention about fixing any of holes which I found.
So there is possibility that all or some of these holes are still not fixed.
I'm rarely sending advisories about vulnerabilities to Bugtraq. During
2007-2010 I sent only small amount of my advisories to Bugtraq. From the end
of 2006 I was sending all holes (http://securityvulns.ru/source15611.html)
29.06.2009 - found vulnerability.
11.02.2010 - announced at my site.
13.02.2010 - informed admin of web site where I found the vulnerability.
15.02.2010 - informed developers of DataLife Engine (at first I thought that
hole existed in DLE, and admin of vulnerable web site didn't answer me and
didn't fix the hole, but DLE developers said that hole is not in their
engine and they didn't know what the module it is).
19.02.2010 - informed developers of the module (after I found that it's
Referer module).
23.04.2010 - disclosed at my site.
Thanks for information.
It's interesting why your Firefox 3.5.2 is vulnerable, because on my
computer only Chrome was vulnerable, and not Firefox 3.0.13 and other
browsers (Mozilla, IE6 and Opera). Yes, I have Chrome installed on the same
system and it does not affect other browsers (not in case of this DoS hole,
not in case of other holes which I found).
Besides, which exploit works in Firefox 3.5.2 in your case? Maybe it's hole
in Firefox 3.5.x. Then it'll be better for you to check it on the system
with Firefox, but without Chrome. In case if it's Cross-Application DoS
Explorer. Which I already disclosed at my site in 2008 (at 29.09.2008). But
recently I made new tests concerning this vulnerability, so I decided to
remind you about it.
I know this vulnerability for a long time - it's well-known DoS in IE. It
works in IE6 and after release of IE7 I hoped that Microsoft fixed this hole
in seventh version of the browser. But as I tested at 29.09.2008, IE7 was
also vulnerable to this attack. And as I tested recently, IE8 is also
vulnerable to this attack.
Also I informed Microsoft at 01.10.2008 about it, but they ignored and
Thanks for information.
It's interesting why your Firefox 3.5.2 is vulnerable, because on my
computer only Chrome was vulnerable, and not Firefox 3.0.13 and other
browsers (Mozilla, IE6 and Opera). Yes, I have Chrome installed on the same
system and it does not affect other browsers (not in case of this DoS hole,
not in case of other holes which I found).
Besides, which exploit works in Firefox 3.5.2 in your case? Maybe it's hole
in Firefox 3.5.x. Then it'll be better for you to check it on the system
with Firefox, but without Chrome. In case if it's Cross-Application DoS
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.
Your position is similar to Mozilla's position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didn't send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that it's Google's official position about this issue.
I understand your and Mozilla's position, but I don't agree with you. And I
----------
Details:
----------
This hole is similar to Cross-Site Scripting vulnerability in Internet
Explorer (http://websecurity.com.ua/1241/) - CVE-2007-4478
(http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-4478). Which I
found in August 2007 and informed Microsoft, and they ignored it and
didn't
fix it in IE6, and they didn't fixed it in IE7 (and also in IE6) after
> "even i see no reason for this. these ip addresses arent valid
> anymore. it seems that chris implemented this for a customer. i
> removed it now" (they are still in the default install image)
> "nvram unset ral
> nvram commit "
> "there is no security hole. both ip's are not active anymore and
> obsolete since a long time. "
> "i will lock this thread now. a new release is scheduled soon (within
> this or next week), but you cannot force me to release buggy code
> based on the current internal tree.thats my last statement on this
> topic" (Posted: Tue Aug 19, 2008 10:57 pm)
Next Page>>
|
|
|
