On 12 July 2010 18:02, Leonard Richardson <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
