Article 2581 of comp.lang.java.security: Check out http://www.halcyon.com/mclain/ActiveX/ In article <1997022722081974952@zetnet.co.uk>, David Hopwood writes: |> In message <330DDC0C.6812@thoughtinc.com> |> Ward Mullins writes: |> |> > paulw@gkb.com wrote: |> > > |> > > I am new to this newsgroup. Please |> > > forgive me if I am asking already asked questions. |> > > |> > > I am interested in any document or any pointer about |> > > security holes from ActiveX, any recommandations, solutions |> > > provided to solve these holes and any clues about what |> > > should be done in the near future to prevent those |> > > from happening. |> |> If you look at old discussions on comp.lang.java.advocacy using |> www.dejanews.com, searching for the thread "Insecurity of ActiveX", |> most of the technical arguments against ActiveX are there. I'm in |> the process of finishing a web page which will give a more concise |> summary; when that's finished the location will be posted at least |> here and on comp.risks. |> |> The bottom line is that I recommend to disable ActiveX completely |> and permanently. I also think that even if you wanted to provide an |> authentication mechanism for the cases in which downloading native |> code is necessary or useful (and which is therefore inherently limited |> in the guarantees it can give), ActiveX would be a poor place to start. |> |> [By "ActiveX", I'm referring to the mechanism for downloading, |> installing and running controls using web clients; not the subset of |> COM that appears to have been given the same name.] |> |> > > Any pointer would be most welcomed. Thanks, Paul |> > > Reponse by email please, thanks. |> > > |> |> > Paul, |> |> > I hate to inform you of this, but Active-X has NO security, only |> > digital signatures which are supposed to tell you that the person |> > who created the script is the same person you received it from. |> |> Actually this is not the guarantee given by digital signatures. |> A digital signature attempts to prove that someone signed the control |> using the relevant private key. It certainly does _not_ prove that |> the owner of that key is responsible for the site you downloaded the |> control from. |> |> In fact it's perfectly possible, _without_ the signature algorithm or |> the browser's security implementation having been broken, that the |> following could all be different: |> |> - the author(s) of the control |> - the person who chose the data to be signed |> - the person who ran the signing algorithm |> - the person or organization whose name is on the certificate |> - the person who applied for the certificate |> - the person who generated the private/public key pair |> - the owner(s) of the web site that appears in the browser's location bar |> - the owner(s) of the web site given by the URL of the HTML page |> containing the OBJECT tag for the control |> - the owner(s) of the web site given by the URL of the control itself |> (both for the main file, and for any referenced files) |> - the signer(s), author(s), etc. of any other controls used by the |> downloaded control |> - the owner(s) of the web site(s) which provide data used by the control |> - the author(s) of the HTML page, and any scripts on it |> - the people who actually specify the content which is downloaded (in |> the case of an attempted man-in-the-middle attack). |> |> Some of these potential differences could be used for realistic attacks; |> some probably could not, but I find it disconcerting that even opponents |> of ActiveX often overstate the guarantees it attempts to make. |> |> David Hopwood |> david.hopwood@lmh.ox.ac.uk, hopwood@zetnet.co.uk |> |> -- Wayne O. Cochran wcochran@eecs.wsu.edu http://www.eecs.wsu.edu/~wcochran Ecclesiastes 3:11