|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IE 5 security vulnerabilities
- To: NTBUGTRAQ
LISTSERV.NTBUGTRAQ.COM - Subject: Re: IE 5 security vulnerabilities
- From: Harry Goodwin <harryg
MICROSOFT.COM> - Date: Thu, 25 Mar 1999 10:06:01 -0800
- Approved-By: Russ.Cooper
RC.ON.CA - Reply-To: Harry Goodwin <harryg
MICROSOFT.COM> - Sender: Windows NT BugTraq Mailing List <NTBUGTRAQ
LISTSERV.NTBUGTRAQ.COM>
I wanted to take a moment to thank Juan Carlos for bringing these issues to
Microsoft's attention prior to posting the issues publicly. I also wanted
to post Microsoft's response to the issues he's discovered.
1) Internet Explorer has customizable security settings in
place for users who are concerned about allowing certain functionality. In
this particular case, concerned users can easily block this behavior by
checking either 'disable' or 'prompt' under "Allow paste operations via
script"
in the custom settings section in security zones. Using the IEAK, admins
can also adjust the default setting for this option before distributing
Internet Explorer to their users. The option is set to 'enable' by default
to
allow enhanced functionality.
2) Upon investigation we did find a cross domain security
violation in the DHTML edit control which we will revoke, fix, and release.
3) Internet Explorer has a mechanism in place which allows
Microsoft to release a .reg file to block ActiveX controls by changing a
bit in the registry.
4) The following information found on MSDN (search on
CodeBaseSearchPath) addresses this concern: When Internet Component
Download is called to download code, it traverses the Internet search path
to
look for the desired component. This path is a list of object store servers
that will be queried every time components are downloaded using
CoGetClassObjectFromURL. This way, even if an <OBJECT> tag in an HTML
document does not specify a CODEBASE location to download code for an
embedded OLE control, the Internet Component Download will still use the
Internet search path to find the necessary code.
Internet search path syntax
The search path is specified in a string in the registry, under
the key
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\CodeBaseSearchPath. The value for this key is a string in the
following format:
CodeBaseSearchPath = <URL1>; <URL2>; ... <URLm>; CODEBASE;
<URLm+1>;
... <URLn-1>; <URLn>
In this format, each of URL1 through URLn is an absolute URL
pointing to HTTP servers acting as "object stores". When processing a
call to CoGetClassObjectFromURL, the Internet Component Download service
will
first try downloading the desired code from the locations URL1 through
URLm, then try the location specified in the szCodeURL parameter
(corresponding to the CODEBASE attribute in the <OBJECT> tag), and will
finally try the
locations specified in locations URLm+1 through URLn.
Note that if the CODEBASE keyword is not included in the key,
calls to CoGetClassObjectFromURL will never check the szCodeURL location for
downloading code. By removing the CODEBASE keyword from the key,
corporate intranet administrators can effectively disable Internet Component
Download for corporate users.
Thanks, Harry
- Follow-Ups:
- Re: IE 5 security vulnerabilities
- From: Phil Brass <pbrass
ISS.NET>
- From: Phil Brass <pbrass
- Re: IE 5 security vulnerabilities
- Prev by Date: Re: MSIE 5
- Next by Date: Re: IE 5 security vulnerabilities
- Prev by thread: IE 5 security vulnerabilities
- Next by thread: Re: IE 5 security vulnerabilities
- Index(es):