Re: Concern about the latest Window Eyes scripting move
- From: "Raul A. Gallegos" <raul@xxxxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Mon, 11 Feb 2008 11:18:13 -0500
Hi.
Whether the Window-Eyes script is running in process or out of process
doesn't degrade or enhance what the script can and can not communicate
with. The benefit of being in process is it is able to communicate with
Window-Eyes much fast as cross-process calls are not necessary but you
lose nothing at all by being in process. So you would not lose access
to WScript.Shell or WScript.FileSystemObject as you specifically listed.
Regarding the Window-Eyes method being more prone to having a virus is
not true as you mentioned, Any script can have a virus no matter what
just as any attachment in you email can have a virus. I never open an
attachment from a source I don't trust and I wouldn't run a script from
a source I don't trust. Window-Eyes will have the ability to only run
signed scripts with the ability to allow you to sign a script that is
only valid on your machine. Security is taken very seriously by GW
Micro and we will take every step necessary to keep malicious people
from taking advantage of this new powerful ability within Window-Eyes.
Hope this helps.
Chris Meredith said the following on 2/10/2008 3:18 PM:
If Window-Eyes executes your script in-process, then the script is
limited to those functions Window-Eyes makes the scripting engine aware
of, plus the COM objects that can be accessed by any script running in
Windows (Does this include things like WScript.Shell and
WScript.FileSystemObject, does anyone know?).
As far as whether using standard scripting languages like VBScript or
JScript opens up more paths of attack, all Window-Eyes is doing is
opening *ITS* properties, methods and events to COM clients (so, I
suppose, the potential is there for a Window-Eyes virus that might break
your settings, but negligibly more so, if at all, than a JAWS script
written for the same purpose). JAWS, you'll note, is also a COM client,
so that if it could create objects such as a FileSystemObject or a
WScript.Shell object (which, I'm thinking, are only creatable within the
context of the Windows Script Host (although I'll have to check some of
the code I do testing on to verify)), one could do just as much damage
as one could with a VBScript or JScript file written for Window-Eyes and
executed in-process.
*From:* programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] *On Behalf Of *John Greer
*Sent:* Monday, February 04, 2008 11:55 AM
*To:* programmingblind@xxxxxxxxxxxxx
*Subject:* Concern about the latest Window Eyes scripting move
Once I got over the initial shock and amazement at GWMicro's decision to
make Window Eyes scriptable. Especially in such a powerful way as to
let it be scriptable with many different scripting languages, I began to
think. Would that not also open Window Eyes and Windows up to a whole
new world of script based viruses? VBScript and Java Script are after
all 2 of the languages that have that sort of power. It just concerns
me a bit that in GWMicro's rush to become the top screen reader, that
they may have actually open the flood gates a bit too wide.
--
Raul A. Gallegos -- GW Micro Technical Support
Voice: 260-489-3671 -- Fax: 260-489-2608
WEB: http://www.gwmicro.com
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
