Text File

precedence: bulk Subject: Risks Digest 20.50

RISKS-LIST: Risks-Forum Digest Tuesday 27 July 1999 Volume 20 : Issue 50

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.50.html> and at ftp.sri.com/risks/ .

Contents: One year in jail for not turning off cell phone (PGN) Communications blackout in Morocco (David Mediavilla) Phone outage in Plano (John P Mcgraw) Double your treasure, double your fun... (Daniel P. B. Smith) ActiveX Security concerns continue (Richard M. Smith) DoD password management (Identity withheld by request) Misplaced priorities with electronic hospital records (John Doyle) Clinical disruptions following loss of telephone service (John Doyle) Re: Anaesthetists' equipment (Daniel Paul Sheppard) Re: Computer startup circuits (M. Simon) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Thu, 22 Jul 1999 22:16:11 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: One year in jail for not turning off cell phone

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>

------------------------------

Date: Mon, 26 Jul 1999 16:35:28 +0200 From: Mediavilla David <davidme.forum@bigfootNOSPAM.com> Subject: Communications blackout in Morocco

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

------------------------------

Date: Thu, 22 Jul 1999 08:57:07 -0500 From: "Mcgraw, John P" <john.mcgraw@eds.com> Subject: Phone outage in Plano

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

------------------------------

Date: Thu, 15 Jul 1999 21:02:42 -0400 (EDT) From: "Daniel P. B. Smith" <dpbsmith@world.std.com> Subject: Double your treasure, double your fun...

"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>

------------------------------

Date: Thu, 22 Jul 1999 22:12:27 -0400 From: "Richard M. Smith" <smiths@tiac.net> Subject: New ActiveX security problems in Windows 98 PCs

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.

------------------------------

Date: Wed, 21 Jul 1999 22:29:29 -0400 From: [Identity withheld by request] Subject: DoD password management

[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]

------------------------------

Date: Thu, 22 Jul 1999 12:37:33 PDT From: "John Doyle" <djdoyle@hotmail.com> Subject: Misplaced priorities with electronic hospital records

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

------------------------------

Date: Thu, 22 Jul 1999 04:52:19 PDT From: "John Doyle" <djdoyle@hotmail.com> Subject: Clinical disruptions following loss of telephone service

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

------------------------------

Date: Fri, 23 Jul 1999 16:19:50 +0100 From: Daniel Paul Sheppard <dps@Cs.Nott.AC.UK> Subject: Re: Anaesthetists' equipment (Doyle, RISKS-20.49)

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.

------------------------------

Date: Thu, 22 Jul 1999 13:11:28 -0700 From: "M. Simon" <mlsimon@mail.rkd.snds.com> Subject: Re: Computer startup circuits (RISKS-20.49)

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]

------------------------------

Date: 23 Sep 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.50 ************************