General discussion


Dear IE, I'm leaving you for good

By typemismatch ·
article root

This conversation is currently closed to new comments.

41 total posts (Page 4 of 5)   Prev   02 | 03 | 04 | 05   Next
Thread display: Collapse - | Expand +

All Comments

Collapse -


by David Hamilton In reply to CERT Report on ActiveX

A most amusing read!

My executive summary of that paper is: "Only ever use ActiveX controls created by your own company on your own Intranet; disable everything else."

And I really enjoyed the 9 (NINE!) page appendix of vulnerabilities.


Collapse -

Knock your self out.

by bcampbellOne In reply to ROFL

Hey, no problem knock your self out, it can be extremely difficult to get past our preconceptions and bias. That's why the paper was written in the first place.
As the paper notes,"ActiveX is a powerful and, therefore, potentially dangerous technology. Most of the risks can be managed if you are aware of the problems. The concerns discussed in this section should be borne in mind when deciding when and how to use ActiveX in your environment."

It seem the problem here is not really ActiveX, but a lack of ActiveX knowledge and poor implementation by developers...

Collapse -

Hello - planet earth calling...

by David Hamilton In reply to Knock your self out.

We're discussing the use of this technology on the Internet - right?

OK, in that case:

1) The only way to be safe is to know where the control comes from or disable it (e.g. don't use it on the internet).
2) Anything else is a risk and, sooner or later, given the size of the Internet, it WILL be exploited.

No, the problem IS ActiveX, and more specifically its lack of sandbox facility, compounded by the power of scripting its capabilities. From the report (read and weep):

"Execution Concerns ? running controls

1. ActiveX controls have more capabilities than tools that run strictly in a sandbox. Because ActiveX controls are native code that run directly on a physical machine, they are capable of accessing services and resources that are not available to code that runs in a restricted environment.

2. Nearly all ActiveX control security mechanisms are based on Internet Explorer. Unfortunately, ActiveX controls do not rely only on Internet Explorer; they can be installed and executed completely outside of IE. Third-party applications that use ActiveX technology may not provide the security mechanisms available in Internet Explorer.

3. Many of the security mechanisms provided by Internet Explorer are coarse. Some of the security mechanisms are all-or-nothing propositions, forcing a user to choose between functionality and security. For instance, there is currently no way
to run a single ?unsafe for scripting? control without enabling all ?unsafe for scripting? controls.

4. When an ActiveX control is executed, it usually executes with the privileges of the current user. There is no mechanism for externally restricting the privileges of a control. (i.e., ?sandboxing?).

5. Because ActiveX controls can be invoked remotely (through a web page or email message), each control presents a channel into a network that can potentially be used by an attacker.

6. ActiveX controls do not have an effective abstraction. Because each ActiveX control has arbitrary latitude in deciding when it can be run and what it can do, it is impossible for users to intuitively determine the behavior of an given control.

7. ActiveX controls are difficult to manage and audit, particularly for non-expert users. The tools to manage ActiveX controls are lacking in several important areas. (For more details, see the section for system and network administrators in Part 2.)

Scripting Concerns

1. ActiveX controls that are scriptable are responsible for implementing their own security. Because ActiveX controls do not run in a restricted environment (a sandbox), each scriptable control is required to implement its own security policy?in effect, its own sandbox. Implementing a single sandbox is difficult, as
evidenced by recent problems in certain Java classes from Netscape
( Though it is not true that each control has to implement a general-purpose sandbox, each control does have to ensure that it behaves well in response to any input, in any order. Because each
control presents a channel into your network (as described above), there is a large number of potential failure points.

2. Scripts can use controls in ways unanticipated by the original control author. This often leads to unexpected behavior that can be exploited to violate security policy.

3. Scripts can invoke controls ?translucently.? A user may not realize that a script is using controls, and it may be impossible to determine beforehand which controls are being used (in an HTML document). As a result, the user might not be able to make informed decisions on whether to open such documents.

4. ActiveX is a means for scripts on a web page to escape the Internet Explorer 'sandbox.' This is arguably a script engine issue, but it does illustrate one way in which a control could be used to subvert security.

5. Scripting engines other than those in Internet Explorer might not provide the security mechanisms that IE does with respect to ActiveX. As third-party applications incorporate ActiveX technology, they will be responsible for
invoking ActiveX security.

6. Cross-site scripting is still poorly understood. Users of many web sites are vulnerable to a variety of cross-site scripting attacks. (See Because ActiveX controls are not isolated in any way, trust decisions made in the context of a cross-site scripting attack can lead to the invocation of vulnerable native code."

Collapse -

by bcampbellOne In reply to Hello - planet earth call ...

It always amazes me how narrow peoples focus is when it comes Microsoft. Here you have the top internet security site on the web attempting to educate users, developers and management on a particular technology and what happens? More spin then a polictical campaign.

Like I said, you only *see* what you want to see. Go back and read the whole document and you might see that the power and reuse of ActiveX controls comes from the fact that they DO NOT run in a sandbox, that's the way they were designed.
"ActiveX controls have more capabilities than tools that run strictly in a sandbox.
Because ActiveX controls are native code that run directly on a physical machine,
they are capable of accessing services and resources that are not available to code
that runs in a restricted environment."

Microsoft has tons of material on how to use, secure and delvelop ActiveX controls. The trouble is that people don't read. And if you don't read, you will weep."

My planet is Earth, you may blindly go where no man has gone, but in technology, that will kill you.

Collapse -

Re: It always amazes me...

by David Hamilton In reply to Hello - planet earth call ...

Reply to message above.

The point that you're completely missing (probably deliberately) is that the power that you talk about, while it is fantastic on a controlled environment like an Intranet, is DOWNRIGHT DANGEROUS in an uncontrolled environment like the Internet.

"Microsoft has tons of material on how to use, secure and delvelop ActiveX controls."

I'm not talking about badly developed controls; I'm talking about deliberately malicious controls!!

The Internet is a huge place, and (unfortunately) contains a fair number of pretty sick individuals. If a technology on the Internet can be misused, IT WILL BE.

Unfortunately, that power that ActiveX has makes fundamentally open to misuse. You cannot dismiss that as spin - it's the reality of the situation.

Nelson, I think it is time for you to hold the telescope to your good eye, and look again.


Collapse -

That is the idea of ActiveX controls

by MadestroITSolutions In reply to Hello - planet earth call ...

Where you see problems, I see features.
That is precisely the idea behind ActiveX controls. They give you the flexibility and the functionality that you otherwise would not have in a stateless and limited environment as the web is (Not that ActiveX controls cannot be used in regular programs).
And Of course the developer is responsible for security. If ActiveX allows you to have a component running on the client side with user priviledges, it is up to you to make sure that no one exploits your control.
Talking about "Scripts can use controls in ways unanticipated by the original control author.", hmm, that sounds to me like most vulnerabilities out there. If I send a super long and carefully crafted string to your web server, I will get it to do something you did not program it to do, like access violations, right?

Collapse -

Re:Re: It always amazes me...

by MadestroITSolutions In reply to Hello - planet earth call ...

If that is the case David, then we should stop making cars and motorcycles because they are dangerous. Maybe you should give a call to Marlboro and ask them to stop making cigarrettes, and while you are at it, call the patents office and ask them to destroy any patents and technology related to making guns, because someone might make a "deliberately malicious" gun and kill someone else.... :)

Collapse -

KeeBored - Your Error...

by David Hamilton In reply to Hello - planet earth call ...

The error in your analology is one of scale. While dangers with cars and bikes do exist, the danger is constant. I.e. a problem with one car is not likely to infect other cars and bring the road system to a standstill.

Flaws on the internet can increase by orders of magnitude due to the level of automation, and so a totally different set of danger criteria have to be applied.

I'd give your short essay on Internet Security a grade of "D-. Hasn't really got the hang of the subject yet".


Collapse -

Well, a few things...

by MadestroITSolutions In reply to Hello - planet earth call ...

1) Evidently, you do not live in a big city, or at least not in one where a simple car crash can bring 1/4 of the city to a traffic halt.

2) In terms of Internet Security, there are only two alternatives: either it is secure, or not.

Finally, being a programmer with over 7 years of experience and having worked in some pretty big companies and projects, I can assure you I know what I am talking about.


Collapse -

Konqueror is enough for me

by gimbal In reply to Dear IE, I'm leaving you ...

....given, "What's available?" -- across all PC
operating systems.

(Konqueror is also the basis -- somehow -- of
Apple's nice Safari browser.)


I've been through with Windows and IE, on my
home station, for some many years.

(I can deal with the Microsoft systems, at work
-- they are as they are; people get what they
get; people use what they've been taught on --
but, there is nothing so seriously useful to me
as my own self-admin'd Linux station -- that
being, really, not a
Microsoft-remote-by-way-of-kludgy-design admin'd

KDE's Konqueror is my favorite browser, in the
Linux XFree86 world -- it looks nice, it runs as
well as any "full featured" browser

(and the whole stinking lot of browsers seem to
be bloated on some sort of insanity in the
low-level code, or something, but, "we make

...and it's customizable, stylish, comfortable,
and quite more useful than Microsofts' IE --
though it's made on some similar design
principles, at least about the fact: Konqueror
can be used as a web-browser, or as a regular
file manager.

Now, most of y'all might not know what SSH is,
for one, but, in short: It's useful for
publishing to a web site (without the
procesor-expenditures, attendant with DAV on the
server, and the certificate fun, attendant with
HTTPS). Konqueror, for one, handles scp: URIs --
so, I can use Konq. to publish straight to a web
site, as if I was copying a file to a local
filesystem directory

....and I didn't have to download, install, and
keep track of any hacked-in
patch/driver/CAB/whatever sort of thing, for
that very useful "feature" of Konqueror to be in
place. Konqueror ships with it.

Back to Desktop Forum
41 total posts (Page 4 of 5)   Prev   02 | 03 | 04 | 05   Next

Related Discussions

Related Forums