Re: It's COBOL, Jim, but not as we know it...

On Dec 10, 10:55 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Richard wrote:
On Dec 9, 5:00 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Richard wrote:
On Dec 9, 1:46 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Robert wrote:
On Tue, 9 Dec 2008 11:31:42 +1300, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Here's what SHOULD happen:

1. You click the link in the newsgroup message.(ONLY ONCE...
don't double click it...)

2. The logon page opens, followed a few seconds later by the
cobdata page opening in the background. (You should maximize the
login page if it isn't already.)

3. You login or register. It succeeds. You click "Resume" and the
standard download dialog for the ZIP file appears.

4. You download. Close the page. The standard cobdata page
remains.

(since Sunday, there have been 7 successful downloads.)

Here's what CAN happen:

1. Both the login and COBDATA main page appear simultaneously.
This has to do with browser delay and/or server workload. If it
happened, it shouldn't happen consistently. Everything will still
work, but it could be confusing to a user.

2. The login page may be minimized and all you see is the COBDATA
main page. This has to do with Browser settings or tabs if you
are using a tabbed browser.

3. The COBDATA page is obscuring the login page. Minimize the
COBDATA page and it should reveal the login page.

4. Your Firefox browser blocks the login page as a pop-up. That's
what happened to me. I told it to stop blocking pop-ups for this
site.

Damn! I took special care to make sure the thing works in Firefox
(even identifying and installing the Firefox add-in needed to
support ActiveX/COM into my updated Firefox browser...) but I never
thought about popups...
- )

And I thought that one of the main reasons for using Firefox was to
_stop_ being infected with ActiveX.

Gosh Richard, perhaps you were ... mistaken?

ActiveX is just code like any other computer code. It can be used
for good or it can be used for bad.

It is actually no more dangerous than any other kind of script.(An
ActiveX control has no more permissions on your system than a Java
Bean, for example.)

That is simply not true. An ActiveX control that has been loaded by a
webpage onto a Windows system is just another executable and has
access to everything that any other program can do, such as writing to
the disk.

But it can't get to your system via that route unless you enable  and allow
it. There was a time when IE used to simply download the component
transparently. That doesn't happen any more. That's why I need for people to
do a separate install of the component before they can run the demo.

It has to be installed and registered. It has topass authentication and mmay
have a signed digital signature which guarantees you are getting what you
thought you were getting.

Actually the signature only guarantees it was signed. It only assures
you that the signature is that of the author, you have to trust the
author.


All of this has a bearing on the permissions (like
file writing) that it ends up with. It can be disabled in seconds by

Seconds is all that it takes.

de-registering it, unlike a virus, trojan, or backdoor. It is VISIBLE on
your system.

But the files that it has written may not be visible.


As someone who has been writing these components for over a decade now I can
honestly say I have allowed controlled ActiveX downloads to my system and
have never had a problem with it. Security in the last few years has been
much improved as Howard alluded to.

As you say, controlled. It is _you_ that has improved the security, by
being aware of what the messages are saying and judging whether _you_
trust the author.


A Java applet (which is what can be in a webpage) runs in a sandbox
and cannot write to the disk, or access other processes.

The "sandbox" is a set of security measures which seriously limit the
usefulness of applets. So much so that Sun has now chosen to emulate the
MicroSoft system of signed authentication which is used by ActiveX controls.

Java always has had several levels of security. The default is that it
runs in a sandbox. It can, however, and always has been able to,
request increased facility using a signed mechanism.

http://www.javaworld.com/javaworld/jw-05-1997/jw-05-security.html


Which is dated 1997. Hardly 'Sun has _now_'.

It is Microsoft that is trying to catch up.


While both can be security risks (especially on Windows) ActiveX is
while working exactly as designed and Java only is when it can exploit
a flaw.

You could see it that way. I don't. But then, I don't write malicious
components that do damage while working "exactly as designed".


It is irrelevant that you don't write malicious components, others do.
It is the ActiveX mechanism that 'works as designed' when malicious
code can write to Windows file system.


Many millions of people find ActiveX components to be useful devices
that enhance their computer use. Calendars, juke boxes, and very
effective online virus scans from companies like Panda and Trend are
all implemented by means of ActiveX controls.

The mere fact that virus scans are necessary is an indication that the
security model is completely wrong.

The model is evolving. It is no more "wrong" than any other model would have
been.

Not true.

Microsoft email can automatically execute an attachment. In fact it
used to be (and may still be) that the email didn't even have to be
opened but clicking it so it could be deleted may have been enough
that the attachment executed.

Microsoft hides the 'type' of the file so that what looks like
'knickers.jpg' and would only open in image viewer is actually
'knickers.jpg.exe' and will execute and can write to the disk.

Other models do not allow execution of attachments or downloaded files
and they cannot even have the property of being executable so even if
saved to disk they cannot be executed (as an .exe can).

Windows 'security' is simply that of MS-DOS with layers added to patch
up the problems. The problems cannot be entirely eliminated because
applications have been developed over the decades that would fail if
they were.

In fact that is why Vista's improvements does have compatibility
issues with many older applications.



Investment of many millions has been made into improving it. Judging
today's model by what was true yesterday, is simply misleading.

And yet there is _still_ a requirement on Windows for Virus scans and
spyware scans. Windows based Botnets are still the most powerful
computing resource available.

The 'improvement' in Vista of putting up a 'allow/disallow' message is
_not_ for security, it is entirely to shift the blame from Microsoft
to the user.

If they habitually press 'allow' without reading (which is typical due
to overuse) or turn it off then viruses and spyware are the user's
'fault'.

In fact the 'many millions have been spent' was by users on Norton's
and McAfee et.al which is too valuable a source of revenue (ie user's
cost) to eliminate, even if Microsoft could.


Pete.
--
"I used to write COBOL...now I can do anything."

.

Relevant Pages

  • Re: RWW Remote Desktop activeX control
    ... "IE 6 wasn't secure" ... So Microsoft develops some new security models and folks don't like it. ... Desktop ActiveX Control. ...
    (microsoft.public.windows.server.sbs)
  • Re: Important...Interesting...Danger behind some file types ??
    ... and .URL files I can´t understand what malicious code they can carry. ... case of the URL the maximum they could do is execute a local file via 'file:' ... this issue on some security forums but no one was able to reply. ... no good documentation the only things Microsoft provide on SCF files are IE ...
    (microsoft.public.security)
  • Re: Important...Interesting...Danger behind some file types ??
    ... but for URL files you CANNOT pass parameters to the local file. ... Microsoft guys???? ... execute it as an .EXE anyways. ... With so many security threats out there, ...
    (microsoft.public.security)
  • ActiveX apologetic Larry Seltzer... "Sun paid for malicious ActiveX code, and Firefox is bad, bad ba
    ... to see Microsoft apologetics writing tiresome rants just when Redmond ... "trusted" win32 code downloaded over the net (ActiveX) vs. Java's ... "sandbox" security model... ... they also didn't mention that a signed Java applet could ...
    (comp.lang.java.programmer)
  • Re: What is an Active X?
    ... that Microsoft probably now wishes it had never ... The trouble is that security ... was never considered when ActiveX was developed. ... very easy for them -- you open some innocuous Word document containing ...
    (microsoft.public.word.newusers)