Re: It's COBOL, Jim, but not as we know it...
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 10 Dec 2008 14:51:17 +1300
Richard wrote:
On Dec 10, 10:55 am, "Pete Dashwood"<snip>
<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:
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.
But the authentication determines what level of access it gets. If you don't
trust the author you can either not download (probably wise...) or download
but only allow read-only access. (You switch to a group or user account
that has authentication set up for read-only, THEN download).
Windows is highly configurable; the fact that people ignore this and run
everything as an Administrator, is hardly a problem with the Operating
System... You can swith users with a couple of mouse clicks.
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.
But isn't that what any system Administrator should do?
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.
"Always" being "since 1997"... when it took a leaf out of Windows' book.
http://www.javaworld.com/javaworld/jw-05-1997/jw-05-security.html
Which is dated 1997. Hardly 'Sun has _now_'.
I'm sorry, I missed that. At that time COM (ActiveX) was very vulnerable and
there were a number of famous cases where it was penetrated.
The COM model today and the COM model then are very different.
I thought that MS might drop it in favour of WCF but, instead they are
adding language facilities to make COM easier for programmers and to enhance
facilities in it. The forthcoming release of C# has improved COM Classes and
properties. They ARE replacing COM++ (the RPC implementation) with WCF.
It is Microsoft that is trying to catch up.
I don't see how you can say that when they were obviously ahead in 1997, and
have since moved way beyond their position then.
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.
You are living in the past. It doesn't work today the way you think it does.
I'll say it one last time... It can ONLY write to your system if you allow
it to authenticate with write permission.
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.
Nope. Hasn't been the case since Office 6 (using Outlook as the mail
program) and IE6. Users will get a message warning them of dangerous file
type attachments. In fact, this can be tiresome because if you want to send
someone a database or an executable you have to rename it or it won't get
delivered. They then need to rename it back before executing it, so it is
hardly likely they "didn't know about it".
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.
Nope. Again, you are simply way out of date on things MicroSoft. That's OK,
I understand you have no affinity for it and would therefore have no reason
to keep up, any more than I am familiar with the latest Red Hat release and
what it adds to Linux,... but I don't go around slagging off Linux...
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).
Please seee above.
Windows 'security' is simply that of MS-DOS with layers added to patch
up the problems.
Not since XP. (That is at least 7 years now). The NT kernel was NOT DOS
based. (New Technology) You probably won't find the history interesting, but
others might: http://wiki.oldos.org/Windows/WinNT5x
The problems cannot be entirely eliminated because
applications have been developed over the decades that would fail if
they were.
But, generally, they don't.
In fact that is why Vista's improvements does have compatibility
issues with many older applications.
It has nothing to do with security. It has to do with device drivers. Vista
supports over 2,000,000 devices but that just isn't enough.
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.
As there also is on Macs and systems running Unix based OS's. It's just that
many Linux users labour under the delusion that they are safe.
Here's a transcript from a Linux forum 4 years ago where at least one user
was talking sense...(The atrocious spelling and grammar has been left
intact; I believe the posters may not be speakers of English as a first
language.)
-----------------------------------------------------------------------------------
I am new to linux and my question is do I need a ant-virus program, if
which one would be best and ware to find one.
A virus for linux would need to escalate it's privaleges for it to
execute any kind of serious payload; so no , you don't need one.
no no no
there might be a dozen ways to escalite privileges, what to you think the
last kernel-security update i.e. was about?
The root of the problem (possible executing of arbitrary code) is the same
as on windows. There are enough format-string- and
buffer-overflow-problems on linux software too.
ok ok ok
there are not that much viruses and worms for linux, so the risk of an
infection is not the same as on windows. So you might not need the same
kind of anti-virus-software like on windows.
But the fact that your box runs on linux does not mean that it is safe.
So you have to do the same things as on a windows system:
- close holes
- keep it up to date
- be careful about strange mails
.....
-------------------------------------------------------------------------------
The bottom line is that ANY system needs to have decisions made by an
Administrator as to how potential threats will be handled.
And there will always be potential threats. (The String2Num COM component is
NOT such a threat... : - ))
Pete.
--
"I used to write COBOL...now I can do anything."
.
- Follow-Ups:
- Windows permissions was Re: It's COBOL, Jim, but not as we know it...
- From: Clark F Morris
- Re: It's COBOL, Jim, but not as we know it...
- From: Michael Wojcik
- Re: It's COBOL, Jim, but not as we know it...
- From: Howard Brazee
- Windows permissions was Re: It's COBOL, Jim, but not as we know it...
- References:
- It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: HeyBub
- Re: It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: Robert
- Re: It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: Richard
- Re: It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: Richard
- Re: It's COBOL, Jim, but not as we know it...
- From: Pete Dashwood
- Re: It's COBOL, Jim, but not as we know it...
- From: Richard
- It's COBOL, Jim, but not as we know it...
- Prev by Date: Re: It's COBOL, Jim, but not as we know it...
- Next by Date: Re: It's COBOL, Jim, but not as we know it...
- Previous by thread: Re: It's COBOL, Jim, but not as we know it...
- Next by thread: Re: It's COBOL, Jim, but not as we know it...
- Index(es):
Relevant Pages
|