Security Vulnerabilities in the OptiGuide Screen Reader

October 26, 2012

OptiGuide claims to be "the first screen reader to provide access to Safe Mode". That may be true, but it’s also a security risk.
In brief, they allow open access to their website, as well as install a root certificate that includes the private key that attackers can use to make a website look trusted.
For details, see below. Uninstalling the latest version of OptiGuide appears to remove its certificate, but when I installed an older one (I tested with 1.0.55) and uninstalled it, the
certificate was not removed. You can check in Certificates/Trusted Root Certification Authorities. Search for ACCESSIBLESOFT and remove it.

After installation of OptiGuide 1.0.57, I noticed it installed a self-signed certificate into my root certificate store. Looking at the certificate properties for the ACCESSIBLESOFT\Operator certificate, this line stood out:

You have a private key that corresponds to this certificate.

I’m not sure what this is used for or why it is needed.

I wasn’t able to export it via the gui, so I looked at what imported it. The certificate is contained in OptiGuide_TemporaryKey.pfx in the program’s folder.

The first problem I had to solve was the import password that pfx files have. Running strings on InstallCert.exe finds it quite easily. Once this was found, I used openssl to convert it to a .pem and examine the keys:

$openssl pkcs12 -in OptiGuide_TemporaryKey.pfx -out test.pem -nodes
Enter Import Password:
MAC verified OK
$grep BEGIN test.pem
-----BEGIN PRIVATE KEY-----
-----BEGIN CERTIFICATE-----

This certificate is valid until October 20, 2013. Because it contains the private key and can be used for client authentication, I can quite easily set up a server that will use this.
Once done, Internet explorer will consider this as valid. Firefox uses its own certificate store, which doesn’t have this certificate.

Moving on, I lookd at the network activity when running OptiGuide.
I saw an ftp connection to utechaccess.com, where it proceeded to get Optiguide/Customers.txt.
Looking further, the ftp leads to the webroot of the main OptiGuide website, which possibly could allow the replacement of the OptiGuide setup executable. Because of this, I cannot be sure that the setup file hasn’t been tampered with.

I reported this on October 18, and new versions have been released since then with these same vulnerabilities. I feel it necessary to warn the community about this program,
and hope that these problems can be fixed for the future. Once they are, I will update this post.

Crash words in the Eloquence speech synthesizer

May 1, 2011

The Eloquence speech synthesizer is an old but popular synth used in many screen readers such as JAWS, Window-Eyes, and System Access, Cellphones, and notetakers.

It’s widely used, very understandable at high speeds and responsive. Despite that, it has at least one problem: it can crash when it reads certain words. With the way screen readers are designed, when the synthesizer crashes, your screen reader goes with it. After that happens, it can be difficult to reload, sometimes requiring the dismissal of error dialogs.

This leads to a question. Are the crashes simple crashes, or can they lead to buffer overflows and the ability to execute code via a carefully-crafted string? If code execution is possible, it might be difficult to get through the preprocessing most screen readers do; but there might be something else using it that does less. I don’t have the knowledge and experience to check for myself, but someone might.

What can we do about this? Unless the screen reader vendors release patches, not much, if Eloquence continues to be used. GW Micro has an Eloquence Fix script, which can easily be updated as new words are found. I don’t know of any fixes for the others. Recent versions of JAWS fixed a few of them, but not all. Unless strings are converted from unicode before checking (e.g. Python’s s.encode(‘mbcs’)), several characters in the unicode range can be used to substitute for the letters, defeating any simple regular expression. I think that the GW Micro script already does this. In the folowing section, delete the slash (/) character from the words listed. I’ve put it there to avoid crashing anyone using Eloquence to read this page. “Re: ” at the beginning says that this line is a regular expression describing part of the word See comments on previous line. These re’s might not be 100% correct, or might pick up false positives. Experiment a bit.

We need to worry about prefixes/suffixes for this one. E.G. re, anti, -ing, etc.
re: c/aesur.+

these next few all have one common pattern. A prefix ("h'", "j'", "s'", "x'", "z'") folowed by something else,
followed by "'re" or "'ve". I won't list the prefix/suffix, just the middle part.
Concatenate the middle parts with apostrophes to get endless combinations. e.g. prefix+a'b'c+suffix.
They don't seem to work in a sentense,
but if you can get them to read on their own they should crash. Experiment a bit.
Empty - prefix+suffix
s, d, hs, js, ll, xs, zs
re: bj+s
re: bx+s

Next, we have word+hesday and word+hesway. e.g.
wed/hesday. I think the word needs to end on a consonant.
But we also have, at the end of a word:
re: hh+s[dw]ay

This crashes, e.g. when next to a number or by itself, but not as part of a word. e.g. nietzsche won't crash.
tz/sche

Last updated: May 01, 2011

Impressions of Hal from Dolphin

December 19, 2009

These are my impressions of the Hal screen reader from Dolphin in no particular order, as I

continue to test it. I’ll update this as I continue evaluating it and in response to

comments.

The installation process went fine, but I had to press the setup button inside a WinZip self

extractor in order to get the talking setup to run.

If another screen reader’s mirror driver is enabled, Hal will break (mainly by not reading

certain list views and combo boxes).

Upon rebooting, Hal came up with Realspeak and walked me through its startup wizard, asking

me to set various options such as speech rate and character echo settings. It also asked me

to update its map files, which I allowed and had no trouble with.

It comes with Realspeak, Orpheus and Eloquence. Orpheus is the most responsive and has the

fewest problems. Realspeak sometimes will start speaking the next phrase while the current

one is ending, while Eloquence isn’t too responsive and pauses in strange places in addition

to the default annoying Eloquence pauses that haven’t been suppressed.

SAM (Synthesizer Access manager) loads every driver it has as separate processes into memory

at the same time, even for devices I don’t have, cluttering up the task manager.

Standard WinForms (.net) apps don’t work. I tested with EdSharp, and got very disappointing

results. The edit field was just read as “control”, while the menus didn’t speak at all.

While browsing the web, the standard control+enter keystroke for opening links in new tabs

doesn’t work. In order to do this, I have to press delete to right click, then go to the

menu item to open in new tab.

Mozilla Thunderbird (either 2.x or 3.0) is not supported at all, and gives no useful

information when tabbing around the interface.

While selecting by lines in notepad, the lines I’m selecting aren’t automaticly read.

List view fields are read in terms of screen text, so anything that doesn’t fit on the

screen gets cut off.

Capital letters aren’t announced by default. If turned on, Hal will announce “capital”

before any word that is capitalized, and mixed before a mixed-case word. There is an option

buried in the menus to change this to beep, but it’s either all or nothing; it can’t be set

to only announce when reading by character.

A distinction is made between the left and right modifier keys when talking about hotkeys.

For example, mute speech is set to left control. In order to use right control for this

purpose it must be added as an additional hotkey.

The hotkeys don’t repeat when held down, whereas every other key on the keyboard does.

Gathering passwords with the JAWS builtin keylogger

October 19, 2009

JAWS so helpfully contains a built-in script that logs all keys pressed on the keyboard. This method has a better chance of working on XP than the others. You must have a user account on the machine to make this work.

1. Open Keyboard manager, and open the default file. Add a key to the “ToggleKeyboardLogging” script.

2. Once done, log out of the machine. Your profile will still be loaded. Press that key. The only thing JAWS will say is “enabled”. Log into the machine, then open keystrokes.log in your jaws program directory. all keys pressed will be there, from the last time the script was enabled.

JAWS security flaw, round 2

October 19, 2009

In my First Post, I described a security vulnerability that allowed local users to gain system-level access to a machine. A quick test with JAWS 11.0.729, the release build of JAWS 11, reveals that it is fixed. Here is a slightly different set of instructions that will do the same thing.

1. From the login screen, press insert+j, and navigate to utilities/configuration manager.
2. When configuration manager opens, press control+o.

3. press the Import button. The open dialog will appear.

4. On my Windows 7 test machine, I got an error box that can safely be dismissed. Once done, type %windir%\system32\*.exe into the open dialog.

5. find cmd in the list, and press the applications key on it. Select Run as administrator if it appears. If not, keep following these steps.

6. From cmd’s context menu, pick select. answer no to the question asking you to overwrite settings files, if it comes up.

7. press import, and pick cmd from the list again. Activate the context menu, and select Run as administrator.

If done correctly, you should have an administrative command prompt.

Critical security flaw in JAWS

October 16, 2009

I have found a critical security flaw in the JAWS Screen reader that allows an attacker to gain full system-level access to

the machine. I have tested this on 32-bit Windows Vista
with JAWS 10.0.1154 and 32-bit Windows 7 with JAWS 11.0.611 Beta.

Instructions:

1. From the Windows logon screen with JAWS running, press insert+f2. Run JAWS Manager will appear.
2. Select Settings Packager, and press ok. Settings Packager will open.
3. From Settings Packager, go to File menu > Open, or press ctrl+o.
4. In the open dialog, type “%windir%\system32\*.exe” into the file name field (without the quotes) and press enter.
5. In the list of files, find cmd. Right click on it, or press the applications key and select Run as Administrator.
A system-level command prompt should open. To get out of it, type exit and press enter, then close the Settings Packager.

Update: audio demonstration available here.
 

Contact information:
tyler Spivey
Email: tspivey@pcdesk.net, PGP key: 0x048C58A4
Twitter: tspivey

My Thoughts on the Current State of Command Line Accessibility

November 14, 2007

I am a heavy user of the command line, and command
line oriented operating systems such as Linux and
OpenSolaris. I am blind,
and use a screen reader to access my computer. This means that
various things are inaccessible to me, such as captchas that have no
audio alternative. The command line,
being mostly text based, is almost perfect. I say
almost perfect, because the screen reading technology isn’t really geared
towards certain types of text. Consider that as new
text arrives, the screen reader will attempt to read it, from
top to bottom, left to right. This works perfectly
in programs such as ed, because I can type a command and get a response on the next line.
However, this all falls apart when certain classes of programs are invoked,
such as screen editors (vim, emacs), some parts of
mailers (pine, mutt), and tabular output
utilities (df, vmstat, prstat). These programs are in different classes and have
their own problems, so I’ll discuss them below.

Full screen applications

The problem with these is that a screen reader
doesn’t know that, for example, j will move
the cursor to the next line in Vim. Nor does it know that l
will move to the next character. if I type
j in vim, or ^n in emacs, the screen
reader will attempt to read what has changed on the
screen, which is usually nothing – just
the position of the cursor. At this point,
the screen reader isn’t sure if I typed a j because I wanted to insert a j, or
if I typed a j because I wanted to move to the next line. I can
attach, at least in the windows screen readers, a script to the j key, but that wouldn’t always be accurate due
to network delays and such – I have no way of knowing when the cursor
has successfully moved in order to read. This isn’t
a stop-all for screen programs, but personally, I would rather focus on
my work rather than hitting j, and then whatever
command my screen reader uses to read the current line. This gets
progressively more annoying when I attempt to move by character – character right, read
current character. There are scripts tied to the arrow keys, but those sometimes don’t work, and conflict with
the automatic echoing of newly written screen text. Ed is great,
but it’s not so good for writing emails that are
expected to be word wrapped, nor is the lack of an edit current
line function beyond ^u and ^w – if I realize that
I’ve made a typo at the beginning of the line, I have to either kill
the line and retype it, or hit enter, fix the typo and keep writing.

Tabular Output Programs

Tabular output programs produce output in a columnized table format,
for example:

Filesystem             size   used  avail capacity  Mounted on
fs/home/tyler          109G    86G   4.1G    96%    /export/home/tyler

This is a rather simple table, and mostly self explanatory. I’ve used
the df command so many times, and it doesn’t have too many columns, so I can find out where
I am relatively easily. But in contrast, take this vmstat output:

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr dd dd f0 --   in   sy   cs us sy id
 0 0 43 428760 14456  1   4  3  1  1  0 51  6  0 -0  0  426  106  109  1  3 97
 0 0 52 416600 21632  1  23 105 0  0  0  0  0  0  0  0  851  490  276  1  7 93
 0 0 52 416600 21632  7   7  0  0  0  0  0  0  1  0  0  801  489  263  1  6 93
 0 0 52 416600 21632  7   7  0  0  0  0  0 19  0  0  0  942  410  451  0 26 74
 0 0 52 416600 21632  7   7  0  0  0  0  0  0  0  0  0  813  475  246  1  6 93

This table has approximately 22 columns, with different sized numbers. I can bring my
screen reader’s cursor to, say, the SR column, and go read down by words, but if a 100 suddenly
changes to a 0, the number will move and the screen reader will get confused on which way to go -
left or right – to find it again. I can find myself
reading some other column that I don’t intend to read, but might not notice. Of course,
reading this from top to bottom, left to right is impossible.

I propose a solution to all this. A screen reader, in userspace, that will
wrap the shell and provide commands for moving around. While such
things exist, for example
YASR,
I feel that there should be an easily modifyable,
extendable screen reader, perhaps written,
as the Orca project for gnome,
in Python. Orca is all
well and good for the Gnome desktop, but it’s terminal support feels like it was
added on as an afterthought, at least to my view of
working. I want something that is
stable, reliable and customizable. In-kernel
screen readers are great if you want to view the boot messages, and are even nessisary for certain
types of recovery operations where a serial console is unavailable, but this adds the complexity of
kernel development and restricts the languages that they can be written in.


Follow

Get every new post delivered to your Inbox.

Join 289 other followers