Some high-level points: 1) In thinking about security, I find it helpful to separate policy from mechanism. A bunch of messages in this thread are about various mechanisms (taint tracking, DOM reference monitors, etc), but we don't have a clear idea what policy we'd like these mechanisms to enforce.
2) Several messages are interested in protecting passwords (e.g., noticing if an extension mis-uses passwords in various ways). Before we think about what sorts of policies we ought to apply to passwords, we should think about how we're going to recognize what's a password and what's not a password. Just using <input type="password"> isn't sufficient if the extension can draw things on the web page (which is a more or less a requirement for the extension system) because the extension can draw a box that looks exactly like a password field. 3) Some folks are tempted to punt security questions to the user (e.g., extension XYZ wants to communicate with host ABC, allow/deny?). Although it might make us feel better to be able to blame the user when something goes wrong, many users won't have enough context to make reasonable security decisions when faced with these kinds of questions (e.g., should the Happy Fun Ball extension be allowed to communicate with happyfunball.com?). Adam On Fri, Jan 1, 2010 at 6:48 AM, Laurence <l.d.ander...@gmail.com> wrote: > Agreed, it'll be hard to detect if an extension is maliciously using > passwords. However if passing of passwords can be detected between the > content script and the background page/XHR for example, it can have a > security capability associated with it, which hopefully people would > only grant to a password saver. Well that's my theory... > > Laurence > > On Jan 1, 2:10 pm, PhistucK <phist...@gmail.com> wrote: >> But, think of the counter case, how can you detect that an extension is >> maliciously using your passwords as malicious, and an extension that is >> rightfully using your passwords (a password saver) as not malicious? >> >> Both of them can act the same way, so, what, will you block both of them due >> to the security risks? >> >> ☆PhistucK >> >> >> >> On Fri, Jan 1, 2010 at 16:04, Laurence <l.d.ander...@gmail.com> wrote: >> > Could there be some more fine grained security around forms, >> > especially password fields? (Including document.onkeypress when a >> > password field has focus, and possibly other vectors - am I being too >> > simplistic here - does the content script merge and become >> > indistinguishable from the web page itself?). It should be very rare >> > for extensions to need these (only password managers, which you >> > implicitly trust with everything anyway), and if people give an >> > extension access to their passwords, then they do it with their eyes >> > open. >> >> > Is fine grained security around eval/innerHTML from XHR possible? I >> > assume that would be difficult too, would need to 'taint' every >> > variable derived from an XHR. >> >> > What do you think? Or other ideas? >> >> > Laurence >> >> > On Dec 31 2009, 10:14 pm, Mohamed Mansour <m...@chromium.org> wrote: >> > > Maybe having some kind of statistical usage of xhr calls that each >> > extension >> > > will keep track permanently. That way, we could do some sort of smart >> > > algorithm that will point out some uncommon, untrustworthy requests. I am >> > > just dreaming, but I think its possible to eliminate some threat. >> >> > > Cause currently, if some developer's extension's account got hijacked or >> > > stolen, the user could modify his extension and add some privacy >> > concerning >> > > risks. To (try to) stop that, we could do what we did before, and let the >> > > developer supply the certification file (pem) everytime he updates his >> > > extension, that will eliminate that kind of threat, when the account has >> > > been compromised. >> >> > > PS: I am not a security person, just some ideas that came out of my head. >> > So >> > > I might be just dreaming. Nevertheless, its an interesting topic. >> >> > > -Mohamed Mansour >> >> > > On Thu, Dec 31, 2009 at 3:44 PM, Adam Barth <aba...@chromium.org> wrote: >> > > > Yes, that's a scary scenario and a real threat. If you have ideas for >> > > > what we could do to protect against that threat, I'd be interested in >> > > > discussing them. >> >> > > > Keep in mind that a nefarious extension doesn't need the auto-update >> > > > system at all to change its behavior over time. For example, the >> > > > extension can load code from it's own web site into the extension >> > > > process (e.g., via eval or innerHTML). >> >> > > > Adam >> >> > > > On Sun, Dec 27, 2009 at 4:16 AM, Laurence <l.d.ander...@gmail.com> >> > wrote: >> > > > > Hi, >> >> > > > > I've been playing about with the extension framework - really is a >> > joy >> > > > > to use. >> >> > > > > However I have a slight concern about the threat model. It's fairly >> > > > > trivial to write an extension to log all form data (from both http >> > and >> > > > > https sites) and send it off to a foreign host, given content script >> > > > > and Cross-Origin XHR permissions. The threat model assumes that such >> > > > > an extension will get bad reviews, so not affect many users, but does >> > > > > it factor in the autoupdate mechanism? >> >> > > > > As a nefarious developer, I could create a perfectly innocent and >> > > > > useful extension (with content script and Cross-Origin XHR >> > > > > permissions), and wait until a large number of users have installed >> > > > > it. Then I release a new version, automatically pushed out to >> > existing >> > > > > users, that introduces form logging. Whilst it may only take a day or >> > > > > so for someone to notice and the extension killed, large numbers of >> > > > > users will have their details (usernames, passwords, credit card >> > > > > numbers) stolen. >> >> > > > > Any thoughts? >> >> > > > > Laurence >> >> > > > > -- >> >> > > > > You received this message because you are subscribed to the Google >> > Groups >> > > > "Chromium-extensions" group. >> > > > > To post to this group, send email to >> > > > chromium-extensi...@googlegroups.com. >> > > > > To unsubscribe from this group, send email to >> > > > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2Bunsu >> > > > bscr...@googlegroups.com><chromium-extensions%2Bunsu >> > bscr...@googlegroups.com> >> > > > . >> > > > > For more options, visit this group at >> > > >http://groups.google.com/group/chromium-extensions?hl=en. >> >> > > > -- >> >> > > > You received this message because you are subscribed to the Google >> > Groups >> > > > "Chromium-extensions" group. >> > > > To post to this group, send email to >> > chromium-extensi...@googlegroups.com. >> > > > To unsubscribe from this group, send email to >> > > > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2Bunsu >> > > > bscr...@googlegroups.com><chromium-extensions%2Bunsu >> > bscr...@googlegroups.com> >> > > > . >> > > > For more options, visit this group at >> > > >http://groups.google.com/group/chromium-extensions?hl=en. >> >> > -- >> >> > You received this message because you are subscribed to the Google Groups >> > "Chromium-extensions" group. >> > To post to this group, send email to chromium-extensi...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2Bunsu >> > bscr...@googlegroups.com> >> > . >> > For more options, visit this group at >> >http://groups.google.com/group/chromium-extensions?hl=en. > > -- > > You received this message because you are subscribed to the Google Groups > "Chromium-extensions" group. > To post to this group, send email to chromium-extensi...@googlegroups.com. > To unsubscribe from this group, send email to > chromium-extensions+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/chromium-extensions?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to chromium-extensi...@googlegroups.com. To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
