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: Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>
Date: Mon, 16 Feb 2009 20:10:57 +0100
Message-ID: <0BE18111593D8A419BE79891F6C46909028E7154@EITO-MBX01.internal.vodafone.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: "Frederick Hirsch" <frederick.hirsch@nokia.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, "public-webapps" <public-webapps@w3.org>
No problem.


[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

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.



>-----Original Message-----
>From: Marcos Caceres [mailto:marcosscaceres@gmail.com] 
>Sent: 13 February 2009 13:27
>To: Priestley, Mark, VF-Group
>Cc: Frederick Hirsch; Barstow Art (Nokia-CIC/Boston); public-webapps
>Subject: Re: Reminder: January 31 comment deadline for LCWD of 
>Widgets 1.0: Packaging & Configuration spec
>Hi Mark,
>2009/2/12 Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>:
>> [mp] To be clear I was suggesting that access to signatures was 
>> restricted from the widget after installation. I was not suggesting 
>> that they were not more generally available. As you say access to 
>> signatures after installation (outside of the widget) is useful and 
>> should be supported.
>Could you please explain what the security implications of 
>allowing a widget to have access to the signatures at runtime? 
>(apologies if you have done this in another email, I might 
>have missed it).
>Kind regards,
>Marcos Caceres
Received on Monday, 16 February 2009 19:11:58 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC