Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Neil Whitehouse has been convicted of ``recklessly and negligently endangering'' a Madrid-to-Manchester British Airways flight with 91 passengers. Despite multiple warnings, he refused to turn off his cell phone. He was sitting over the aircraft's fuel tanks in the wings. <http://www.zdnet.com/zdnn/stories/news/0,4586,2298512,00.html?chkpt=hpqs014>
According to the Spanish paper "El Pai's", http://www.elpais.es/p/d/temas/hassan/7has25b.htm (in Spanish) : Since Hassan II (king of Morocco) was entered in the Avicena hospital (in Rabat) until his death was officially confirmed, 4 hours passed. In that time, the Moroccan news agency MAP halted service, mobile phones stopped working and Internet connection was down. David Mediavilla Ezquibela
The *Dallas Morning News* reports that 100,000 people in Plano, a Northern Suburb of Dallas, were without phone service for 9 hours when a battery failed in the switching office. I have been told that this office has two power sources coming from different grids, but it appears that they still have a single point of failure. The 911 service was out as well, and I was told that a house in my old neighborhood was badly damaged by a fire when the owner could not reach the Fire Department. <http://www.dallasmorningnews.com/metro/0721met1phones.htm> John P, McGraw, CISSP, Plano, TX 75024 1-972-605-6949
"Treasury Direct" is the long-established U.S. Government service that enables individual consumers to buy U.S. Treasury securities directly from the government. Normally the securities are held in an account, and interest paid by direct deposit to your bank account. A few weeks ago, I used the Treasury Direct Web site, http://www.publicdebt.treas.gov/sec/sectdes.htm, to purchase several thousand dollars worth of Treasury securities. It was very easy. A little too easy, it turns out. First, Web access was automatically available to me, simply because I have a Treasury Direct account. I did not need to request or authorize it. This means that, in all likelihood, millions of people have Web access to their accounts and don't even know it. Second, I only needed two pieces of identifying information for full access: my account number, and my Taxpayer Identification (Social Security) number. Conveniently, both of these are printed together on every one of my Treasury Direct statements. Third, it appears as if no special authorization is needed to enable purchases--the same authorization that lets them deposit small amounts of interest to my account also allows them to withdraw large sums to cover my online purchases. This all seemed a little flaky, but some part of my brain was convinced that since Amazon handles $32.95 purchases _perfectly_, it MUST be OK to buy thousands of dollars worth of Treasury securities via the Web... and I wanted to buy the securities... and I didn't feel like hassling with phone calls and forms... so I went ahead and clicked the button. I placed the order on 2 Jul, for delivery today, 15 Jul. I felt warm and secure because the screen display, which I immediately printed, showed all the correct information together with a confirmation number. Tonight I found that exactly twice the amount I authorized has been deducted from my bank account, and exactly twice the amount I meant to purchase is recorded as being in my Treasury Direct account. Now, Treasury securities are not a bad thing to have, and buying twice as many as I planned to is not the worst thing that could happen, but, among other things, this happens to leave the balance in my bank account slightly too low to cover an outstanding check I wrote to the IRS... Only time will tell whether this is a small problem that the Treasury folks will straighten out quickly and cheerfully... or whether this is the start of a vast bureaucratic Kafka nightmare that will leave me an embittered, enfeebled, quaking wreck. (HOW am I going to PROVE that I DIDN'T click the button twice? And that I DIDN'T get a SECOND screen with a second confirmation number?) Meanwhile... the RISKS are obvious. Daniel P. B. Smith <dpbsmith@world.std.com>
At work, I recently started using a new HP Pavilion computer that is running
Windows 98. As part of ongoing research into Internet security issues, I
discovered that this computer was shipped with 2 ActiveX controls, which are
extremely dangerous. These controls can be easily misused on a Web page to
gain access to the computer and run programs. More worrisome however script
code can be embedded in an HTML Email messages and the controls accessed in
Outlook, Outlook Express, and Eudora. The controls are marked "safe" for
scripting even though they can do things like launch programs and read and
write the Windows registry.
Using these controls, some of the malicious things that can be done include:
- Automatically install a computer virus or other malicious software
on a system.
- Turn off all Windows security checking, making a system wide-open
for future attacks.
- Read personal files for the local hard disk and silently upload
them to a remote Web site.
- Delete document files from the local hard drive.
- Remove Windows system files so that a system can no longer be booted.
With less than 30 minutes of effort, I was able to construct a test Email
message that downloads a Windows executable file from a remote FTP site and
installs it on the local hard drive using one of these ActiveX controls.
After the file is successful installed, it then is executed. For my test
message, I download and run the Windows calculator. However, the Email
message can download any Windows program such as the ExplorerZip virus or
Back Orifice 2000 install program. In Outlook Express, this all happens
automatically when the Email message is read. There are no attachments that
have to be clicked on and no warnings with default security settings.
My test Email message contains only about 10 lines of JavaScript code to
direct one of the HP ActiveX controls to do the download and run the
program. Anyone with experience in JavaScript programming could easily
duplicate the code that I wrote. For obvious reasons, I will not be
publically releasing this test Email message.
Microsoft's Authenticode security system built into Internet Explorer is of
no use here because the ActiveX controls are pre-installed on the computer
and not downloaded from the Internet. Authenticode only allows users to
prevent downloading of questionable ActiveX controls, not their execution
once they are installed on a system.
The ActiveX controls are shipped on the HP system for use in system
diagnostic package called SystemWizard. This package is a product of
SystemSoft (<http://www.systemsoft.com>). The intention is these controls
would only be used in SystemWizard and no where else. However, because the
controls are marked safe for scripting, any Web page or Email message can
use the controls in any manner they like. The controls either never should
have marked safe in the first place or the controls need to do their own
security checking. Unfortunately neither precaution was taken.
The two SystemSoft controls are just thin wrappers around a number of Win32
system calls. The Launch ActiveX control allows a JavaScript program to run
a DOS or Windows program and pass in command line parameters. The RegObj
ActiveX control allows a JavaScript program to read, set, and scan registry
keys. The controls are accessed on a Web page simply by including an HTML
<OBJECT> tag with appropriate parameters. Pretty obviously, it is not a
good idea to allow JavaScript programs to make direct Win32 system calls
with such ease!
To give an idea how easy the Launch control is to misuse, the following
JavaScript call will remove the contents of someone's entire "My documents"
directory using the old DOS deltree command:
Launch('c:\\command.com', '/c deltree /y "c:\\My documents\\*.*"');
Both of the SystemWizard ActiveX controls were created last year and my
understanding have been shipped on most HP desktop systems in the US retail
channel for at least the last 6 months. The number of computers, which are
vulnerable, is therefore quite substantial. The same controls may also
being shipped on other brands of computers.
After being alerted to the problems of these two controls, SystemSoft is
providing a patch file to fix the security holes. This patch file can be
downloaded from their Web site at this URL:
<http://www.systemsoft.com/support/syswiz/index.htm>
In addition to the two SystemSoft ActiveX controls, I also found an another
ActiveX control pre-installed on the HP system with a privacy leak in it.
The control can give out Windows 98 registration information such as name,
address, and phone number to a Web site. This control was supplied by
Encompass Corporation (now part of Yahoo) and is used in an ISP sign-up
program. The control is marked safe for scripting on a new computer, but is
marked unsafe for scripting the first time dial-up networking (DUN) is used
on the system. This issue is specific to this machine/build of the
software. Unfortunately on my HP system, I use a LAN connection to access
the Internet and therefore the Encompass control stays marked safe for
scripting forever and could give out registration information (limited to
name, address, phone number) to a malicious person. Since I didn't use the
dial-up portion of the ISP sign up, I just removed the registration
application by going to the add/remove program files and choosing the "Easy
Internet Access" application. The control also remains safe for scripting
if one uses AOL as an ISP because AOL does not use DUN support in Windows
98.
Since Encompass has distributed versions of the software on a different
machines, I've put together a demo page that will test a system to see if
the system has a version of the control that could release registration
information to a malicious person. The test page can be found at:
<http://www.tiac.net/users/smiths/acctroj/reginfo.htm>
I also upgrade from version 4 of Internet Explorer to version 5 on the HP
system. Unfortunately this upgrade installed yet another dangerous ActiveX
control on the system. This control is the DHTML editing control, which can
be easily misused to read files from the local hard drive and upload them to
a Web server. This bug was discovered in March 1999 and has been fixed by
Microsoft but the majority of IE5 users still are vulnerable because not
many people know about the problem. A security bulletin and patch for this
ActiveX control can be found on the Microsoft Web site:
<http://www.microsoft.com/security/bulletins/ms99-011.asp>
How did so many of these insecure ActiveX controls get installed on my
computer in the first place? Because Internet Explorer (IE4 or IE5) comes
bundled with Windows 98, it is becoming an increasing popular for computer
manufacturers to build specialized utilities for their PCs using IE4 just
like HP has done. These utilities include registration software, ISP
sign-up programs, and shells for running common applications. With Internet
Explorer 4 it is very easy to develop user-interfaces for these types of
utilities using standard HTML pages. ActiveX controls are then typically
used in these applications to provide low-level access to the Windows
operating system to do things like run applications, access the registry, or
read and write files. These controls are only suppose to be used inside the
applications they are designed for. However, IE4 has no built-in mechanism
for restricting use of a particular ActiveX control to be used with
particular Web pages. Therefore it is up to application developer to
provide a security mechanism in their ActiveX controls.
After looking at the problems of the HP system, I decided to check out other
new Windows 98 systems from other computer manufacturers for similar unsafe
ActiveX controls. The first thing I discovered that is very common for
manufacturers to ship utilities built as Web pages on their computers. Most
of these applications included ActiveX controls for doing things like
running programs and accessing the registry. The controls had names like
"SpawnApp", "SafeLanuch", "RegRead", and "Run". However, because I didn't
have direct access to these systems, I have no method to test to see if
these controls can be misused or not. Because their is no built-in security
system in place for pre-installed ActiveX controls it is up to the person
who writes the control to make sure they are safe. I have inquired to a
number of computer manufacturers about the controls I saw, but so far have
not received back any responses. Given the subtle nature of ActiveX
security issues, I wouldn't be surprised that other computer models have
serious security problems also.
A typical Windows 98 system today ships with about 50 pre-installed ActiveX
controls that are marked safe for scripting. Because ActiveX controls are
Win32 programs it's not possible to really know if a control is really safe
or not. The developer's claims about safety cannot necessarily be trusted.
Without systematic and detailed testing it is not possible to know if given
control is really safe. I don't believe full testing is really being done
today. For example, here is information about another Microsoft ActiveX
control that is still being distributed with the Windows 98 Resource Kit
today:
<http://support.microsoft.com/support/kb/articles/Q218/6/19.ASP>
This Resource Kit ActiveX control allows Windows programs to be
executed from a Web page or HTML Email message.
What can users do about all of these different ActiveX security holes? One
approach is download patches to fix security holes as they are found.
Unfortunately for most user's it is not possible to know what ActiveX
controls are even installed on their system, never mind knowing which ones
are really safe. It might require going to 4 or 5 different Web sites just
sees what security patches are available. A pretty impossible task for
almost anyone.
One easy thing users can do is completely turn off ActiveX controls in
Internet Explorer. This is done on the security tab of the "Internet
Options..." command in Internet Explorer. This option however is only
available if the Web site that one goes to don't use ActiveX controls.
What can computer manufacturers and software companies do about the problem
of security holes in pre-installed ActiveX controls? As it turns out,
Internet Explorer 5 already offers a great solution. IE5 supports a new
feature called HTML applications (or .HTA files). An HTML Application is
built like a Web page but can only be loaded and execute from the hard
drive. Because an .HTA file comes from the local drive and not the
Internet, scripts on the page are a completely trusted and are allowed to
use all ActiveX controls installed on a system whether the controls are
marked safe or not. For an HTML application, none of its private ActiveX
controls have to marked safe for scripting and therefore the controls cannot
be misused on Web pages.
For current systems, my recommendation is that computer manufacturers need
to review carefully all the ActiveX controls which are pre-installed on
computers that are going out the door. In the review, each control needs to
be checked for potential security problems. It is particularly important to
look at controls, which make Win32 system calls to load and execute other
programs, read and write files, and access the registry.
I've created a Web page on my personal Web site that will check to see what
potentially unsafe ActiveX controls are installed on a system. The URL for
the test page is:
<http://www.tiac.net/users/smiths/acctroj/axcheck.htm>
Security problems with ActiveX controls have been a concern for a long time,
because these controls are binary programs that are allow to make any kind
of Windows system call. The industry has mostly been worried about ActiveX
controls that were intentionally created with malicious code. Microsoft
addresses these concerns with the Authenticode security system which allows
users to decide if they trust a particular author enough to run controls
that the author has written. Authenticode is based on adding digital
signatures to controls.
However, the pattern I see here is a much different issue. Instead we have
computer and software vendors installing ActiveX controls on systems without
any notification and these controls for whatever reasons contain security
holes in them. As I've pointed out here, I found 4 different ActiveX
controls on my HP system for 3 different vendors which compromised the
safety on my system. Not exactly a great track record! Going forward I
hope that PC makers take a closer look at that the ActiveX controls that
they are shipping on their systems. You never know who might be using that
hidden-away ActiveX to create problems for us computer users.
[This message is from Department of the Army civilian who has had Military active duty (53) system administration duties. His or her identity is withheld for obvious reasons. PGN] I am an employee (15 + years) in the Department of Defense. In the last few days I have received the most ludicrous requirement yet. It applies to every part of DoD. It requires us to change every password on every system and then power down and power up the system. I have been told this was signed off by the Secretary of Defense upon urging by his Joint Task Force for computer security. For Army systems, this came in the form of a majordomo message. Last night I found out that it the aftermath of an incident. Prior to this knowledge, a lot of us thought that this was just an exercise. When the initial message came in, MACOMS (Major Army Command typically 4 stars), RCERTS, and other institutions were called to see if this was a hoax. It turns out it wasn't. They actually want us to complete this requirement in less than 4 weeks. Initially, we weren't told the reason for the requirement — just to get it done. Shortly thereafter, we received another report that tells us (1) not to use the word "password" when directing our users to do this, (2) to use verbiage to our users explaining the need for the password change that is untrue, (3) to have the users change their passwords themselves rather that have the system force them to do it. On (2), I don't think they intentionally wanted us to lie; just obscure the reasons. I first take issue that they have us (Sys Admin/Net Admin) mislead our installation users (another risk). Along with every IT (govt. employee, contract, military) person whom I have talked to at my installation, I think this requirement is overkill. In addition to using a lot of resources, it causes us the question the credibility of the people who are making these decisions. This in itself is a major risk. Other thoughts: 1. Some people and sysadmins have about (3-7) passwords for various systems. If they have to change all their passwords they are likely to recycle the same passwords, on different systems. 2. I have spoken with my counterparts at different Army installations. For the most part they want to define the problem away (i.e., NT domain account is not computer account — it is a resource account). DoD is starting to take computer security seriously. However, they are using sledgehammers to stamp out flies. By doing this they make us (sys admins/net admins) question their capabilities. There are several issues here. (1) military Vs civilian, (2) overreliance on FUD contractors, and (3) honesty between levels of commands. [Signed] A concerned but disillusion DoD employee [There are certainly some pockets of enlightenment within DoD, but there are also some incredible examples of ostrich mentality, with heads in the sand. By the way, changing passwords does not help if sniffers are already in place. The deeper problem, familiar to RISKS readers, is the pervasive use of fixed passwords in the first place. PGN]
As most workers in healthcare computing know, the electronic hospital record is becoming increasingly important, as it offers a number of advantages over traditional paper records. Nevertheless, there are a number of conveniences associated with paper medical records, just as many individuals prefer to read a paperback book over reading from a video monitor. In my hospital, a large metropolitan teaching facility, patient demographic data (age, height, weight, allergies etc.) are collected at a computer workstation and stored electronically as well as printed out as part of the paper chart. Although I am very computer literate, in my routine hospital work I prefer to use the paper chart not only for its speed of access (our network can be frustratingly slow in times of peak load), but also because it is simply far more convenient to use at the patient bedside. Whenever I write an order for a drug to be given, I naturally check the patient printout to search for identified drug allergies. Unfortunately, it can sometimes be difficult to find the entry for allergies, since it is not highlighted in any way in the monotonous paper printout. Believing that easy recognition of allergies in the paper record would be in the best interest of the patient (as well as in the interest of the hospital, I might add) I called our hospital computer services department to suggest that allergies be noted in an easily recognized bold or italic font. After all, I knew from experience that the implementation of this was usually fairly trivial, merely involving some simple printer escape codes. Their reply surprised me. I was informed that this request would not be a priority, as their policy was that the electronic record was far more important than the paper record, regardless of my personal preferences. Thus, attention to improvements the paper record would happen only when the long list of planned improvements to the electronic record was completed. In fact, they pointed out that they saw the eventual elimination of the paper record as a good thing, regardless of what any physicians "in the trenches" might feel about any difficulties that might arise as a result. That was their decision, period. Since improvements that would be expected to lead to a reduction in drug administration errors is an obvious good (at least in my eyes), the attitude and decision suprised me. Perhaps they might feel differently if a family member received an inappropriate drug by mistake. D. John Doyle MD PhD FRCPC, University of Toronto and Toronto General Hospital djdoyle@home.com http://doyle.ibme.utoronto.ca
As noted in an earlier posting in this forum, the recent loss of telephone service in downtown Toronto disrupted life for many individuals. At my hospital the loss of outside telephone access, Internet access, paging services and Bell Canada cellular telephone service lead to special challenges. No electronic paging of physicians and other personnel was possible. Overhead voice paging helped in some cases, but this system does not work in our operating rooms! Because of the potentially life-threatening issues involved, a number of surgical cases were cancelled, including my second cardiac case. Regrettably, because of well-known backlogs in the Canadian healthcare system, some cancelled surgical cases may not be rescheduled for some time. D. John Doyle MD PhD, Associate Professor, Toronto General Hospital / University of Toronto djdoyle@home.com http://doyle.ibme.utoronto.ca
I read with horror John Doyle's article in 20.49 about the patient monitoring systems regularly used in anaesthesia. The article seemed to suggest that a typical arrangement for such devices is that a number of sensors are connected to a single unit, under control of a single software system, to be displayed on a composite display. The problem being that when a system crashed (for whatever reason) the system needed to reboot, depriving the anaesthetist of sensory data during that reboot, and losing important calibration data. Surely, a better design for such a system would be a number of quite separate autonomous units, perhaps with low resolution output, or even (in some cases) numerical displays or just flashing LEDs. These could be connected to a separate device which collated the information and displayed it in a convenient form on a high resolution display. If this display crashed, then calibration data stored in the sensor units would not be lost, and all the data would still be available (in a less convenient form, and without cross correlation, admittedly). If one of the sensor units crashed, then a trace would be lost on both the unit and the display, but other sensors would remain. Perhaps the principal justification why units are not built in this modular way is one of cost.
I am overwhelmed by the response. My favorite language is FORTH. Easy to learn. Easy to write. Easy to debug. Well written (easy to teach) it reads like English. Interactive. Compiled. Modern versions run as fast as compiled C. Fed Ex uses it in all their portable package tracking terminals. Sun uses it as the boot language of every Sun terminal (Stop A) Your astronomy observatory probably uses it to run its telescopes. Hardware/Software design should be the way to go in embedded systems. No more separation of the disciplines. There is no way to reasonably teach the complications of C in addition to teaching hardware design. Not enough time. It would add at least a year to the curriculum. Simpler easier to learn languages mean fewer errors. Easier to test languages mean fewer errors. The current favorite 'C' is not easy to write and not easy to test. And yes I have made a living writing C programs. A very good living (I really do love inefficient languages from a personal $$$$$$$$ perspective) M. Simon [GO(TO) FORTH and multiply? PGN]
Please report problems with the web pages to the maintainer