launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 12 July 2010 18:02, Leonard Richardson
<leonard.richardson@xxxxxxxxxxxxx> wrote:
>> That is true but to me the main point is that if there is malicious
>> code running within your desktop machine, you have bigger problems
>> than your Launchpad account.
>
> Sure; the question I'm trying to answer is whether malicious code
> running on your desktop machine also means bigger problems for lots of
> innocent people.
>
>> Can you unpack the logic there?  Do you mean that if malicious code
>> gets onto an Ubuntu system of a user who can write to the main archive
>> or a popular PPA, it can propagate to thousands of other machines.
>> That is true, but orthogonal to whether there is an API to manipulate
>> credentials.
>
> I'm not sure what you mean by "API to manipulate credentials". I don't
> know whether you mean "API to upload a new GPG key" or "API to create a
> new OAuth token without user input". Forgive the verbiage that follows;
> I want to be really precise about this.
>
> Let's take Bob to be a user who can write to the main archive of a
> popular PPA, and let's stipulate that Bob has malware on his computer.
>
> OK, what are the scenarios?
>
> 1. The current scenario. There is no API to upload a new GPG key and no
> API to create a new OAuth token. Can the malware on Bob's computer
> reproduce itself in the PPA? I guess, but it would have to include a
> keylogger (to sniff the passphrase to Bob's existing GPG key) or
> something fairly sophisticated.
>
> 2. There is an API to create a new OAuth token, but no API to upload a
> new GPG key. This is identical to scenario #1. The malware can exploit
> the API to create new OAuth tokens for itself, but it can't use the API
> to do what it really wants to do--reproduce.
>
> 3. There is an API to upload a new GPG key, but no API to create a new
> OAuth token. Now an exploit is trivial. The malware can grab Bob's
> existing OAuth token, impersonate one of his other applications, and
> upload a new GPG key. We can stop this from working by making "upload a
> new GPG key" require a single-purpose, one-use OAuth token.
>
> 4. There is an API to upload a new GPG key, and an API to create a new
> OAuth token. Now it doesn't help to require a single-purpose, one-use
> OAuth token, because the malware can create new OAuth tokens whenever it
> wants. The only way to plug the trivial exploit is to prohibit "create a
> new OAuth token" from creating the kind of OAuth token that can be used
> to upload a new GPG key.
>
> If we take the hard line that once there's malware on your system,
> you're screwed, then all four of these scenarios are identical--the
> difference between "fairly sophisticated exploit" and "trivial exploit"
> is not worth considering. I don't know if this is what you mean by "[The
> existence of an exploit] is orthogonal to whether there is an API to
> manipulate credentials." Is it?

We could do some more research and consultation (especially Kees or
Elmo), but my feeling is that there is not a substantial difference
between these cases.  We're not talking about an untargeted attack
that's just trying to collect a botnet or gmail account details.
Rather, this is someone who's specifically trying to get malware into
an Ubuntu archive, and presumably who's specifically targeted one of a
fairly small number of developers to get there.  It's a pretty
sophisticated and labor-intensive attack: you need to assume there's
not just malware but likely a malicious human with access to the
machine.  Installing a keylogger to get the gpg passphrase or
launchpad password is not a very difficult expensive step.  Similar
things have happened when other project sites have been broken into.

>
> If we take this hard line, then there's no reason to make
> WRITE_SENSITIVE_DATA tokens temporary or prohibit the OAuth token
> generator from generating them--we're just making the malware's job
> marginally easier.

I suppose so.  I think avoiding tokens hanging around on backups or
dead machines has some point.  Arguably having the user reauthenticate
for rare sensitive operations has some "are you really sure?" benefit.

> I think users are likely to need WRITE_SENSITIVE_DATA fairly rarely, so
> I don't have a problem with requiring these tokens to be acquired
> through the web browser. But:
>
> 1. The reaction to 'tokens through the web browser' has been incredibly
> negative. Others have spent a lot of time hacking around it, and I've
> spent a lot of time trying to broker and implement a compromise.
> Reintroducing the browser at (what will appear to the end-user as)
> random intervals isn't good for the user experience--you could argue
> it's worse than our current strategy of using the browser all the time.

Agree.  My argument about client-side security is that there is little
point forcing the user to do an interaction through a web browser
rather than through any other client-side program.

> 2. If we really consider scenario 4 and scenario 1 equally insecure, we
> might as well go for the superior usability of scenario 4.

Sorry, I'm not sure what "API to create a new OAuth token" means.  API
on the desktop credential-granting service?  I don't think you should
be able to use a less-privileged token to make a WRITE_SENSITIVE_DATA
one.

hth,
-- 
Martin