J'ai fait une réponse rapide en demandant des précisions sur les deux autres failles (lecteur audio et vidéo) et lui ai indiqué qu'on avait aucune trace de son mail du 14 janvier.
On verra bien… 2013/4/12 Dotclear (contact) <[email protected]> > La suite… > > ---------- Forwarded message ---------- > From: MustLive <[email protected]> > Date: 2013/4/11 > Subject: Re: XSS and CS vulnerabilities in Dotclear > To: "Dotclear (contact)" <[email protected]> > > > ** > *Hi Franck!* > > So what about those things, which I've wrote you about yesterday? > > Are you planning to fix other holes (in two other swf-files), are you > planning to fix flash-file of SWFUpload or will just use your "non-direct > access to swf-files" approach (to prevent abuse of vulnerable swf-files > instead of fixing them), and will you give me any URL of web site on > Dotclear 2.5, so I can check it? > > Best wishes & regards, > Eugene Dokukin aka MustLive > Administrator of Websecurity web site > http://websecurity.com.ua > > ----- Original Message ----- > *From:* MustLive <[email protected]> > *To:* Dotclear (contact) <[email protected]> > *Sent:* Wednesday, April 10, 2013 9:47 PM > *Subject:* Re: XSS and CS vulnerabilities in Dotclear > > *Hello Franck!* > > Since there was no answer from you on my letter from 14.01.2013, so I > decided that you've ignored my letter. Because most of those who doesn't > answer on my letters, they just ignore and don't fix holes. And others (who > doesn't answer on my letters) fix hiddenly without thanking and without > official mentioning (at site and/or in changelog) about fixing of > vulnerabilities and those who informed about them. I haven't received any > thanks and/or official mentionings of me since 14th of January. > > Plus I've informed you about multiple vulnerabilities in three flashes, > not in just one swf-file (uploader) on which you are referencing (without > calling its name - SWFUpload, but it's clear for me, but not for others, > nor it's not count as official referencing on me and to the lists of fixed > holes, i.e. you should clearly write about fixing three holes: 2 Cross-Site > Scripting and 1 Content Spoofing vulnerabilities, not mentioning holes in > two other flash-files). From this it's clear that you've not fixed holes in > player_flv.swf and player_mp3.swf, just fixed (and badly, see below) holes > in swfupload.swf. > > You said you've fixed holes in SWFUpload, but it's not so. Before sending > my previous letter to you, I've checked your site, because almost 3 months > pasted since informing you and I planed to disclose these holes soon. And > at your site (http://dev.dotclear.org/2.0/browser/inc/swf) I've found > that none changes were made for player_flv.swf and player_mp3.swf and only > swfupload.swf was changed (at 13.03.2013) to fix the holes in it. So you've > ignored holes in first two flashes and just fixed (without answering and > thanking me) holes in third swf-file. I've downloaded it and checked it > on localhost and found that it's vulnerable to all holes, which I've > informed you about. So you didn't fix these holes either. And after that > I've wrote you my last letter. > > In which version (2.5) and how did you fix these holes, since all three > swf-files are vulnerable? Did you prevent flashes from being called > directly, as you wrote? Then give me example of any site on Dotclear 2.5, > so I can check it. I saw only sites with older versions of Dotclear which > are vulnerable to all these attacks on flashes. > > > Note also that any of the injections given in example cannot be used > with Dotclear as our swf files cannot be called directly. > > Why do you think that your swf files can be called directly. At those web > sites, which I've found in Internet, I see that they can be called > directly. So I have not seen such protection and for this reason considered > all vulnerabilities in swf files in Dotclear as real and informed you. > > Here are examples of one web site on your engine: > > *Cross-Site Scripting (WASC-08):* > > > http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?movieName=%22]);}catch(e){}if(!self.a)self.a=!alert(document.cookie);//<http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?movieName=%22]);%7Dcatch(e)%7B%7Dif(!self.a)self.a=!alert(document.cookie);//> > > *Content Spoofing (WASC-12): > > * > http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=test%3Cimg%20src=%27http://demo.swfupload.org/v220/images/logo.gif%27%3E > > *Cross-Site Scripting (WASC-08):* > > http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=%3Ca%20href=%27javascript:alert(document.cookie)%27%3EClick%20me%3C/a%3E > > And similar attacks on other flash-files, about which I've informed you - > on XSS and CS vulnerabilities in player_flv.swf and player_mp3.swf. > > Best wishes & regards, > Eugene Dokukin aka MustLive > Administrator of Websecurity web site > http://websecurity.com.ua > > ----- Original Message ----- > *From:* Dotclear (contact) <[email protected]> > *To:* MustLive <[email protected]> > *Sent:* Wednesday, April 10, 2013 12:48 PM > *Subject:* Re: XSS and CS vulnerabilities in Dotclear > > Hi Eugene, > > We took into account the multiple vulnerabilities you mentioned and > released a **2.5 version** of our script on March, 16th, and we also talked > about this in our blog post, the same day : > > " Among the differences beetween our RC and this release: a couple of bugs > have been fixed, and more importantly, we had to fix two security issue > comming from the multiple files upload system we're using. We are now > planning to replace this (Flash) component by a new one, in Ajax. Expect a > 2.5.1 one of these days. :) " > > in http://dotclear.org/blog/post/2013/03/16/Dotclear-2.5 > > May be you have not yet seen this ? > > Note also that any of the injections given in example cannot be used with > Dotclear as our swf files cannot be called directly. > > Best regards > Franck for the > Dotclear Team > > 2013/4/9 MustLive <[email protected]> > >> ** >> *Hello developers of Dotclear!* >> >> In January I've informed you about multiple vulnerabilities in >> Dotclear. You have lamerly ignored my letter and haven't fixed these holes. >> >> I've wrote you about Cross-Site Scripting and Content Spoofing >> vulnerabilities in flash-files in your engine. Dotclear has three swf files >> (according to your site http://dev.dotclear.org/2.0/browser/inc/swf), I >> suppose last version Dotclear 2.4.4 too. And these files are vulnerable to >> XSS and CS, so your engine has these holes. >> >> Now I'll give you more vulnerabilities in SWFUpload, in addition to >> previous XSS hole, which I'll be disclosing together with previous >> vulnerabilities in all three swf-files in Dotclear. >> >> These are new Cross-Site Scripting and Content Spoofing vulnerabilities >> in your engine. I've wrote about these holes already in March in my >> advisories concerning SWFUpload ( >> http://seclists.org/fulldisclosure/2013/Mar/110 and >> http://seclists.org/fulldisclosure/2013/Mar/116). If you would fixed >> previous hole in SWFUpload in January, when I first informed you, then >> you also fixed these holes. >> >> *Content Spoofing (WASC-12):* >> >> >> http://site/inc/swf/swfupload.swf?buttonText=test%3Cimg%20src=%27http://demo.swfupload.org/v220/images/logo.gif%27%3E >> >> It's possible to inject text, images and html (e.g. for link injection). >> >> *Cross-Site Scripting (WASC-08):* >> >> >> http://site/inc/swf/swfupload.swf?buttonText=%3Ca%20href=%27javascript:alert(document.cookie)%27%3EClick%20me%3C/a%3E >> >> Code will execute after click. It's strictly social XSS. >> >> The same as with previous holes, to these ones vulnerable are all >> versions of Dotclear - Dotclear 2.4.4 and previous versions. >> >> Best wishes & regards, >> Eugene Dokukin aka MustLive >> Administrator of Websecurity web site >> http://websecurity.com.ua >> > > > > > -- > Dotclear Team > -- Dotclear Team
_______________________________________________ Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
