An article `Windows added to cockpit choices' in Flight International, 5-11 November 1997, p 25, explains that the US company Avidyne has certificated an avionics system based on Windows NT. The hardware supplier is Electronic Designs, who has recently received approval from the FAA (approval for what is not specified). Avidyne is apparently working on Level-C approval, which will allow use of its moving-map display for IFR navigation. One of the benefits is said to be the wide range of interfaces available to other devices. This is for general aviation. The first Supplemental Type Certificate (required FAA documentation for installation) is for a Mooney piston single. One major drawback could arise from the hardware. It was pointed out in RISKS-19.45 (many authors) that the Pentium and Pentium MMX chips may be halted by execution of a single instruction in any mode, independent of any memory protection in the operating system. This instruction (in machine language) is F0 0F C7 C8 in hexadecimal. If Electronic Design's box is Pentium-based, the FAA could therefore shortly be asked to certificate a design for IFR flight that can be halted in mid-use. Unavoidably. By a few lines of software that are trivial to write. I would hope I am not alone in feeling very uncomfortable about the precedent this might set for acceptance procedures for COTS products in safety-related environments. This is a static bug, so programs are already available (see RISKS-19.45 for one) which sweep through your software to determine if this instruction is somewhere therein. But I wonder if the FAA will insist that Avidyne install such programs and make it a required part of the use of the equipment that this program is run as part of the pre-flight check before flight under IFR? However, even this does not guard against programs which dynamically generate this instruction. For the history of a dynamically-generated instruction that halted the Shuttle flight-control software in 1981, recounted at length in the Communications of the ACM 27(9), September 1984, pp.874-900, see our compendium `Computer-Related Incidents with Commercial Aircraft' available at http://www.rvs.uni-bielefeld.de Peter Ladkin
[Reference: http://www.usatoday.com/form/colsong.htm] Last week (3 Nov 1997), *USA Today* held a survey on the sports section of their Web site asking readers to rate their favorite college fight songs. Many college students and alumni consider their teams, marching bands, and fight songs, as matters of strong personal pride. Combine this with a high level of technical expertise at many universities and a college student's traditional predilection towards mischief, and it's not too surprising that some anonymous fans apparently wrote scripts to automate voting, overloading USA Today's web servers with traffic and forcing them to end the survey as of 11/10/97. According to the web page cited above, one Michigan fan voted 60,000 times in six hours; that's 167 times per minute, or 3 hits per second; nearly any web server would be crushed uner that kind of load in addition to normal traffic. Similar events have happened before; in March 1996, ESPNet (http://espnet.sportszone.com/ ) held a survey for the "Best College Mascot;" their servers were brought down by poorly-written scripts run here at Stanford rooting for Stanford's Tree mascot; the Tree was subsequently banned by ESPNet from participation in future "Best Mascot" surveys for five years. (Reference in the Stanford Daily: http://daily.stanford.org/4%2D1%2D96/news/newtreegate01.html) These surveys, of course, have no purpose other than entertainment; there are no prizes other than pride for winning. Hence, people who are technically-literate enough to write automated voting scripts, but not enough to realize their impact on a web server, feel no compunction about what would otherwise be considered major "cheating." Adam Elman, Software Developer, Highwire Press Adam.Elman@stanford.edu http://highwire.stanford.edu/
Robert X. Cringely's article begins at <http://www.pbs.org/cringely/archive/nov697_main.html>. "Still, there are some things a big company can do that a small band of programmers could never hope to accomplish. This was best shown to me this week by reader Brian P. McLean, who points out that according to his Microsoft Outlook 97 scheduling/datebook application, Thanksgiving falls this year on *Wednesday*, November 26. "Thanksgiving has always fallen on Thursday before. Wednesday may be an improvement. I don't know."
It was recently reported in the story "Hackers break into Macedonian Foreign Ministry phones," by Vladimir P., Central & East European CrimiScope, http://www.ceeds.com/cee-crimiscope/sa/content/en/cee/199711/19971115-v84.htm, and Central & East European Secure Systems News, that theft of telephone impulses is a new kind of threat facing Macedonia. Arabic speaking criminals have cracked a simple 4-digit code on card-based telephones, enabling them to call free-of-charge all over the world, according to CEE CrimiScope. In many cases, the default code of 1111 is never changed and even when another code is set, it often remains unchanged for years. The risk is not only that companies and organizations will lose financially due to higher phone bills but also that they might be sharing their proprietary information, and that of their business associates, with tech-savvy listeners. From the story: "All that a potential hacker needs to do is the following: First, a call must be placed to the (inadequately) protected telephone station (switchboard). When the taped message starts playing, the hacker dials a "nine" followed by the four-figure secret code number of the telephone station. If the code still happens to be the manufacturers default code (1111) - the job is done! However, if the code is not the default, the hackers begin their guessing game." -- Steven Slatem, firstname.lastname@example.org, Editor-In-Chief, Central & East European CrimiScope, Central & East European Secure Systems News, http://www.ceeds.com/cee-crimiscope http://www.intellitech-media.com/ceesn
[Lloyd sent a long registration form and questionnaire for the first Y2K-related spam he's aware of. +44-1483-300800x3641, <L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>] MAKE MONEY FAST!!! fixing Y2K problems! The 'Experience with programming is NOT required!/Experience with computers is NOT required!/Experience with computers is needed!/Experience with software is needed!' will give any RISKS reader pause for thought. [The questionnaire asks for your credit-card number, $24 to register you, for which you will be sent a test. If you pass the test, you will be listed in their database as Y2K Test Certified along with your test score, which allegedly will be "helpful in selecting people for positions that might require a higher skill level." They also want to know if you will be willing to travel in your new role as a Y2K expert. PGN]
C|Net reports that the Craig Nowak, of C.N. Enterprises of San Diego, has been ordered by a Travis County (Texas) district court to pay $19,000 in damages for sending spam which incorrectly identified 'flowers.com' as the originating domain. The owners of that domain, Tracy LaQuey Parker and Patrick Parker, Zilker Internet Park (their ISP), and the EFF-Austin sued for damages after they were forced to deal with thousands of bounced messages -- an onslaught which temporarily took down their mail server [as noted in RISKS-19.19 and 20.] Reference: http://www.news.com/News/Item/0,4,16393,00.html Bear Giles <email@example.com>
There is a small town in northern Pennsylvania where there is at least one case of identical twins that are named Jim and James. (The twins go to the same hospital to receive their medical care which is how I know about the situation.) So far there are no known mishaps at the hospital regarding their medical records, but surely it's an accident waiting to happen, both at the hospital and in any other computer databases. A few comments: If Jim and James receive their first service from an organization at the same time, that's safest for them since there will be two records set up initially. If Jim goes first and gets a record created and James then tries to obtain service at a later date, it's more likely that their records will be combined. Ironically, this is one case that computers are likely to get right if left to their own devices. Computers easily recognize Jim != James. But computers are rarely left to their own devices and it is a human operator who is likely to tell the computer to update the wrong record. (Same address, same birthdate, "same" name -- they must be the same person!) There is plenty of opportunity for mixups when Jim and James have an interest in keeping the records straight. Imagine if one of them tried to create trouble for the other! We'll probably hear about Jim and James again if they ever order e-tickets on the same flight. -Michael J. Zehr
Within 24 hours of being told about a buffer-overflow bug in Internet Explorer 4 discovered by DilDog at the University of Massachusetts, Microsoft announced a patch. The bug resulted from a URL longer than 256 characters, which allowed IE4's HTML interpreter under Windows 95 version A to arbitrary execute binary code at the end of the URL. DilDog had noted that the bug had existed for six months, and had survived Microsoft's 10,000-person beta test -- despite this being a characteristic flaw that should have been detected. [Source: Hacker Reveals Serious Security Hole in IE4, culled from pcworld online, 12 Nov 1997. PGN Very Stark Abstracting]
By now I'm sure you've heard about this delightful synergy: > ------- Forwarded Message > Date: Tue, 11 Nov 1997 06:53:45 -0500 > From: "Per Hammer" <firstname.lastname@example.org> > Subject: New IE4 security hole exploited ... > > http://www.wired.com/news/news/technology/story/8429.html > > The deal is, if your use a 'RES://' URL that us longer than 256 characters, > byte 257 onwards will be executed as machine code. Now ... think ... > F0 0F C7 C8 > > Which is only slightly less malicious than deleting any files ... > > Per Hammer email@example.com
Intel Corp announced that a fix to the Pentium & Pentium/MMX microprocessor flaw has resulted from Microsoft, Sun, and others modifying their operating systems to block fatal instructions. See http://www.intel.com .
To my surprise, it turns out there's a fairly straightforward workaround for the new Pentium flaw, and at least one vendor, BSDI, has already released system patches. Contrary to rumors, it doesn't involve turning off caches or anything like that, it's a way of arranging the interrupts in a way that preempts the hang with a higher priority interrupt. I gather there's also patches available for Linux. Here we have kind of a reverse risk -- the increasingly ubiquitous Internet made it possible to diagnose the bug and distribute a fix in a day or two at very low cost. John Levine, firstname.lastname@example.org, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner PS: I don't see any reason that the same technique wouldn't work in Windows, though I can't see any evidence that Microsoft is doing anything about it.
Another case of the media `not getting it' about computers appeared in the *San Jose Mercury* on 11 Nov 1997. The report on the latest Pentium flaw said that the flaw was exploitable by applications written in C or languages derived from C (whatever that means). Since it's unlikely that any C compiler will ever be so foolish as to deliberately generate the particular instruction in question, this misses the point. What is perhaps more confusing is that I've heard that Microsoft's implementation of Java will allow the execution of machine code. A malicious Web page could then become a Pentium-killer by including the defective instruction in its Java code. Thus the problem, while not present in Java, could arise from executing a Java program. I suspect the newspaper's confusion arose from the fact that an `exploit' of the flaw was demonstrated by a small C program that coerced an array containing a series of bytes that implemented the defective instruction into a function call. Including that C code snippet in a program would indeed exercise the flaw. But the flaw is C-related only in the sense that the flaw is Java-related because it could be invoked in Microsoft's Java implementation. -Fred Gilham email@example.com
Not only can one create a C program to execute this opcode, such a program doesn't actually have to contain the sequence F00FC7C8. A program could build this up by bitwise or arithmetic operations, which implies that scanning programs like Sam Trenholme's won't find a properly written malicious program. Also, by simply using Emacs or another editor, one could enter this string into an existing binary and not have to compile a line of code. Ahh, the possibilities. Nicholas C. Weaver [The possibility of self-modifying code was noted by many others as well. PGN]
In RISKS-19.45 a perl script to find the dreaded Pentium flaw was posted. There is a risk that some might believe the script will protect their systems. False. It is quite trivial to `hide' the killer code so a search for 0xf0 0x0f 0xc7 0xc8 will fail. Several such hidden exploits were recently posted to the bugtraq mailing list. What is interesting is that BSDI has just announced a binary patch to their operating system that is supposed to cure the problem. No information was given as to the nature of the patch. The release notification specifically stated: We are not at liberty to discuss the mechanism of the workaround at this time. More risks?
Earlier, I'd written and RISKS-19.45 had reprinted: >The following perl script, courtesy of Sam Trenholme via the security >mailing list at Redhat Software is reported to find _all_ occurrences of >this code sequence on systems running Linux... As has been pointed out to me by Jeremy Radlow (firstname.lastname@example.org), there's really no way reliable way to detect this code sequence, since trivial run-time manipulations of the sequence renders it invisible to simple filters. Therefore, I'd encourage readers _not_ to rely exclusively on that perl script to catch the problem. Steve Siegfried email@example.com
While I'd rather there wasn't "halt and catch fire" instruction for the Pentium, programs that crash the PC aren't exactly rare. Jon Strayer, Software Solutions Group, Ameritech, Indianapolis firstname.lastname@example.org (317) 265-4037
The recent Pentium crash flaw scared quite a lot of people. Fortunately there was an acceptable workaround this time (http://www.news.com/News/Item/0,4,16312,00.html), but it still gives us something to think about. Hardware is getting more and more complex and keeping serious bugs out of it is getting quite difficult. Imagine a bug in a popular processor that would let users run privileged commands (there's no way the operating system can stop broken hardware from doing anything it likes). The bug would be impossible to fix without replacing the chip (even with these new microcode update possibilities that newer chips like ppro/pII have, another risk by itself, although I believe the updates are not permanent, but reloaded each time the machine boots making the problem very small). Obviously replacing millions of chips is extremely costly. A bug like this would basically make every modern secure multiuser operating system that runs on that processor into a multiuser windows 95. Even if you can trust the users, there's always some static buffer in a program (web browser, mail reader, first alpha version of someones latest project) that malicious people can overflow from the outside and thus run their code and do whatever they want with the machine (without the hardware bug the damage would be limited to one user) The risk should be obvious, a single serious flaw in a popular processor could have some very dramatic effects (there are millions of Pentiums out there, many of which are in extremely critical places) Pekka Pietikdinen, Net People Ltd., Oulu, Finland
Here is how to use DEBUG to create a DOS executable that exercises the new flaw. DEBUG is available on DOS, Windows 3.x/95/NT and OS/2, and maybe others. At the command prompt, do the following: C:\TEST>debug -e 100 f0 0f c7 c8 -n kill.com -r cx CX 0000 :4 -w Writing 00004 bytes -q C:\TEST>KILL
[An earlier version of Jeff's message appeared to have identified a possible denial of service problem. After several iterations with a few of the respected occasional RISKS referees, this is the upshot of what apparently really happened. PGN] A co-worker who wishes to remain anonymous came to me with a problem. He had been visiting sites that he likely should not have, and somehow wound up with an advertisement on his background screen, one that was rather inappropriate on company equipment. It took some digging to find out how it came to pass. A quick look at settings showed that the display settings had been changed to make "netscape wallpaper" the default background. Apparently what happened was a simple UI slipup. He must have clicked right on a picture, and somehow managed to use the "Set as Wallpaper" button. given that it isn't the default action, he must have been waving the mouse pretty violently. This command doesn't require a confirmation, so he might not have noticed it. It's still a risk: things that don't have immediately visible results should confirm.
7TH USENIX SECURITY SYMPOSIUM 26-29 Jan 1998, San Antonio, Texas Marriott RiverCenter Hotel Program Chair: Avi Rubin, AT&T Research Labs Sponsored by USENIX, the Advanced Computing Systems Association In cooperation with the CERT Coordination Center Register now online: http://www.usenix.org/events/sec98/ Early registration discount deadline: January 5, 1998 Learn about the newest tools in tutorials, hear the latest solutions offered by researchers, and talk with some of the leading lights in the security community. Speakers include: Bill Cheswick, Carl Ellison, Dan Geer, Arjen Lenstra, Alfred Menezes, Clifford Neuman, JoAnn Perry, Marcus Ranum, Jon Rochlis, Avi Rubin, Shabbir Safdar, Bruce Schneier. Tutorial topics include: Java, NT, and Web Security; Cryptography; Certification; How to Handle Incidents; What Every Hacker Already Knows
Please report problems with the web pages to the maintainer