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…
The *New York Post* reports on Sunday, April 6, that $20 million has been spent by New York City on an effort to convert to electronic voting machines, but the city has received only one prototype voting machine. Notably missing is the software system (expected to cost another $1 million) to process the election returns. The project is now mired in lawsuits between the city, the primary contractor (Sequoia Pacific Systems), and a subcontractor (Deloitte & Touche). The article, by William Sherman, covers quite a bit of ground, including the history of the voting machine contract and the various milestones of progress (or, more often, no progress) along the way. Some of the salient points are: * Much of the technology is now outdated, because the project was started back in 1984, with the specifications developed in 1987. * The new system will be vulnerable to vote tampering by "computer hackers". [RISKS readers familiar with this issue of course know that the real source of vote tampering is not "hackers" but the politicians, poll workers, and other parties who have access to the voting machines.] * The hardware (i.e., the voting machine) met only 63 percent of the "technological and security criteria" set by SRI, the city's consultant for the specifications of the voting machine and for evaluating the bidders. * The city rejected Deloitte & Touche's proposal for the voting system software "citing Deloitte's inability to explain how it works". * According to the article, each voting machine would use a "digital vote recorder" and removable cartridges. The cartridges would be removed from the voting machines, brought to a district center for uploading (via fiber-optic lines) to a central computer, then returned to the voting machines for more voting. This process would be repeated throughout the day. * Although the vendor says that they have 10,000 machines of this type deployed around the nation, a city official says those systems do not work when there are more than 1500 voting machines on the same network (as there would have to be in NY City, with 1250 polling sites and multiple machines at each site). My take on the subject is that it is nice to see that there's an evaluation process going on regarding the software system that all democracy in NY City may one day depend on. I prefer my tax money going to waste rather than buying an unsecure electronic voting system. This isn't the first time I've heard of this project: I've read complaints from "good government" groups that the city's planned system did not have any way to confirm "the computer's" vote totals. Their concern was that any well-placed technically-aware politician, Board of Elections employee, or other rascal could steal the vote, and no one would be the wiser. It appears that their concerns have not yet been addressed. If the new voting machines really need to have their "cartridges" ferried to and from the polling site while voting is in progress, that alone raises all sorts of questions in my mind as to how they can be kept secure. Ed Ravin eravin@panix.com
Microsoft's ActiveX has security flaw, Sun says Reuters Financial Report 3 Apr 1997 Courtesy of Reuters News via CompuServe's Executive News Service > SAN FRANCISCO, Calif., April 3 (Reuter) - Sun Microsystems Inc on Thursday > demonstrated what it said was a security loophole in Microsoft Corp's > ActiveX technology, which it said could enable a malicious hacker to break > into a computer user's private financial files. Sun showed how when a > specially written program containing ActiveX was downloaded by a remote > user, the program then took over the user's computer and rifled its files > for personal financial information. [...] > The demonstration was made during a keynote speech by Sun CEO Scott > McNealy at the company's JavaOne conference. [...] Sun executives said > they see security as a major issue differentiating Java, which has been > designed to enable programs to run in a protective "sandbox," and ActiveX, > for which security has recently become a looming issue. The demonstration ActiveX control *had* been signed. Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.
The _Globe and Mail_ for 8 Apr 1997 (p. A21) has an article by Robert
Sheppard ("Talk around the clock") that brings out an unexpected consequence
of the availability of mail-merge programs for the legislative process.
Background: the Conservative government of Ontario has been using its strong
majority to pass laws in spite of public opposition to specific bills. The
latest example is the amalgamation of several established cities in the
metropolitan Toronto area into one giant "megacity" (trivial by US and world
standards but big by Canadian standards). In the process, about a half
dozen municipal governments are to be abolished. In a region-wide
referendum on the question of amalgamation, 75% of the voters opposed the
plan. The Tories flatly stated that they would pass the law anyway.
The opposition parties have hit upon a novel form of filibuster: they are
proposing about 12,000 amendments — one for every single named street in
metro Toronto — demanding that any law affecting the residents of that
particular street be subject to local review by those citizens.
The Ontario legislature is procedurally obliged to vote on every single
amendment. Since it take at least a few minutes to read the amendment, vote
on it, and read the results, the chambre is managing to work through about 4
amendments an hour in 24-hour sittings. It is estimated that it will take
several weeks to clear the amendments.
So where are the computers in all this?
They are churning out the amendments! The combination of mail-merge
programs, word-processing packages, and an electronic list of all the
streets in the area has made is physically possible to produce this tidal
wave of amendments. Were the older methods to have been in use, it would
have been impossible to generate the sheer volume of writ in time to clog
the system.
It's a curious way to run a province.
M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA) http://www.ncsa.com
[It's like a Perl script to annoyster. PGN]
We've been printing some labels for CD cases where the label has to fold on the inside of the case outside of the carrier. We had observed that the label always seemed a fraction too small even though we were sure we'd measured an original correctly. I've just tracked this down to a bug in the PostScript back end of Tgif (Version 3.0 (patchlevel 12)) where it converts from internal units (5 per mm) to postscript points (72 per inch). The code went: 72 128 div 100.000 mul 100 div dup neg scale making 25.6 mm per inch! Sure enough changing the output to 72 127 div 100.000 mul 100 div dup neg scale makes things appear the correct size. I guess the RISK is having programmers who are too used to typing powers of two. Richard
My dad's new Beamer [1996 540i], ya' know, the ultimate driving machine, turned itself in to the ultimate PITA [pain...], as relayed by my dad: The automatic tranny locked up in OD after he nailed it, doing the ol' power downshift that automatics can do. This left him quite overgeared and useless from a full stop. The instrument panel read 'program missing ' or some such fibbishness. Back at Beamer local, the center-of-gravity guys found that he had a corrupted or missing tranny 'program'. The Beamer system is designed to sense driving habits and adjust shifting patterns accordingly, storing the 'changes' in firmware. Apparently, the nailing was outside dad's established params so the 'program' balked. They had to connect the car to Beamer central in Munchen via dialup to download a fresh program. NickZ [Evidently the extreme parameters resulted in either a Variant Beamer or a Bavariant Creamer. PGN]
> Suppose I have a PRNG seeded with a nice and dandy (VERY random) 128 > bit seed. [...] > Information theory states that if I know any 128 bits of this stream, I > theoretically know the whole stream. In practise you need a few more bits > to be sure. In practise you can only recover the whole stream if the > entropy in the original is small enough. You're right that the amount of real entropy is less than the message size. In practice this doesn't matter, since strong crypto functions are available. The information theoretic argument is more interesting and isn't as cut-and-dry as they might seem. I made the (admittedly broad) assumption that the crypto is strong, leaving brute force as the only way to find the inital state. Although some information theory purists might claim that the existence of a brute force attack makes inversion possible, I don't necessarily agree. For example, if the initial state is 1024 bits, the amount of energy required to perform 2^1024/2 state transitions should exceed the amount available in the known universe. Thus, although the attacker may know that the solution is out there, it's stuck in a cryptographic black hole. -- Paul P.S. Please note that I'm slightly playing devil's advocate with the claim that sufficiently hard problems are impossible :-). One particularly interesting challenge to this assertion comes from quantum computing, since a quantum device might not require a separate state transition for each key tested. Anyone care to comment? Paul Kocher (pck@netcom.com) Crypto consultant http://www.cryptography.com Voicemail: +1-(415)-354-8004 FAX: +1-(415)-321-1483
I work in an MIS department. Yesterday morning, there was a call from a user about a program not working that she had used on Friday with no problem. I ran the program and it told me there was a corrupt file and that I should make a copy of the original file from the last disk of the distribution set. Before doing this, I compared the two files to try to figure out what might have happened so I could check for any other problems in other files. The files were identical. I then looked at the size and time stamp of the files. The only observable difference was that the time stamp on the file on the hard disk was exactly one hour later than the time stamp on the file on the diskette. Being a long-time reader of RISKS, my suspicions were immediately raised since it was the day after the switch to daylight savings time. I ran the two other programs we purchased from the same software company. One reported the same type of "corrupt file" error message with a different file and the the other claimed we were no longer licensed to run the program from a network server. I examined the files and found the same time stamp differences. I copied the first file off the diskette as directed and the program again worked. I then merely changed the time stamp on the other two affected files and the respective programs also began working. The affected files were all on the diskettes which are different depending on what type of license for the software you have - an unlimited, network license in our case. It was obvious to me that their licensing checks are somehow related to the time stamp on the file. I called the company to report my findings. The person I talked to claimed that the real problem was that my workstation had a different time from the server. I checked and this was not the case as far as I could tell. I reported this and the person appeared to be quite miffed that I was questioning his word. Since it didn't really matter to me if he didn't want to know the solution to what was going to be a busy day on the phone for him, I did not pursue this further with him. However, I am wondering what will happen in the fall when we change our clocks again ...
The problem Ian Brogden described was so widely known that some freeware distributed by Jamie Hanrahan through DECUS (user group) channels was used at many sites throughout the world (by altering clock frequency rather than changing the clock all at once). There is a RISK that such helpful add-on software relieves the pressure on the original software vendor so as to delay inclusion of a general fix in the product. That leaves those who don't hear about the unofficial workaround out in the cold. The upside is that the design of the workaround was so widely discussed that many people outside the original software vendor learned the details of the problem and how to ensure that their own software would not make the same mistake which had been in the affected version of DECnet. (Essentially there are two ways call for time delays in VMS, one of which would be affected by a time change.) The VMS world is currently going through a similar learning experience regarding those who have imported software from Unix and used certain VMS date routines without reading their specification. There will never again after this year be an opportunity to reach day 10000 after the base-date of Unix, but there will be many future opportunities to read routine specifications before using them. Larry Kilgallen
Ian Brogden reports on a problem which causes DECnet to stall for an hour when the time back (so this is really a Fall RISK, not a Spring RISK). This is an old (at least 5-6 years?), known bug, long ago fixed. To help make sense of some of what Mr. Brogden says, a bit more explanation of how VMS deals with times may be worthwhile. The VMS standard time format is a 64-bit signed integer representing 100 nanosecond "ticks". A non-negative value represents an absolute time (since a base date in 1858). A negative value represents a "delta" time. The VMS calls that do things like request a signal when a particular time arrives take a standard time as an argument. On the surface, there is no difference between specifying the absolute time for an hour from now, or specifying a delta time of one hour; the timer queue stores only absolute times. However, the kind of time used in the request is recorded in the timer queue elements. When the clock time is reset, the timer queue is traversed. All queue elements that specified absolute times are ignored; but all queue elements that specified delta times are adjusted by the same amount as the system clock is being adjusted. Hence, the request that specified an alarm an hour from now (at, say, 3:00PM on a given date) will arrive when the system time is 3:00PM on that date. On the other hand, the timer request that specified an alarm an hour from now will arrive when an hour of time has elapsed, whatever the clock then says. Finally, VMS records the *local* time of day, daylight or standard; so it has to be adjusted (these days, automatically and gradually) twice a year. The bug was the result of mistakenly using an absolute time in a DECnet timer routine, rather than a delta time. The fix was, needless to say, straightforward. I'm not sure what the RISK really is here, beyond the observation that we've all made that bugs *will* emerge, even in heavily used and apparently very reliable code. (The code, and bug, had been around for years, but was never noticed - if no one is logged in when the time change occurs, it's unlikely that there will be any easily identifiable effects to notice the next morning - well, the next *Monday* morning. Network protocols, after all, are designed to be resilient, and to expect errors to occur here and there. By the way, there was, of course, an corresponding bug that showed up with the clocks were set forward. In that case, timers would expire early. In practice, this is even *less* noticeable; all you get is an apparent burst of lost packets, which is no big deal to network software.) Jerry
[... Identical situation on my home PC.] And, true to form, this last weekend (the DST change-over weekend in those parts of the US that honor it) my dual-boot Linux/Win95 system, running with the hardware clock set to UT, decided, when I booted Win95 (also configured to use GMT), that the clock should be bumped up an hour. I too had left the "Adjust for DST" box checked thinking "well, GMT doesn't adjust, so it doesn't matter." How long have computers been dealing with time zones? And Microsoft still hasn't figured out exactly what GMT--the easiest of the lot to deal with--is? Jeff Uphoff - Scientific Programming Analyst, National Radio Astronomy Observatory, Charlottesville, VA, USA juphoff@nrao.edu juphoff@bofh.org.uk
Marvelous, simply marvelous. Reminds me of the student who, many years ago in response to a complaint by me about not using meaningful variable names came up with A000001 A0000O3 A000002 A000O03 A000003 intermixed with A000OO3 A000004 A00O003 A000005 A00O0O3 and this was in the days of IBM 1401 chain printers when it was harder to differentiate between the letter and digit. charlie shub University of Colorado at Colorado Springs cdash@cs.uccs.edu cdash@cs.colorado.edu (719) 262-3492 http://www.cs.uccs.edu/~cdash
Blue Cross has set up an automated system to have subscribers update the Social Security Numbers (SSNs) of all dependents. They say this is to meet the Medicare requirements. To use the system, the subscriber enters his/her SSN on a touch-tone phone, followed by the last two digits of the birth year as a "password". It then steps through asking for the SSN of each additional person listed on the account. Risk #1: Using a birth-year as a password hardly provides any security. Anyone who has access to my SSN (which is to say, approximately half of the world ;-) can also get (or guess) my birth-year. I have no idea how many tries it allows before locking out. I haven't experimented to find out how much harm I can do (i.e., cancel insurance), as I don't want to mess myself up! Risk #2: Before this "new & improved" system, I'd get mailed a form every year to fill out (took about a minute to do). The new system takes about 10 times as long to use as the old form, although it does reduce Blue Cross' expenses in processing the data. That's in part because it spells out each person's name and slowly reads each SSN to make sure it's correct. The risk is that as we automate systems, we sometimes forget that automation does not automatically equal efficiency.
I understand the difference between how earnings requests were handled without the Web interface. With e-mail requests at least there was a physical address available for law enforcement agents to help find perpetrators of crimes. With written requests, maybe they were retained and forged signatures could be used as evidence. According to *USA Today* (AP 8 Apr 1997) Paul Gambino, a spokesman for the SSA stated that "auditors can trace the origin of a request back to the exact personal computer used to make it." My questions are: How many information brokers have run a cross-match between marriage license, birth and credit databases to get the information required by the PEBES Web form? How many people downloaded all that information because it was all based on "public information"? How many thieves or foreign powers spoofed their IP address or DNS when they downloaded this information? Router intercept and impersonation? How does Mr. Gambino propose to identify these individuals? Can I demand to know every IP address that requested my earnings statement? And how does DHCP and other dynamic forms of IP addressing affect investigations? Oh, and what is the physical address of the requestor? There are conflicting reports about volume of requests. Some sources same volume increased 28 times (CNN), some say it went up from 3000 to 8500 requests per day (AP). Another says it went up from 3000 to 85000 requests per day (REUTERS). One SSA district manager reported that his office could not access their internal PEBES system due to the volume. Looks like 28 times is close. How much of this volume was automated cross-matching? 85000 requests per day? [Late breaking news: In response to cries of alarm, the Social Security Administration has apparently withdrawn PEBES at http://www.ssa.gov from public view, at least for the time being. It's hard to tell, because with the flood of traffic generated by the various postings and news articles, no one seems to have been getting through anyway. PGN]
There's a certain enthusiasm among genealogy buffs for putting their family trees on their websites. Presumably this constitutes a security exposure that such people should be aware of? Richard Hollands Richard.Hollands@mgre.com [As noted previously in RISKS, your mother's maiden name is on your birth certificate, which is also public record information. PGN]
USA Social Security numbers encode the state the US-citizen recipient was living in at the time the number was issued (aliens get a special code). Thus the "state of birth" is likely actually the encoded issuing state. [This has been true in the past. But numbers have been reused for some years now. Who knows whether the state code is still consistent? PGN]
It seems LYCOS has found their own way to alleviate people's fears about Web
security: their Web page at http://www.lycos.com/software.html seems to me
at least to border on lying about what "certificates" really are. Instead
of telling users that they're a security tool used to weed out completely
un-sponsored code, Lycos implies nothing of the sort, saying only:
The Microsoft browser supports certificates which add features
^^^^^^^^^^^^^^^^^^
to your browser. Lycos has prepared a certificate which will allow
^^^^^^^^^^^^^^^
you to search the Internet using Lycos from the address box of the
browser (where you normally type URLs). To customize your MSIE browser
now, download the certificate.
Doesn't this seems intentionally misleading? At best, it grossly
over-simplifies what certificates really are, which may lead people to fail
to fully understand the risks of accepting future certificates.
Rob Bailey, wm8s@pobox.com
Thanks to everyone who made suggestions on how to handle the spammer problem I was having. For the time being, it seems to have stopped, and I hope it stays that way. I'd like to summarize some of the suggestions that were made so that others may benefit from this: a) use procmail and return every post - I was doing this for a while, before the spammer switched domains. That's when I decided to contact the postmaster again. b) use procmail, and return every post to the personal account of the postmaster - devious, but likely to get noticed. c) complain in writing to the University, and ask about their guidelines on commercial use of their systems - had the postmaster remained uncooperative, this would have been one of the few (non-technical) avenues left. Complaining in writing was suggested specifically to try to rule out any "filtering" in case the postmaster was involved with this spamming. In any case, it looks like the user was asked to move to a commercial Internet provider, so this might start up again. I'm still annoyed at the lack of answers from the postmaster involved, and I'm really surprised that there seems to have been no disciplinary action involved. Although the sky does look a little clearer for the time being, there are dark clouds on the horizon, so to speak - I was cleaning out my mailbox, and I noticed an old spam message that came through one of the mail-by-Web sites. It was for an event this same guy's company was promoting, and the userid was based on the name of the event. If they start using "disposable" accounts to do their spamming, that will make most of the methods mentioned above a lot less effective. However, they are dumb enough to include an 800 number for one of the groups involved in throwing the party, and judging from the one time I did get a response at that number, it seems to go to someone's house. He didn't seem very pleased about my 3 A.M. call asking him why I was being spammed. ;-) Vivek
I was really confused to read of Vivek Sadananda Pai's incident with the postmaster at an university in New York. I have found that sending numerous e-mail missives to the postmaster alias almost never works. What works is calling up the school's police department or the president's office. Food for thought. When being harassed, always use out-of-band channels. http://www.packet.com/garfinkel
Please report problems with the web pages to the maintainer