[PKG-Openstack-devel] Bug#788306: Bug#788306: Bug#788306: Bug#788306: horizon: CVE-2015-3219: XSS in Horizon Heat stack creation

[Thomas Goirand]

On 06/10/2015 11:06 PM, Moritz Mühlenhoff wrote:
> On Wed, Jun 10, 2015 at 05:00:27PM +0200, Thomas Goirand wrote:
>> On 06/10/2015 12:23 PM, László Böszörményi (GCS) wrote:
>>> On Wed, Jun 10, 2015 at 10:42 AM, Salvatore Bonaccorso
>>> <carnil at debian.org> wrote:
>>>> On Wed, Jun 10, 2015 at 09:10:56AM +0200, László Böszörményi (GCS) wrote:
>>>>>  Just checked. The Wheezy version doesn't contain the vulnerable code
>>>>> segment, but the Jessie version does. Mark the bug accordingly.
>>>>> In case you may accept, I attach a debdiff for Jessie.
>>>>
>>>> Thanks for the quick followups. Am I right that jessie though is not
>>>> affected due to
>>>> https://bugs.launchpad.net/horizon/+bug/1453074/comments/13
>>>>
>>>> The field help_text is always escaped already.
>>>>
>>>> Is that right?
>>>  I think the correct answer would be 'it depends'. If you check the
>>> presentation layer when that text used as-is, then yes, it's escaped
>>> there already. On the other hand that text may be used in the code for
>>> addition to other variables that may not be escaped for the
>>> presentation tier. Then the user may have customized his/her
>>> installation that use the mentioned text without escaping. Last but
>>> not least some plugin or other software may also use that text without
>>> filtering. If I think these cases then OpenStack may be vulnerable in
>>> other places that can be harder (but not impossible) to take advantage
>>> of this CVE.
>>> In short, the comment you mention emphasize this: "Juno - ASSUME that
>>> help text is always safe:" (ie, not 100% sure). That can be the reason
>>> upstream has an update for Juno which was merged[1]:
>>> Branch  stable/juno
>>> Status  Merged
>>>
>>> I say it's better to be more safe and may escape that string twice
>>> than have a risk of a vulnerability remain in some use cases. But of
>>> course, you are in the position to choose if a DSA is issued or not.
>>
>> Hi again,
>>
>> FYI, I uploaded to Sid:
>> horizon_2015.1.0+2015.06.09.git15.e63af6c598-1
>>
>> To Jessie backports:
>> horizon_2015.1.0+2015.06.09.git15.e63af6c598-1~bpo8+1
>>
>> and as for Jessie, as per Laszlo patch, its:
>> horizon_2014.1.3-7+deb8u1
>>
>> So the Sid and Jessie backports are including the last 15 commits since
>> the stable release (which are non-security bugfixes). I'll do like this
>> from now on, as it's a way more easy for me to do so, and because
>> upstream is currently questioning doing point releases all together.
>>
>> I don't really mind the DSA, but I would prefer the patch to reach
>> Jessie through the (faster) security updates.
> 
> I don't think this qualifies for a DSA. We can piggy-back the fix into
> a future DSA or fix it through the 8.2 point release.
> 
> Cheers,
>         Moritz

Moritz,

Could you please allow me to upload the package to the security FTP,
even without a DSA? Dealing with the release team to update software for
security is often frustrating because it takes too long (because they
are busy, and they often ask for too much).

Cheers,

Thomas Goirand (zigo)