launchpad-dev team mailing list archive

[Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx>]

> 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?

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 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.

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

Leonard

Attachment: signature.asc
Description: This is a digitally signed message part