Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Sep 2012 17:43:16 -0600
From: Kurt Seifried <>
CC: Tavis Ormandy <>
Subject: Re: Re: note on gnome shell extensions

Hash: SHA1

On 09/13/2012 11:59 AM, Tavis Ormandy wrote:
> Vincent Danen <> wrote:
>> * [2012-09-13 18:03:33 +0200] Marcus Meissner wrote:
>>> On Thu, Sep 13, 2012 at 05:39:57PM +0200, Tavis Ormandy wrote:
>>>> On Mon, Sep 10, 2012 at 02:48:38PM -0600, Vincent Danen
>>>> wrote:
>>>>> * [2012-09-08 18:14:10 -0600] Kurt Seifried wrote: SUSE has
>>>>> some interesting info in their bug:
>>>>> By the sounds of it, this should be harmless.  Vincent Untz
>>>>> says that the browser plugin doesn't actually install the
>>>>> extensions, it's passed to another process via a dbus call
>>>>> to gnome-shell, which sends the uuid of the extension to
>>>>> the web site in order to download the
>>>>> extension.
>>>>> See:
>>>>> which is:
>>>>> let message = Soup.form_request_new_from_hash('GET', 
>>>>> REPOSITORY_URL_INFO, params);
>>>>> And REPOSITORY_URL_INFO is hardcoded earlier:
>>>>> const REPOSITORY_URL_BASE = '';
>>>>> '/download-extension/'; const 
>>>>> '/extension-info/'; const REPOSITORY_URL_UPDATE   =
>>>>> REPOSITORY_URL_BASE + '/update-info/';
>>>>> I don't think this is something that can be exploited,
>>>>> based on the above.
>>>> Not sure I follow the logic, can't I just upload something
>>>> malicious to and then force you to
>>>> download it? I mean, I can try it if you're not convinced
>>>> it's possible.
>>> There are supposed to be reviewers before it gets activated,
>>> but exactly this concern Sebastian also voiced.
>>>> They surely do not have a magical technique for determining
>>>> if my code is or can become malicious.
>>> Exactly.
>> Yeah, this is definitely a possibility, but could happen
>> regardless of this with some social engineering (hey, download my
>> cool foo extension!) and have something malicious up there.  This
>> is pretty much the same thing, just making it easier.
> Well, no. This is like saying it's pointless to patch
> vulnerabilities, because I can just make you download malware. You
> can't just make me download malware, because I know how to make
> trust decisions.
> You could make me download a malicious gnome extension, because you
> can do so without interaction or my consent.
>> It's not much different than having a malicious app in the 
>> iTunes/Android/Whatever app store.  The flaw there isn't so much
>> in the app store, but the app.  Wouldn't the same thought apply
>> here?
> I've uploaded my malicious android app, how do I make you install
> it?
> I can create, that's clearly not a
> vulnerability and working as designed. But if I can force you to
> download and install it without you having the opportunity to make
> a trust decision, that clearly is a vulnerability.
> Do you agree that I can upload something malicious to
> Do you agree that I can make you install it without consent,
> interaction, or the opportunity to make a trust decision?
> If so, then I don't understand the objection :-)
> Tavis.

Please use CVE-2012-4427 for this issue.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.