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…
News item from the Detroit Free Press, 8 March 1995. A Detroit area woman last week looked at her Caller ID box (manufactured by CIDCO, Morgan Hills, CA) and was puzzled to notice that it indicated 19 received calls that evening, even though only one person had called. Then she checked the names listed. John F. Kennedy. Thomas Paine. Harry S Truman. John Hancock. Ulysses S. Grant. Samuel Clemens. Ronald Reagan. And many others. Most of the phone numbers were non-working, but a few were. Ryan Biermann, an English student at the University of Wisconsin-Madison has been plagued with phone calls for Abraham Lincoln recently. No definitive explanation has been given. Ameritech (the Baby Bell for Detroit and Madison) believes the Caller ID box was probably a pre-programmed demonstration model. Dave Glowacz, a telecommunications consultant in Chicago, suspects the work of a phone hacker. Depending on the cause, lots of old Risks here (either a faulty demonstration circuit with non-fake data or an insecure data system), but perhaps with a new face to them. Addendum: accompanying the article is a photo of the Caller ID box listing Abraham Lincoln's name and phone number. I hope Mr. Biermann won't be getting too many more phone calls because of it ... Jim Huggins (huggins@umich.edu)
From misc.news.southasia Sun Mar 5 17:56:49 1995 From: abdutta@icaen.uiowa.edu (Abhijit Dutta) Date: Sun, 5 Mar 1995 00:34:16 GMT Newsgroups: misc.news.southasia Subject: Pakistan Forces Motorola To Halt Cellular Services In Karachi Voice of America, March 04, 1995 By Jennifer Griffin Islamabad: The Pakistan government has forced the US telecommunications giant, Motorola, to halt mobile telephone service to the country's strife-torn city, Karachi. Pakistani officials are demanding Motorola hand over sophisticated eavesdropping equipment that would allow intelligence agencies to tap into phone calls made on the company's cellular network. Analysts are saying the government's action is not encouraging to foreign investors. The Pakistan government claims it is trying to crack down on Karachi terrorists using mobile telephones to coordinate attacks and organize violence in the ravaged city. In a memo to James Beneda, the president of Mobilink — Motorola's Pakistani joint venture — the communications ministry demanded equipment needed to tap into all calls made by its subscribers be given to the government. Without these sophisticated scanners, intelligence agents would not be able to tap into the cellular network. It is the first time the government has admitted such tapping and eavesdropping is commonplace in Pakistan. Mobilink's service to Karachi was cut by the government January fourth. According to Mobilink's regional manager, Zahid Hussain, two other cellular phone companies presently operating in Karachi have not had their service interrupted because their calls are easily tapped. "The facility the other two cellular companies have, all you do is buy a 200-dollar scanner from Hong Kong or wherever, and you can walk the streets and just keep tuning into different frequencies and listening to people's conversations." Mr. Hussain says his company will comply with some of the government's demands and will deliver the mobile scanning equipment sometime this month. But, there remain other obstacles to resuming operations. The government has also demanded Mobilink not expand its number of subscribers from the present 3000 — a request mobilink officials say they cannot possibly honor. US state department officials and Secretary of Commerce Ron Brown are said to have brought the matter to the attention of Pakistan's Washington Ambassador, Maleeha Lodhi. The US-based company has invested more than 32-million dollars in establishing its Pakistani operation since last August, and intended to invest nearly 20-million dollars more this year. The scandal has caused many foreign businessmen to rethink their investment in Pakistan, where they say licensing agreements are easily rewritten and often disregarded. Mr. Hussain says the government's handling of the incident sends a negative signal to foreign investors, particularly on the eve of prime minister Benazir Bhutto's trip next month to the United States. Ben Burch Motorola Wireless Data Group Ben_Burch@wes.mot.com
>Barry Ward, ... `I've been in the computer business for 19 years and >have never come across this problem before. ... I find it difficult to imagine someone who's been in the computer business for two decades and has never heard of floating point round-off errors. This should be part of any computer science curriculum. Of course, part of the problem is that 20 years ago, virtually all business software was written in COBOL or PL/I, and that's probably Mr. Ward's background. These languages provide fixed-point decimal as a built-in data type, and require that decimal arithmetic be done accurately. There may still be round-off errors (e.g. dividing 100 by 3, or multiplying .01 by .01 and putting the result in a variable with two digits after the decimal point), but the programmer has direct control over the level of precision. These days, end users use spreadsheets to write "business software", and the spreadsheet designers seemed to have forgotten how business software has traditionally worked. The spreadsheet implementors are simply using the built-in mathematics that C provides, which is not appropriate for this problem domain. Floating point was designed for scientific computing -- it's often not much of a problem that errors are introduced, since there's an inherent imprecision in the input data (since it's translated from the analog real world to the digital cyber world). Barry Margolin, BBN Internet Services Corp. barmar@near.net
Re: the various appends about lights, etc., fooling remote controllers: I
used to have a Jerrold cable box that had a clock in it. When I used my
stereo receiver remote, it would sometimes cause the Jerrold clock to jump
an hour. What was interesting about this was that this was NOT a function
offered by the Jerrold remote! ...phsiii
[This is a clock that goes JERROLD McBoing-Boing when it triggers
the alarm? If it change the right <left?> digit, it would become a
YEAR-OLD clock. PGN]
> [The situation is even more complicated by the availability of > programs that mask encrypted messages as graphical image files > (.gif), so that irrespective of their REAL content, a message > appears to be an innocuous picture. PGN] What about going in the other direction? If you take an image file or some other data file (say a core dump file) that appears random, apply some simple operations (say XOR with various values) to it and run the output through a program that filters out everything except strings of alphanumerics (such as the Unix "strings" program), eventually you're bound to come up with with something that contains some obscene words, possibly "misspelled". A zealous prosecutor could use this to "prove" that the original was an encrypted form of obscene text.
[The situation is even more complicated by the availability of programs that mask encrypted messages as graphical image files (.gif), so that irrespective of their REAL content, a message appears to be an innocuous picture. PGN] Let's consider something even easier: Take a digital picture "A" of a politico presenting an award. Using a graphics editor, a miscreant removes certain items and adds a mustache (or something). The two digital files are then XORed so that only the changes remain in file "B". Again we have a two part solution but now the first part is mixed so that the second becomes a night sky or lost in the 24th bit of the first. Viewed as sent, it is an innocuous picture, but rearranged... Can you see the prosecutor trying to explain "yes but if you switch this and change that color and twitch you nose it becomes... Kinda like the person (not catching me with that one) complaining of the indecent behaviour next door: "Yes officer, it's horrible. Just climb out here on the roof of the garage, lean against that light pole and with these infrared binoculars you can see it just as plain..." "Life will find a way". Padgett
>If A and B exchange P in this way, then they can individually publish F1 and >F2, from which anyone can recover P, but both A and B can plausibly deny >having done anything but publishing a random bit stream. Unless they actually didn't know what the purpose of those random bit streams were, they would be perjuring themselves. They would have to convince a judge (and maybe jury) that they really thought they were just random bit streams, and they were passing them to each other for no reason. Were I on the jury, I would be skeptical. Barry Margolin, BBN Internet Services Corp. barmar@near.net
In RISKS-16.87, gat@aig.jpl.nasa.gov (Erann Gat) had some very clever comments about ways of exchanging bit streams that together make up a picture. I'd propose another scenario: if U1 embeds a pornographic image in the background of a picture, and sends U2 a binary image of the picture, U2 may well be unable to detect it. If U2 forwards the picture to U3, who (if anyone) has violated the proposed Exon law? As was shown in a paper published at the 1993 Computer Security Applications Conference, an amazing amount of data can be embedded in a digital picture without it being visible to a human looking at the picture on a screen or on paper. Truly amazing how little insight our legislators have into the technology they're trying to legislate.
> [encrypt image file F1 with one-time pad F2, email F1 to person A > and F2 to person B; A and B then exchange F1 and F2] > A and B each can now recover the original image. Has the law been > broken? Who broke it? All anyone did in the above scenario was to > send a random bit stream to someone else. At no time did anyone send > a bit stream with any identifiable semantic content. An undeveloped photo becomes evidence of crime when it's developed and is deemed porn. A special film requiring its own developing process doesn't change this. Whether a crime was committed wouldn't rest on mechanisms of imaging, therefore, but on the image transmitted. If it's deemed porn, chances are all three of you broke the law (plus conspiracy to commit same, given the way you went about it.) Lectures to judge or jury on the mathematical properties of the tools used will probably seem to them like lectures on thin film chemistry. > One might argue that I broke the law by sending out two files that I > knew could be combined to produce a pornographic image. That would be the prosecution's argument, yes. > So imagine now that A sends a random bit string F1 to B, who then uses > this as a one-time pad to encode P, which B then sends back to A. Has > the law been broken? Who broke it? A has conspired with B to effect the transmission of images deemed pornographic from B to A. I wouldn't bet the rent on any judge or jury concluding anything else. > B could never be convicted of violating the law, since he could always > claim that he had sent F2 before receiving F1, and that therefore A > had transferred P to him rather than vice versa. Even if the > government had timestamps to show that F2 was sent after F1, B could > claim that this was simply a retransmission. Oh? We couldn't recover P from A or B's storage? Or talk to someone who knew where P came from? If we do, we don't need to know anything about F1 or F2. We know where P came from and where it went to. Even without that, if timestamp records conflict with B's claims, we simply have to choose which one we believe. B's claims might be found credible, and might not. The judge or jury decide. On either grounds, B's toast under a variety of circumstances. > If A and B exchange P in this way, then they can individually publish > F1 and F2, from which anyone can recover P, but both A and B can > plausibly deny having done anything but publishing a random bit stream. The key word here is "plausibly"; plausible to whom? Judge or jury might find it less than plausible that A and B engaged in the generation and distribution of random bit streams, which later just happened to form images in combination. > The DA might try to prosecute both A and B on a conspiracy charge, > but it is not necessary for A and B to have conspired. The mere > knowledge that random bit streams can be used in this manner might > prompt some people to start sending random bit streams around. > Without reliable time stamps there is no way to trace the introduction > of semantic content. So as soon as anyone starts to transmit > one-time-pads, everyone can publish anything and no one can be > prosecuted for it. The above discussion should demonstrate why this is a rather naive view. However anyone who wants to give it a whirl is welcome to; it's your nickel. The danger lies instead in an equally naive view: > Any attempt to legislate the content of digital communications is > therefore doomed to fail And therefore we need do nothing. Wrong. The fact is that clever games such as these will not impress the judicial system nor derail the legislative process. If the law gets on the books it will work its damage. Such schemes as suggested above will be looked on as what they are, attempts to evade it or confuse its enforcement; little will be gained; it might even be counterproductive. No, if we want to stop Senator Exon's nonsense, we have to do it the old fashioned way: organizing, lobbying, informing, and persuading. Jon Krueger jpk@pet.com (510) 523-2514
Erann Gat's article on semantics (RISKS-16.87) provides a nice example of the difficulties of identifying any bit stream with certainty. Unfortunately it also provides an example of an all too common Risk: Engineers confusing scientific "proof" with that of a legal nature. Censorship is already enforced on the internet. In particular, allowing transfer of encryption technology out of the U.S. is illegal. This leads to awkward situations for companies who's products include security, but by Gat's arguments they can get around the problem by simply encoding the software and sending it as two "random" bit streams. Anyone who decides to try this, please be sure to let us all know... Sarcasm aside, I don't think anyone believes that Department of Commerce (or Defense, or whoever enforces that restriction) would even slow down on their way to the courthouse because the information was encrypted. Intent is far more important than encoding, and I don't believe they'd have any trouble with a conviction. But back to the basic Risk: Engineers forgetting the end users and getting wrapped up in notions of mathematical certainty and "solid" proof. Remember: your firewall _supports_ an overall security policy. Your automated flight system _supports_ a pilot. Your software filters _support_ the legal system. In all these cases the software is not the end all be all, but an aid to accomplishing some other task. At some point we may feel comfortable replacing humans with software completely for these uses, but RISKS forum itself is a testimony to how far off that actually is. -Tim Kolar
>Now suppose that I email F1 to person A and F2 to person B. Then A and B >exchange F1 and F2. A and B each can now recover the original image. Has >the law been broken? Who broke it? All anyone did in the above scenario >was to send a random bit stream to someone else. At no time did anyone send >a bit stream with any identifiable semantic content. Unfortunately, our legal system is not advanced enough to recognize the subtle differences described above. The authorities will wait until the two parts are combined. They will then seize every piece of hardware which appears to be associated with the image. Anyone who happens to be in the mail header will be arrested. During the trial, the reconstructed image is all the jury will see, understand or remember. They will fall asleep during the expert witness testimony regarding public key cryptography. This is the RISK of living in a society which is heavily dependent on technology, but whose users are not very well educated. David Harpe david_harpe@mm.cobb.ziff.com
>Actually, this is a feature. I'm sorry, but throwing a user into an unknown state and requiring them to know they have to type "go" and calling it a feature simply because the operating system can't handle losing power without risk of losing the file system is wrong. It's a kludge covering a bug. It never ceases to amaze me the ends to which people will put up with this from vendors. They won't fix the original bug, but they will add on all sorts of backdoor patches and think they've solved the problem. It would be like taking your car in for service for a rattle, and and the garage giving you ear plugs so you can't hear it anymore. To steal a line from the same Risks issue, the ultimate solution to these recurring file system problems is for consumers to demand working file systems from software manufacturers. /ahw
I would like to take issue with Tarl Neustaedter for saying, in effect,
that Sun's decision to have its SPARC computers go into the ROM Monitor
when you unplug the keyboard is a FEATURE and not a BUG.
Mr. Neustaedter eloquently says, basically, the following:
1. Sometimes you need to be able to interrupt the computer.
2. User software can completely remap the keyboard.
3. Therefore, we need some signal that can't be remapped to get the
user into the ROM Monitor.
4. The only thing left is unplugging the keyboard and plugging it
back in.
Here are some things to consider:
1. First at fault is the ROM monitor itself, which has one of the
most un-user-friendly prompts I have ever seen. The menus are difficult to
read; the commands are not neatly formatted; it's just not clear for
non-technical people what to do.
2. I am sure that more files have been left by some poor secretary
or other non-technical person accidentally unplugging the keyboard and then
plugging it back in (and consequently getting trapped at the ROM prompt),
then have been saved by UNIX weenies who have known that they could trap
into the ROM monitor by playing this game with the keyboard plug.
3. Mr. Neustaedter's note that this functionality can be disabled
by hand-editing the function call to abort_sequence_error() in the function
zsa_xsint() in the file zs_async.c is the typical UNIX weenie response: if
you don't like it, then search through the source-code (or object code) and
fix it yourself.
Yes, it is wonderful that UNIX gives its users such flexibility.
But it's also clear that UNIX was designed for small research labs where
the users want this sort of flexibility, and not for general use. Putting
UNIX into general distribution is dangerous: it's dangerous for the users,
and dangerous for those who have to give support to the users.
"It helps to be handy with kadb."
Indeed.
Simson L. Garfinkel
Co-Editor, "The UNIX-HATERS Handbook", IDG Programmer's Press, 1994.
This has been a feature of Sun Workstations at least since the Sun-2s. I worked on a project in 1985 with six rack mounted Suns each supporting 6 diskless Suns. There was a table beside each rack and on the table was a keyboard. No CRTs of any kind to be seen. I don't know why, but periodically someone would decide that they needed one of these keyboards. With the result that at least six Suns (generally more as NFS mounts to the now hung server would fail) would freeze up until we could get the keyboard back and reboot the server. Just last year I was stung by this feature. I was to give a demo on a Sparc 10. Some one had connected the mouse off the left side of the keyboard and I decided I needed it on the right. So I immediately unplugged the mouse then proceeded to disconnect the cable on the right side, and the Sparc 10 proceed to crash. After reconnecting the cables I attempted to reboot. Well it failed to reboot and later it was discovered that one key file had been corrupted (I forget which one).
This is a good topic for a trivia question in the Computer Bowl. I bet SMI borrowed the break behavior from PDP-11s. I'm not sure when it was introduced into the PDP-11 family (certainly by the mid 70's), but holding the break key for a bit on the console caused a "framing error halt". On a PDP-11/03, this dropped you into the microcode monitor. On machines without a monitor, you had to restart it from the front panel with all the funky lights. Anyways, it served a useful purpose. On the RSX-11 operating system, you could schedule a job with a priority higher than the command line interpreter. If this job went into an infinite loop, it could not be terminated. The solution was to stop the machine with the break key, and poke around in kernel memory to remove the job (there were various ways to do this.) Hopefully, when the machine was restarted, it would be back to normal. — Mark Stalzer (mas@acm.org)
Disconnecting the keyboard is the same as the L1-A interrupt which throws Suns (since Model 3s) into their monitor program. Typing "c" for continue will let the cpu resume unixing. This is indeed obscure behavior if you don't know about it :-0 Most computers have arcane stuff like this mentioned (once) in their voluminous manuals. Computers aren't the only such systems: there are cars you can shut down by kicking in the right place, where you activate a sensor that shuts off the fuel pump, for instance. The problem with big systems is no one reads (or understands) whatever descriptions of it there might be.
Please report problems with the web pages to the maintainer