W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

From: Marcos Caceres <marcosc@opera.com>
Date: Sun, 22 Feb 2009 19:10:35 +0100
Message-ID: <b21a10670902221010x307f80d0gb14a1667c45acafe@mail.gmail.com>
To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
2009/2/16 Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>:
> No problem.
> From
> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0346.html:
> ----------------
> [mp] The hole is that signature files are excluded from the generation
> of the signature values in any other signature files. This means that
> if, for example, an attacker added to the widget resource a signature
> file containing some malicious content, the malicious content of that
> file wouldn't be covered by any of the other signatures but the widget
> user agent thinks the entire widget resource is signed. This could
> happen regardless of whether or not the signature file was actually
> valid, or was just named according to the convention for digital
> signature.

Ok, good point.

> To be abused by an attacker it would either be necessary to inject a
> reference to the file into the widget, which might be difficult, or to
> hijack an existing reference to a signature file by swapping the
> intended signature file for the attacker's signature file (with the same
> name). While this later attack depends on the author providing such a
> reference in their widget, there are two reasons why the author may
> currently choose to do this - to get some information about the
> signature to display to the user, or possibly more likely, to get around
> the need to sign everything in their widget resource (I thought of this
> as a way around signing everything so developers will too!).


> It's not a big hole and the attacks require some "assistance" from
> developers, but unless there's a reason not to it should be pretty easy
> to close.
> ----------------
> I realise that this still requires the ability to read in the file,
> which would probably have to be via a local Ajax call, not a reference
> as I suggested above. You could say that it's a pretty theoretical
> vulnerability but if it's easy to fix and there's no negatives then I
> think we should address it.

Ok, as you saw, I created an issue so we don't forget to address this:


I also added your description of the hole.

Kind regards,
Marcos Caceres
Received on Sunday, 22 February 2009 18:11:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:51 UTC