The FBI is working on software that could insert a computer virus into a suspect's computer capable of reading encrypted data. The software, known as "Magic Lantern," installs "keylogging" software that can capture keystrokes typed on a computer. The virus can be sent via e-mail. Once on the targeted PC, it waits for a suspect to launch the Pretty Good Privacy encryption program and then logs the passphrase used to start the program, essentially giving agents access to the keys needed to decrypt files. The Magic Lantern software is part of the FBI's "Enhanced Carnivore Project Plan," which operates under the umbrella project name of Cyber Knight. Electronic Privacy Information Center attorney David Sobel says privacy issues arise when keylogging results in "overly broad" searches, since it would be possible to observe every keystroke typed by the suspect, even if a court order specified only encryption keys. The FBI has already used a less-sophisticated version of the software to build the high-profile racketeering case against Nicodemo Scarfo, but had to manually turn the system on and off in order to comply with the court order. [MSNBC/Wall Street Journal 21 Nov 2001; NewsScan Daily, 21 November 2001] http://interactive.wsj.com/articles/SB10062942834030720.htm (sub req'd) [Insertion by e-mail probably works well for Microsoft software, which is prone to that kind of attack. Various reports suggest that Magic Lantern can also plant itself by penetrating systems. Penetrability of supposedly secure systems has long been noted here, with further risks resulting from a weak system that is directly networked to supposedly more secure systems (especially if done with single-sign-on authentication). This may not be a case where one good (LAN-)turn deserves another. PGN]
Declan McCullagh, Wired News, 20 Nov 2001 If you subscribe to any of Ziff-Davis' computer magazines, you may want to double-check your credit-card bill next month. Ziff-Davis Media, which publishes such popular tech titles such as Yahoo Internet Life and PC Magazine, accidentally posted the personal information of about 12,500 magazine subscribers on its website. On 19 Nov 2001, ZD removed the data, which included hundreds of credit-card numbers, and said its engineers had taken steps to prevent additional security leaks. http://www.wired.com/news/ebiz/0,1272,48525,00.html
As RISKS readers may be aware there was a national election in Australia on 10 Nov 2001. Australian electoral procedures have many features which US readers in particular would find unusual, but perhaps the most surprising of all is the method used to elect Senators for each of the states. A preferential voting system is used (a complete order of preference must be shown) and those candidates who receive a quota (a proportion based on the number of positions to be filled) are elected. Any votes surplus to quotas are redistributed at reduced value, and least preferred candidates are excluded until all positions are filled. The interested can refer to http://www.aec.gov.au/pubs/factfiles/factsheet7.htm or the truly masochistic to the legislation which specifies the counting method. http://scaleplus.law.gov.au/html/pasteact/0/57/0/PA003450.htm In a normal half-senate election, 6 senators are elected, meaning that a the quota value is about 14.3% -- within the bounds of possibility for smaller parties. With a trend toward an increased number of candidates, a simplification was introduced in the late 1980s whereby political parties could nominate a preference "ticket" and the voter can choose the party ticket by voting in boxes above a thick line which divides the ballot paper. Alternatively the voter can number all the squares below the line (65 in all in the recent election in New South Wales). Since its introduction, the number of voters using the above the line method has grown at each election and was above 95% in 2001. The increase in ticket voting has made feasible the automated "scrutiny" or determination of the result, and the Electoral Act was amended before the 1998 election to permit this. All that is needed is for the 3-5% of below the line papers to have their order of preference captured, the total number of voters who selected each of the tickets and then the legislated method can be applied and the result determined "instantly" instead of taking several weeks by the manual method. The taxpayer wins if the time taken to input the ballots is shorter than the time taken by the manual procedure... But the risk is in the accountability. In a manual election, each of the candidates is entitled to appoint an observer (scrutineer) who may check for irregularities in the process. It may be mind numbingly boring, but it is feasible. The automatic system is much more difficult. The legislation permits the scrutineer access only to a record of: * the preferences on the ballot-papers ... stored in the computer; and * the ballot-papers that ... are transferred at each count; and * the progress of the count of the votes, at each count. Note that the source code of the software which determines the result nor its operating environment are explicitly not available for scrutiny, meaning that each scrutineer must be able to reproduce the process independently to sufficient accuracy to detect errors or fraud (refer to the legislation link above). Also the scrutineer(s) must attempt to observe the accuracy of hundreds of data entry staff as they enter the ballots at full speed. As the result can be affected by cascading differences triggered by tiny numbers of votes changing the order of exclusions, it's probably only a matter of time before there is a very interesting case in the Court of Disputed Returns.
(Re: Programming error scrambles election results (RISKS-21.74) There is an interesting paper I recently read. It shows that biological evolution is just like debugging. Selective pressure, such as poison (debugging), on a biological system will kill as few members as possible to keep the system stable. Software bugs are the same way. Debugging is a selective pressure (selected by the debugger to meet their expectations) and will remove as few software bugs as possible. See "Murphy's law, the fitness of evolving species, and the limits of software reliabilty", at: http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/babtr.pdf The authors webpage is at: http://www.cl.cam.ac.uk/~rja14/
Both Mr. Marson and Mr. Kos, in their comments about the San Bernardino election problem, make a common mistake. There is programming, and there is programming. "Programming" an election is not writing software. It is akin to programming a VCR. In other words, entering data to describe the layout of the ballot. Sometimes vendors do this, sometimes county employees do. (Even though I do not know which particular vendor's equipment was used, all are alike in this regard.) Does this make testing unnecessary? Of course not. But let's make sure we understand where the failure was. Paul Terwilliger, Sequoia Voting Systems, Inc.
I believe that in order to truly test a piece of software, at least two testers are needed. The first would be somebody with a complete enough understanding of the problem that he/she could have coded the program themselves. This person would review the code for logical errors, robustness of algorithms, etc... The second tester would be a person with minimal knowledge of the system (representative of the least trained person ever likely to operate the system). This person will unwittingly test all the user interface and data checking assumptions made by the original programmer.
If you want to know the cost of quality, prepare to purchase it! A 'real' software test engineer, one who is exceptionally knowledgeable of the fundamental technology mechanisms residing at the core of modern products (like threads, synchronization, scheduling, signals, process tracing, message passing, VM, etc.) is mighty, mighty rare and plenty expensive. Certain cultural and educational barriers forestall the creation of many. Peer ostracism, managerial indifference, and professional lassitude often conspire against this career choice. The best folks prefer product engineering (aka 'development'). Hell, a good test engineer must continuously author and develop test assets well ahead of any product engineering activity. In the past 7 years, I have authored in excess of 400Kstatements of PERL/C/C++ comprising thousands of individual functional test assets and dozens of reliability evaluations. I know kernel hacks who have struggled for months to find a 1 line race condition fix arising from a wimpy program. Creating non-deterministic product evaluations that compel races, corrupt data, generate deadlock, cause resource leakage, panic, coredump, or other fatal conditions is more of an art than a method. No matter how stupid or non-sensical an input, a product must remain deterministic and self-consistent (this is the famous user-is-an-idiot postulate). Deterministic evaluations consume substantial test engineering cycles: all those inputs, a little product logic, and assertions of output takes many keystrokes. Such exhaustive measurement is often the only means to show program feature and function correctness. What I'd give to out-think Alan Turing on this issue! Many for-profit organizations do not really understand that test engineers author intellectual property too: IP the customer does not purchase, but what they experience as a consequence of test asset quality ; If the test assets stink, the product stinks. That's what test engineers do -- function as editors (as in newspaper publications) to raise product IP quality. To be successful, test engineers must embody the worst customers in the world, and the best friend a product can have. The only acceptable customer feedback is a purchase, not a complaint. How does proactive test engineering compare to a 'nuclear' customer support hotline post-release? Its hard to query corpses -- especially dot-bombs. If management believes any warm body will suffice to successfully and thoroughly evaluate 1Mline+ C++ software toxic wastedumps, dig up a corpse from a cemetery and apply a space-heater, but don't hire a button pusher. We all know its far cheaper to fix bugs in the system before release, and even easier/cheaper when in the earliest SDLC phases. But testing and other means to ensure quality are often short-changed because of disciplinary failure and organizational, ethical lapses -- covert institutionalized violence. Richard M. Stein, StudioCentral Test Engineering Contractor 650-933-7391
Takes a lot more than understanding the problem, etc.. The person who really understands the problem is generally only going to enter expected, correct data for the problem domain. The programmer tends to be limited by the expectations of the program, the skilled user by the expectations of the problem domain. Good testing is a different skill. If you want a program to be ready for prime time, get it tested by someone skilled in testing. Of course the tester must know something about the problem domain, and testing by both the programmer and the skilled user are valuable too. But testing is a skill in itself.
> nobody (not even I! ;) can be relied on to find their own bugs. And also there is less chance of them LEARNING from their bugs - so the "method" behind the bug tends to propagate. I had been arguing about the existence of a bug with two programmers from another dept in the IT organisation that I work for. Eventually I got to take a peek at the code in which - according to me - the bug had to exist. I found it in minutes. The programmer concerned had written code that ignored a lock in the database with the result that updates were sometimes "lost" if two instances of the code were running simultaneously. When I showed the programmer (a junior person) who wrote the code the bug and explained it she quickly grasped the flaw in her logic and went off to check several other bits of work she'd done to see if she had reproduced the bug. She now also understands a particular aspect of her job and the language she works with better than she used to. A test in a multi-user scenario and/or a code review would have quickly uncovered a bug that caused some acrimony and a loss of money - and would have resulted in a programmer who had had improved their craft. One of the RISKs of not having code reviews and good test procedures in place is that inexperienced junior programmers will become poorly experienced senior programmers and the bugs will propagate.
I'd suggest that a large part of this is due to explicit blocking of IP ranges by system administrators. This could either be local blocks or published lists like MAPS or SPEWS. Getting on SPEWS, for example will make about 30% of the Internet unreachable if you get listed. Also, for cable modems, I'd think a large part of this is the arrogance, unresponsiveness and incompetence of the administrators of the cable networks, especially @home. They've gotten into lots of local block lists because they won't shut off abusers or even respond to complaints.
My wife and I had an unexpected adventure when we went to get our car washed at a gas station the other day. (I am withholding the name of the chain to protect the not-so-innocent, and because it is probably not the only culprit anyway.) First, some background: the system is fully automated, and offers three levels of operation. (The cheapest doesn't even dry the car, and the most expensive includes tire scrubbing and other frills.) Because we had recently gotten the car used, we decided to go for "The Works." Also, the station offers a discount with the purchase of 8 gallons or more of gas; in order to get this discount, you need to buy a code for the machine with your gas. Anyway, the first problem we encountered came about when ordering: the display at the pump told us to press 1, 2, or 3 to select a cycle, but did not specify which was which. Assuming that it went from cheapest to most expensive, we pressed 3, only to be told that we had selected the basic cycle. Fortunately, it asked for confirmation, so we went back and selected 1 instead. Next, we drove up to the car wash (which involved waiting in line for a little while, waited for the previous driver to finish, punched in our code (for "The Works"), and drove into the machine. It started to wash our car, but then stopped in the middle of the cycle -- with a little barrier effectively preventing us from driving out the other side. (We could probably have driven over it if we had pressed hard enough on the gas, but it didn't seem like a great idea.) The machine appeared to be completely dead; the screen which normally displays something like "enter," "exit," or "washing" was blank. Experimentally, we backed up slightly, at which point the machine told us to drive forward again; when we were back in the target position, it started all over -- with a basic cycle, which it at least finished properly. At that point, we drove out unhindered and went to complain to the management. We convinced them to give us a new code for "The Works", and returned to the back of the car-wash line. When we got back inside the machine, it stopped at the same point as before. This time, we just gave up and waited for something to happen; after a few minutes, the attendant came out (at the behest of the driver behind us), and motioned that we should again drive backwards for a moment and then back forwards to the target position. This maneuver again caused the machine to restart -- this time with what appeared to be a "deluxe" cycle. Since that cycle included the remainder of the things we wanted, we decided that it was good enough and that we had wasted enough time there, and so simply drove off. Our hypothesis is that both times, the drivers behind us had confused the machine by entering their codes before we were done -- an action which the interface allows, and even appears to encourage -- and that each time we backed up, it restarted with the cycle the next driver had ordered. The risks? * Poorly presented menus can lead to undesired selections. * Badly designed machines can trap their users. (Note that in this case, a Big Red Button would not have sufficed, since it was not entirely clear that the machine might not suddenly restart and injure whoever got out of the car to push it.) * Systems that prompt for input before they are ready for it can fail unpleasantly.  After telling one driver to enter, it immediately prompts for another code. Aaron M. Ucko, KB1CJC <firstname.lastname@example.org> (finger email@example.com) [Nonatomic transactions can be quite explosive. PGN]
Um, perhaps I'm being naive, but it's not clear to me what the "risks to the public in computers and related systems" is in this case. Sure, there's a risk that consumers may be buying software that's not legit, but is there an allegation that the software is flawed in some way? Isn't this sort of like buying a Rolex on a NY street corner?
NO! The problem was _NOT_ that some "bleary-eyed coder" missed a couple of quotes. The problem was that Apple's process for reviewing software prior to shipping to catch the _inevitable_ syntactically correct but semantically flawed code was broken. And broken badly if such a obvious error could slide through undetected. paulward (DrGS)
Before the Mac haters out there take any glee from this incident, a clarification is important. What was left out was the reason why the quotes are important-- On the Mac, file and directory and disk names can and do contain spaces. With the new Unix-based OSX, long-time mac users are discovering the hard way that spaces are used as delimiters in scripts and in parsing, so filenames containing spaces can have unintended results. Most Unix code samples and docs assume that no one ever puts spaces in their file names, so the samples never show quotes being used, and some docs don't mention this need either. Just about every programmer making the Mac switch from OS 9 to 10 finds this out the hard way, just not as publicly and catastrophically. The risk-- changing the underlying behavior of familiar software, and not being aware of all the assumptions behind that underlying behavior.
I agree that it's unlikely that the US military needs extra Swedish PC computing power to plot missile trajectories, but the Swedes have been here before. In the mid-90s the Swedish parliament and other government offices acquired Lotus Notes, and one factor in their choice was the "secure" encryption it provided. Until they found out that the CIA had a master key. So the line between "conspiracy theory" and "justifiable paranoia" is perhaps blurred in this case. There is also the RISK that in running any code from SETI@home, you are trusting SETI's site not to be hackable by someone who might want to run some other code on your computer. If someone put a replacement client in there which trashed your hard disk at a given date/time, I suspect the worldwide damage would put the "ILoveYou" worm to shame.
> I can't find a way, in the *import* function, to define these numbers as > "text" so that Excel will leave them alone upon import. Sigh. Text Import Wizard step 1 - choose fixed/delimited Step 2 - column breaks Step 3 is where you set the column format - choose Text for IP addresses http://www.sysmod.com/spreads.htm Patrick O'Beirne B.Sc. M.A. FICS
Listings can (at least now) be removed using a form found at http://www.google.com/help/pbremoval.html, which was linked to from the "More phonebook listings" on my Google telephone listing. This form itself is not without risks. First, they require (off-line) authentication only for removal of business sites, so individuals can have their listings removed by others even if they would prefer to have their listings remain. Second, your communication with Google about your phone listing can actually help them establish its correctness (and they ask for your e-mail address too), so depending on your trust level in Google to handle your personal information, you might consider it better to remain silent than to voluntarily give them verified information about yourself. [RISKS received a Google-plex of e-mail on this subject. This information is widely available on the Internet, on CD-ROM, etc. Thanks to all who responded. PGN]
>Sure, you can change passwords if you have physical access to the machine. >You can also boot any Mac with a MacOS 9 CD and completely circumvent all >protection. Firmware security can make it much more difficult to boot from a MacOS 9 CD (or any other bootable CD), and avoids some similar simple methods of circumventing password authentication (booting in single user mode). Firmware security is a recent, and poorly documented, addition to the Macintosh that is not present on all models, and on many machines will require a firmware update. It is a significant protection against the casual, Macintosh capable but not truly expert, attacker, and is thus probably a good idea for situations such as unattended kiosks or laboratory machines. It cannot, however, be completely relied on. There are two methods to bypass firmware security. One is a reasonable and prudent method - if you change the RAM in the machine, it also resets the firmware security. Perhaps there will be unintended consequences from those are unaware of this poorly documented side effect, but it is necessary that there be some means of disabling the feature to prevent machines being rendered unbootable, and it is appropriate that it be some feature that requires access to the internals of the machine for a reasonable amount of time. If you are in a situation where firmware security is an issue, you should also be implementing physical security (Apple generally makes it easy to secure access to the case with a padlock or similar on most models). Unfortunately, there exists a weakness in the implementation of the firmware security that enables the dedicated attacker to discover the Open Firmware password and thus bypass this protection, and a program to exploit this vulnerability is available. http://www.securemac.com/openfirmwarepasswordprotection.php Luckily, it runs only under Mac OS 9, so Mac OS X machines are relatively safe (it does not run under Classic), but this cannot be relied upon, as the same underlying vulnerability exists and it is simply a matter of someone writing code to exploit it. Apple does appear to be gradually increasing the amount of security, and definitely appear to be treating security on Mac OS X as a serious issue. Unfortunately, there are still some weaknesses that have been discovered. David Cake (Macintosh and Unix consultant), Difference Engineering
Please report problems with the web pages to the maintainer