Fwd: XSS and CS vulnerabilities in Dotclear
by Dotclear (contact)
La suite…
---------- Forwarded message ----------
From: MustLive <mustliveua(a)gmail.com>
Date: 2013/4/11
Subject: Re: XSS and CS vulnerabilities in Dotclear
To: "Dotclear (contact)" <contact(a)dotclear.net>
**
*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 <mustlive(a)websecurity.com.ua>
*To:* Dotclear (contact) <contact(a)dotclear.net>
*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])...<http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?movieName=%22])...>
*Content Spoofing (WASC-12):
*
http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=test...
*Cross-Site Scripting (WASC-08):*
http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=%3Ca...
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) <contact(a)dotclear.net>
*To:* MustLive <mustlive(a)websecurity.com.ua>
*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 <mustlive(a)websecurity.com.ua>
> **
> *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://d...
>
> 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:al...
>
> 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
11 years
Fwd: XSS and CS vulnerabilities in Dotclear
by Dotclear (contact)
Quelqu'un pour lui répondre ?
Dotclear Team
---------- Forwarded message ----------
From: MustLive <mustlive(a)websecurity.com.ua>
Date: 2013/4/10
Subject: Re: XSS and CS vulnerabilities in Dotclear
To: "Dotclear (contact)" <contact(a)dotclear.net>
**
*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])...<http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?movieName=%22])...>
*Content Spoofing (WASC-12):
*
http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=test...
*Cross-Site Scripting (WASC-08):*
http://www.noslibertes.org/dotclear/inc/swf/swfupload.swf?buttonText=%3Ca...
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) <contact(a)dotclear.net>
*To:* MustLive <mustlive(a)websecurity.com.ua>
*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 <mustlive(a)websecurity.com.ua>
> **
> *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://d...
>
> 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:al...
>
> 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
>
11 years
Fwd: XSS and CS vulnerabilities in Dotclear
by Dotclear (contact)
Pour info
Franck
---------- Forwarded message ----------
From: MustLive <mustlive(a)websecurity.com.ua>
Date: 2013/4/9
Subject: XSS and CS vulnerabilities in Dotclear
To: contact(a)dotclear.net
**
*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://d...
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:al...
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
11 years
[sexy] Généralisation du getPostType, gestionnaire d'urls, ...
by Dsls
Hello,
A force de creuser dans les entrailles du core coté admin, je me rends
compte d'un besoin transverse pas encore adressé : la gestion des
URLs.
Par exemple : comment éditer la catégorie 1, comment afficher la
catégorie 1 coté public, ...
Je pense qu'un objet qui gère tout ça coté admin serait bienvenu.
Du genre :
$core->urlManager->getAdminLink('category',array('id',1))
$core->urlManager->getPublicLink('post',array('id',1))
...
Aujourd'hui, si on veut renommer admin/category.php en autre chose,
les impacts sur les fichiers à modifier sont assez conséquents. Autre
point, un plugin peut contourner tout ces liens vers les siens :)
--
Bruno
11 years
[sexy] form::combo, optgroup et cie
by Dsls
Yo,
Petit changement (déjà effectif, mais peut-être passé inaperçu) sur la
branche twig/sexy, concernant le devenir des form::combo, et sur le
fonctionnement interne.
Je me suis toujours posé la question sur le fait que la liste
d'options dans form::combo était de la forme :
array('label1' => 'id1', 'label2' => 'id2', ...).
Cela forçait une certaine gymnastique au niveau php (il faut parcourir
un tableau pour vérifier une valeur, plutôt que de tester la présence
d'une clé dans ce tableau).
Je pense que c'était surtout lié au fait de pouvoir définir un
optgroup, lequel était défini de la manière suivante:
array('labelgroupe1' => array('label1' => 'id1', 'label2' => 'id2', ...).,
'labelgroupe12' => array('label3' => 'id3' ...)).
Sur la branche sexy/twig, on est revenu au plus cohérent :
array('id1'=>'label1', 'id2' => 'label2', ...)
et avec les optgroup :
array('labelgroupe1' => array('id1'=>'label1', 'id2' => 'label2',
...), 'labelgroupe2' => array('id3'=>'label3'...)=>...);
A garder dans un coin de la tête donc, lors des prochaines évolutions
sur sexy/twig :)
--
Bruno
11 years
Install-Party
by Franck Paul
Dites les gens,
Ça fait un bail qu'on ne s'est vu, surtout toi, là bas dans le fond. Ça
vous dirait une install-party Dotclear (qui n'aura d'Install-Party que le
nom car c'est surtout pour papoter, discuter, troller, dire du mal des
gens, etc) disons mi-avril, le samedi 13 par exemple ?
Comptez-vous ici les ceussent qui viendraient dans un lieu qui reste à
trouver, mais d'ici là sa devrait pouvoir se faire.
Franck
11 years
[Sexy] Question sur pagination dans admin
by Dsls
Hello,
Je reviens sur la pagination des listes d'éléments dans l'administration.
Sur la branche default, si on est page 19, on la liste des liens suivants :
* "préc" (ie. p 18)
* "..." (ie p 1)
* 11 - 12 - 13 - 14 - 15 - 16 - 17 - 18 (ie. liens vers les pages idoines)
* 19 (sans lien)
* 20 (ie. p 20)
* "..." (ie p 21)
* "suiv" (ie p 20)
Donc, potentiellement:
* Un lien vers la page précédente
* Un lien vers la plage de 10 pages précédentes (donc vers la page 1
si on est page 19)
* Un lien vers 10 pages dans la dizaine de la page courante (11 à 20
si on est page 19, 41 à 50 si on est page 43)
* Un lien vers la plage de 10 pages suivantes (donc vers la page 21 si
on est page 11)
* Un lien vers la page suivante
Sur la branche formfilters, cela se résumait à des liens
début/précédente/Page X sur N/suivante/fin, avec un textfield pour
sélectionner une page voulue.
Je trouve l'approche de la branche default un peu déroutante
(notamment les le manque de sens des "..." et le fait qu'on n'ait pas
accès aux x pages avant/après la page courante), et l'approche
formfilters un peu trop simpliste.
Des idées de proposition pour faire évoluer la chose ? C'est vraiment
open-bar à ce niveau-là, n'hésitez pas à vous lâcher :)
--
Bruno
11 years, 1 month
Fichier CHANGELOG
by Franck Paul
Plop les gens,
Le fichier CHANGELOG n'est pas mis à jour via l'auto-update (because pas
présent dans le fichier digests, expressément exclu par le Makefile, ligne
80), c'est voulu ou bien ?
Franck
11 years, 1 month
