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…
Thousands of electronically filed tax forms are being rejected by the IRS. Apparently that new software may be to blame. The new system requires a five-digit PIN (which is used as ``an electronic signature''!!!). Taxpayers are also required to provide the adjusted gross income and total tax from the previous year's filing. As a result, Intuit and H&R Block are both reporting 20% rejection rates on electronic returns, blamed on ``user confusion''. The IRS expects 42 million electronic returns this year — 70% of all returns. [Source: an UNDATED item at cnn.com somewhen earlier in March 2001; PGN-ed.] [Typo in March date fixed in archive copy. Added note: The 70% figure seems BOGUS. PGN]
>From : http://www.theaustralian.com.au/ Cyber surfers caught by fishing nets, AFP, 22 Mar 2001 China's Internet links with the US are threatened by the anchor nets used by the country's fishing industry. *The Shanghai Daily* reported on 21 Mar 2001 that fishing equipment had snagged underwater cables off the coast of Shanghai three times in the past two months, causing havoc for millions of Net surfers. And officials fear the problem could worsen, the paper said. China's main fishing season has just begun and industry officials say they lack sufficient legal power to stop further damage, the report added. The problem centres on a type of fishing net developed in South Korea that uses anchors sunk into the seabed. Strong tides can drag the anchors -- which are sunk lower into the seabed than Internet cables, for distances of up to 8km — severing communications links. Anchor nets are due to be phased out by 2006, but China's Ministry of the Information Industry and the Ministry of Agriculture, which regulate the Internet and fishing industry, are still working on an interim solution. For the next three months, however, authorities in Shanghai can do little but increase patrol boats in the cable areas to warn fishermen away, and industry officials warn that may not be sufficient to prevent a severe breakdown in communications. The first serious break occurred on 9 Feb 2001 about 370km off China's coast, severing the main Internet link between China and the US. Although communications were partially restored during a repair process that stretched over two weeks, 22.5 million customers, including many in Shanghai, suffered slow service, the paper reported. On 9 Mar, the Internet backbone linking Taiwan and Shanghai was cut by a fishing net about 120km south of the city, affecting four million users. When that split was finally repaired on 19 Mar, authorities found another break in the undersea cable that will disrupt Internet services for a further two weeks. Each break costs about six million UN ($1.4 million) to repair, in addition to unknown business losses resulting from the Internet disruptions.
The saga continues strangely: a rodent chewed through cable that had been exposed while Canadian National Railway workers were repairing the cut caused by the would-be copper thieves (noted in RISKS-21.27). This disrupted service to about 300,000 customers in Ontario's Niagara region, including Sprint Canada and AT&T. [Source: Animal takes byte out of Rogers, Steve Erwin, The Canadian Press, 24 Mar 2001 http://www.ottawacitizen.com/hightech/010324/5060312.html]
[Contributed by an unidentified individual to Dave Farber's IP list, For IP archives see: http://www.interesting-people.org/ . PGN] The following happened to a colleague. About a year ago he signed up for a membership at a video rental store. The form had a place for social security number and he made the mistake of filling it in. About three months later there was a message on his answerer from a bank with which he did not have an account asking about an overdraft. Upon calling he discovered that there was an account in his name with his ss number but with a different address. On calling and writing to the various credit bureaus, he discovered that there had been numerous queries about his creditworthiness. He then contacted each of these and discovered that there had been many credit cards issued in his name as well as a variety of wireless phone accounts. He called each of these in turn and got letters from the credit bureaus but could not be sure that the matter had ended. The accounts/credit cards were in states other than his but police in those communities were not responsive to complaints. Fortunately, a friend worked in a state attorney general office and he made a call to a local official in the area where the perpetrators seemed to be based. In addition, quite by accident a local house was raided for drugs. Fortunately, one of the police in the raid remembered my colleague's name so when they discovered a collection of driver's licenses from a variety of states, as well as credit cards and other account info, in my colleague's name, he was able to put it all together. There were also cards and licenses for others. The perpetrators pled and got some jail time... probably more because of the drugs than the identity thefts and fraud. All of this involved an incredible number of hours and associated aggravation to track down and fix the problem. And resolving it quickly depended on having a well placed connection and a good deal of luck. The lesson is that we are all vulnerable. Just a ss number is enough to get a fraud going. AND There is no privacy wrt ss numbers. For example, at many universities the ss number is the same as the student ID...and appears on class rosters sent to departments and faculty.
There is nothing new about this scam — the new law just allows the bank to disclaim financial responsibility for the loss. I was hit by this exact scam in Texas in 1979. After some telephone calls, the bank covered the loss and I never heard about it again. I am not surprised that the banking industry would make an effort to get legal protection so they could share the pain. For those inclined to law-breaking, this scam seems like a really easy way to steal money.... John D. McCalpin, Ph.D. mccalpin@austin.ibm.com Senior Scientist IBM POWER Microprocessor Development
First, I wish people would stop talking about Internet voting as if it was a completely different animal. It isn't. Traditional absentee voting and vote by mail are also done from the home, raising problems of difficult voter authentication and insecure ballot transmission. Direct recording voting machines and precinct-count mark-sense and punched-card ballot systems also use computers and many now offer transmission of totals over public telecommunications systems (frequently phone and radio). We should address these risks across the board! The way things are going, I'm afraid we'll end up quite properly stamping out the threat of immediate Internet voting while leaving the significant flaws of these other voting systems largely un-addressed! We should treat Internet voting as direct recording absentee voting using electronic communication of ballots and vote totals, and we should address the threats it raises by fixing the laws regarding absentee voting, direct recording voting systems and use of electronic communication in elections! Yes, the Internet does introduce some new problems, but these other problems are far, far broader! Second, I have been involved with certification testing of DRE machines, and I've found that it is extremely difficult! With mark-sense and punched card systems, you prepare a test deck or a test ballot stack, and then run those ballots through the system, checking to see that the totals reflect your test. You can hand-count your test deck and arrange all the votes to come up in easy to recognize patterns in the final total. In contract, with DRE systems, you have to stand there in front of the machine doing a repetitive and mind-numbing exercise, entering ballot after ballot into the machine. After a few ballots, your mind begins to wander. After a few tens of ballots, your fingers are sore from pushing buttons or tapping the screen, and by the end of your test, you've made so many mistakes that the numbers are meaningless. A voter casts only one ballot, and for the voter, the voting experience is a peak moment. I've concluded that DRE machines are extremely difficult to test because of this! Hundreds of volunteers (or paid experimental subjects) might be able to run a good test, but even then, they'd be required to vote from a sheet of paper instructing them what candidates to select in order to follow the test plan. Alternatively, the hundreds of voters could be closely observed (perhaps by discretely hidden video cameras), in order to observe how they vote and then compare this to the election result. The FEC's "voluntary" standards suggest a button-pushing robot to perform such tests, but for accurate testing, this would need a functioning vision system so it reacts to the feedback provided by the machine. In sum, I've concluded that the accuracy of DRE machines is extremely hard to assess — so much so that I don't see any reason to trust the assessments that have been made, whether they're positive or negative! Douglas W. Jones <jones@cs.uiowa.edu>
[From BUGTRAQ@SECURITYFOCUS.COM, Via both Mike Hogsett and Dave Stringer-Calvert. TNX. PGN] Some information regarding Verisign Certificates that has come out of this fiasco is quite disturbing but has been under reported and may have been missed by many in the security business. Pay close attention to this paragraph from the Frequently Asked Questions part of http://www.microsoft.com/technet/security/bulletin/MS01-017.asp: "The update is needed because of a characteristic of VeriSign code-signing certificates. Every certificate issuer periodically generates a Certificate Revocation List (CRL), which lists all the certificates that should be considered invalid. A field in every certificate should indicate the CRL Distribution Point (CDP) - the location from which the CRL can be obtained. The problem is that VeriSign code-signing certificates leave the CDP information blank. As a result, even though VeriSign has added these two certificates to its current CRL, it's not possible for systems to automatically download and check it. " The first question I have after seeing that is how many of the rest of the 500,000 certificates that Verisign says they have issued also do not have this CRL Distribution Point field properly filled in. In the lack of any information to the contrary I would hazard to guess that it's probably that none of the 500,000 certificates issued by Verisign have supplied the information that should be in this field. If this is truly the case then we have yet another problem of much wider scope than the improper issuance of two certificates, there are a great number of valid certificates which could be stolen or misused and even if Verisign were to add them to their CRL the certificates themselves don't point to the CRL so they won't be properly rejected. Two things need to be done, one is that software which checks certificates must be changed to warn users that certificates lacking a CRL are much more suspect and Verisign needs to re-place all certificates that currently lack this critical information with new certificates that have this field properly filled in. Additional questions that come to mind is how many other certifying agencies have also failed to fill in the information in this field and what percentage of the certificates being used today are unverifiable?
So, lets see - Microsoft says that ActiveX is secure as long as the software (ActiveX thing) is not from an "evil" source. To prevent bad software from being used, they use digital signatures to identify the person or company who made the software such that you could either trust them or know who to go after when it does something bad. The OS and system infrastructure does not try to enforce anything other than to check these certificates and warn you based on your settings as to if you want to run unsigned software or any software signed by company "X" or a number of other possible combinations of warnings. There is no built in security beyond that point. Once you say "Yes, run it" you are opening up your system to complete control by the ActiveX control. Ok, in a perfect world, with no one wishing to do harm or rob you blind, such a mechanism would work just fine. The Internet is not such a world. And now, to put this into even brighter "this is not the right way to do things" light, Microsoft says that you can not even trust that software that says it is from Microsoft really is from Microsoft unless you first check the dates on the digital signature and remember that if it is Jan 29 or 30, 2001, that it is most likely not really Microsoft and you should not accept it. What do people do now? If you accept anything from Microsoft, it is too late. If you ask for confirmation before running, what are the chances you would even think to look at the dates once you see "Microsoft" as the signing party? All of this really goes to show that security must be done at the start and not just "added in" by saying "make sure you trust the author". Even if you trust the author, there could be bugs. And, as this example shows, you can not even always trust you know who the author is. Time to think this though some more... http://www.zdnet.com/zdnn/stories/news/0,4586,5079987,00.html?chkpt=zdhpnews01
As Anton Setzer is speculating about certain things which obviously are discussed only in the Norwegian part of the report, I think I will be able to clarify a few points and bring some details not mentioned by him. Actually, the train-controlling system warned only about a malfunction of the set of points at the northern exit of Rustad station, caused by the northbound train forcing it open when driving out of the station. The warning was issued as a static text line with 16mm (0.6") high red letters at the bottom of the monitor. There was no sound signal or flashing light/text to get the train controller's attention. The warning was issued at 13:09:28 and as he was currently occupied with another train line displayed on another monitor, he didn't notice the situation before some time between 13:10:54 and 13:11:58. The report states, that the train controller can not be held responsible for overseeing the warning for 90-150 seconds. The mobile-phone numbers had been reported by both train drivers to the train-controlling central, but the train controller on duty earlier the same day hadn't written down the numbers where he was supposed to. It was also a relatively new situation that the phone numbers had to be reported to the train controlling central. Up until a few months before the accident, the railway company had been using a UPT service (like British 0700-numbers) making it possible to call a train using a (fictive) number like 0700 123 <train number>. As this service had been canceled by the operator Telenor, all train drivers had to call the train controlling central and report their train number and the corresponding mobile phone number. The report states that it is highly unlikely that the exit signal for the northbound train was green, but it might have happened, that either the red signal disappeared (no signal showing) or that it switched to green for 3-5 seconds. The reason for this is, that the security system in NSB87 which is supposed to make it impossible for the train controller to issue a green signal on both sides of a track segment operates independent of the main system and may actually take a few seconds to "discover" the failure and then do something about it. The older NSI63 signalling system operates with mechanical safety relais which should make it physically impossible, that a green signal is shown on both sides of a track segment. But, there are no commands logged from the train controller where he tries to issue a green signal to the northbound train, and there is no reason to assume that the exit signal switched to green and was corrected by the security system. The northbound train started according to the train's "black box" 13:07:17 and passed exit signal according to the train control central log 13:07:58. Time enough for the train driver to notice that the signal had switched back to red. To clarify the situation a little bit: The accident happened between Rustad station (on the south side) and Rena station (on the north side). The two trains were supposed to cross at Rustad station, but it is discussed in the report if it is likely to believe that the train driver of the northbound train had reason to believe that the crossing had been moved to Rena station. The southbound train was already delayed and the northbound train would also have been delayed if it was supposed to wait for the southbound train at Rustad. But, the train controller had decided to let the trains cross at Rustad as planned, since a crossing at Rena would have caused further delay to the southbound train and also would have caused a connecting train from Hamar to Oslo to be delayed. It is also thoroughly discussed and concluded that neither the driver nor the conductor of the northbound train could have been aware that the southbound train was delayed by about 10 minutes. But, as the report states, the train driver of the northbound train seemed to suppose that the crossing was moved to Rena for the following reasons: * When stopping at Rustad, he did not drive far enough into the station area to let a crossing train drive through the station. Because he stopped the train so far south, the main track behind him had not yet been "cleared" and the south exit signal of the crossing track showed red. * The train log shows sign of the train driver being "in a hurry". He held a higher speed than normal when approaching the station, and the train normally only stops at the station "on demand". It is clear that noone left the train at Rustad station, and the train driver might have been prepared to drive through without stopping if it had not been for a passenger waiting for the train at the station. * The train left Rustad 13:07:17 after a halt of only 15-20 seconds, although it according to the time table is not supposed to leave until 13:10. The train driver was known to be a very correct person and his watch was found after the accident still going, only 12 seconds off correct time. >- It might be that a train drives over a red light while running. In the > situation in question however, the local train was waiting at a station, > and when waiting in front of a red light, it is unlikely to drive over it. That is also what the report concludes. It might happen that a train driver oversees a red signal from a running train, but it is extremely unlikely that a train driver on purpose starts from a station and passes a red signal on purpose when he is certain, that the track in front of him is not clear. The possibility of the train driver committing suicide is discussed in the report, but the conclusion is that his emotional imbalance would have caused noticeable changes in his behaviour and driving pattern. His conversation with the train controller had been recorded and both this and the train log have been evaluated by a psychologist. The southbound train left Rena about 45 seconds before the northbound train left Rustad. I don't think the report mention anything about a relation between the two times. >From this I conclude that the following scenario might have happened [...] This should not happen. Normal procedure when leaving a station is the following: * The train driver notifies the conductor about the green exit signal. The green exit signal is only a sign that the train is allowed to leave the station and is not to be considered as a "leave now" order from the train controller. If the track is free, the exit signal is green already when the train enters the station. * The conductor is after he has been notified by the train driver that the exit light is green responsible to be sure that all passengers have left and entered the train and that the departure time has been reached before signalling the train driver to leave. This makes it reasonable to believe that both the train driver and also the conductor agreed on leaving almost 3 minutes before the time table. The report does not find any reason why that should have happened. The report ruled out [various concluding] possibilities [suggested by Setzer], with a high degree of probability. Tor-Einar Jarnbjo [PGN removed or abridged most of the interstitiated text from Anton.]
Were it in the USA, I'd also suspect the driver may have been using drugs and alcohol. All in all, though, the only RISK worse than having a human make such decisions is not having a human make such decisions. (With apologies to Oscar Wilde.) Dave Aronson, Sysop of AirNSun free public Fidonet BBS @ +1-703-319-0714
[Here is something that should be of vital interest to RISKS readers and writers alike. PGN] Call for Articles and Reviewers for an IEEE *Software Magazine* Special Issue "Software Security: Building Systems Securely from the Ground Up" Publication: January/February 2002, Submission deadline: 1 July 2001 Fragile and insecure software continues to be a major threat to a society increasingly reliant on complex software systems. The premise of this special issue is that most security breaches in practice are made possible by software flaws. We believe engineering secure and robust software systems can break the penetrate-and-patch cycle of software releases all too common today. A constructive exchange on this topic among software practitioners and researchers is the focus of this special issue. Specifically, our goal is to encourage a deeper, more fully integrated understanding of how security concerns should influence all aspects of software design, implementation, testing, and support. A notorious example is the buffer overflow problem. Known for decades and very troublesome in networked systems, it continues to be introduced into new software at an alarming rate, due in part to software development habits that trace back to isolated systems where such flaws had few security implications. An important aspect of this discussion is how to balance security with the many other characteristics of a good software system. Finally, software designers in a networked world cannot pretend to be working in isolation. People are a critical part of the full software security equation, and software that makes unrealistic or unreasonable security-related demands on users (for example, requiring them to memorize too many passwords that change too often) will inevitably fail to keep its data secure. Articles that address the issues of how to design software that works with and directly supports the need for such social engineering issues are also encouraged. Topics of interest include: - Case studies that help quantify common security risks - Security implications of programming languages and development tools - Techniques for balancing security with other design goals - Extracting security requirements from software projects - Design for security - Developing secure applications - Aspect-oriented programming for security - Analyzing programs for vulnerabilities - Testing for vulnerabilities - Secure configuration and maintenance - Developing trusted environments for running untrusted mobile code - Secure mobile code programming paradigms - Analyzing unknown software for malicious logic - Intrusion-tolerant software architectures - Software application-based intrusion detection - Models and techniques for quantifying tradeoffs in adding security concerns during development [... 5,400-word limit, caveats, etc. PGN] Guest Editors: Anup K. Ghosh Director of Security Research, Cigital phone +1 703 404-9293 anup.ghosh@computer.org <mailto:anup.ghosh@computer.org> Chuck Howell Chief Engineer, Joint and Defense-Wide Systems Division, MITRE Corp. phone +1 703 883-7615 howell@mitre.org <mailto:howell@mitre.org> James Whittaker Associate Professor of Computer Science, Florida Institute of Technology phone +1 321-674-7638 jw@se.fit.edu <mailto:jw@se.fit.edu>
Please report problems with the web pages to the maintainer