This is too good to be true, but I'm afraid it is. I own a tiny (just me) California corporation. Every year, I have to file a form listing my address, the names of the top officers, etc. It turns out that the form can be filed online (though you have to enable Java to do so). If you go to https://businessfilings.ss.ca.gov you can type in the name of any corporation registered in California and be presented with the corporate-info form. If you type "Microsoft", you'll get several with MS in the name, including one that's located at One Microsoft Way, Redmond, WA. Keep clicking and you can fill out the form with "corrected" information. It costs a $25 filing fee, which can be paid with a credit card. They also collect an e-mail address, though I don't know why. So if you have a stolen credit card and a throwaway e-mail address (e.g., at mailinator.com or just good ol' hotmail), you can change Microsoft's information. For MS, it would probably get caught fairly quickly. But you could cause a lot of trouble for a smaller company. For example, maybe you could change their information, then sue them. Not knowing about the suit, they'd default. Then you could change the information back and institute proceedings to collect the judgment. Hmmm, I wonder if I could sue Bill for a couple of billion? — Geoff Kuenning email@example.com http://www.cs.hmc.edu/~geoff/
I've just been rather shafted by this one... I have a publicity mailing list, which I maintain as a local alias in qmail on my mail box. I send out periodic mailshots, to myself as main recipient, but BCC:'d to the mailing list, for brevity and privacy. Well, apparently not. Either the EMACS mail system, or the qmail delivery system (probably the latter) drops the supposedly private BCC: address into a Delivered-To: header, visible to all recipients. And in a bad-goes-to-worse scenario, this alias address has found its way into an e-mail list currently being used by a virus on a compromised broadband machine on Bellsouth, so it's managed to send its payload to my entire mailing list. (And, of course, the virus does indeed come through, and depart from, my mail machine.) I've now nuked all my supposedly private mailing list names, and will use completely transient ones in future, but this is something of a wake-up call to my assumptions about secret mail headers. nick rothwell — composition, systems, performance — http://www.cassiel.com
Together with Andre Broido and kc claffy from CAIDA, I have been working on methods for remote physical device fingerprinting, or remotely fingerprinting a physical device without any modification to or known cooperation from the fingerprintee. At a high level, our fingerprinting techniques exploit microscopic deviations in device hardware: clock skews. At a low level, our preferred technique exploits the fact that most modern TCP stacks implement the TCP Timestamps Option (RFC 1323). When this option is enabled, outgoing TCPs packets leak information about the sender's clock. This work further supports the following well-known observation: there can be security relevant information in what one might traditionally consider to be noise. Our paper and abstract available here: <http://www.cse.ucsd.edu/users/tkohno/papers/PDF/> <http://www.caida.org/outreach/papers/2005/fingerprinting/>
From my reading of the story, Mr. Plum seems to have jumped to some conclusions. One, I didn't see any mention that the data was not encrypted. Two, the tapes seem to have been shipped as cargo, not in someone's baggage. There was a specific statement that the tapes were being shipped to a backup data center. Something normal for disaster recovery planning. Considering that the tapes contained data about government officials and at least one Congressman the theft may have been part of someone's "Opposition Research". [But if it was encrypted, why the BofA statement that no misuse of the data is known to have occurred (yet)? Why not say that the data was encrypted, and therefore this was no big deal? PGN]
Why not always have TSA inspect the bags in the presence of the owner, who is then allowed to lock them? > Failure to encrypt these backups before they went offsite seems > negligent of BofA to me. Perhaps. But this is a minor transgression compared to the ChoicePoint issue. ChoicePoint deliberately sold personal information that didn't belong to them, without the permission of its owners. The fact that the buyers weren't who ChoicePoint thought they were is a side issue. If I somehow learned private information about you, and sold it without your permission, you ought to be more upset at me than if you had given me private information, a copy of which was then stolen from me.
> The "TSA [master] key" lock idea will just mean the thieving baggage > handler will acquire one of the master keys beforehand. Or not even bother. I have already had two TSA master key locks removed destructively. I view the TSA master key idea as nothing more than a scam to sell new locks. It has nothing whatsoever to do with security or fighting terrorism.
I would like to comment on the remarks made so far concerning the UK ITsafe web site. It so happens that I know the guy responsible for planning and implementing the site on behalf of HM Government and we had a long conversation about it the week before it went live at the DIPCOG conference in Leeds. The first and most important thing to note is that this site is aimed at people who have absolutely zero knowledge of technology, risks or security. At the risk of sounding patronizing, those who are complete IT novices (e.g. someone who may well have just bought their first ever computer and plugged it into the phone line) are the ones the site is set up to benefit. It is, IMHO, important to view the message that the site carries and the way in which it does so from the viewpoint of those people, not the informed position we have as Infosec/IT/risk management/whatever professionals. Those with knowledge look at bugtraq, CERT, WARPs, a/v provider alerts, etc, the general public does not - and most probably wouldn't understand the output and what to do with it if they had it. The designer had to balance a whole set of risks - if it's too secure or complex the target audience either won't be able to access it or won't understand it and will just go away again. If you know how to use S/MIME or PGP signatures you are too knowledgeable to benefit from the ITsafe site. The issue of hacking/spoofing has been considered and they have some plans. My friend was, quite rightly, somewhat reticent to reveal them... >> 1. This would be a great site for the Malware Brigade to spoof. I hope >> that it is more secure than most Web Sites. > >Sadly, no: > >Signing up for e-mail or SMS alerts does not appear to require any >address confirmation, so presumably anyone can sign up anyone else's >e-mail address or mobile phone for alerts. Also, no secure (SSL/TLS) >form is provided for submission. > >I am also dubious about the 'ITsafe Word' scheme to protect from spoofing by >the 'Malware Brigade' — http://www.itsafe.gov.uk/glossary/itsafeword.html >definition: A security feature used on the ITsafe website to help reduce the >risk of someone spoofing our e-mails. > > When you sign up to our e-mail service you are asked to type in an ITsafe > Word (please keep this clean). This is not a password, so if you forget > it, it is not the end of the world. You just need to be able to recognise > it again in the future. > > All e-mails we send to you will use this word in the 'subject' line. In > e-mail programs this is normally displayed just above the e-mail > content. You can quickly check that the e-mail has come from us as someone > else would not know your ITsafe Word. > > Until you forward the e-mail, forgetting to remove it (not that it mentions > that people *should* do this on forwarding etc). Or post it to USENET, or... > > I wonder if they have heard of S/MIME or PGP signatures? > > The problem here is that quite a lot of people will probably receive this as > a forward, all malware would need to do is search mail folders for a > legitimate bulletin (identified from mail headers) with the ITsafe Word in > the subject line and use this to construct a forgery to attach itself to... > > ITsafe site URL http://www.itsafe.gov.uk/index.html David Alexander, Towcester, Northamptonshire, England http://home.rednet.co.uk/homepages/dave_ale/dave_ale.html
> ... I would be very surprised to be held responsible for failing to read a > message that was properly refused. Really? I had thought that bounce messages were pretty much obsolete. I am forced to killfile all bounce messages directed at me, since the vast majority of them report bounces of spams forged to be from me. Not only has it long been the cast that the vast majority of e-mail directed at me is spam (or viruses, worms, bogus bounces, and other junk), but it's also long been the case that the vast majority of e-mail that appears to be *from* me is spam. I believe that same is true of most people with non-secret e-mail addresses. Spammers harvest addresses for *two* reasons -- to get addresses to spam, and to get addresses to forge. Over a year ago I gave up on filtering, and started whitelisting. Everyone with whom I've exchanged e-mail or newsgroup postings is on my whitelist, as are all the regular RISKS posters, and about eleven thousand other people. I also have a disposable e-mail address on my web page which anyone can send to. And I've borrowed PGN's trick of accepting anything with "notsp" (or any of a few hundred other key words and phrases) on the subject line. This has reduced the volume of spam to a tolerable level, but it *still* exceeds all legitimate e-mail. The real RISK here is assuming that e-mail is reliable. I never assume anyone has received my e-mail unless they tell me they have. Why are courts relying on it? I thought they didn't even rely on snail mail, other than *registered* snail mail. Also, the lawyer in question should have whitelisted the court, and anyone else he had business dealings with. There's plenty of blame to go around. What next? Being served papers, not by a process server, but by e-mail? "If you do not reply to this e-mail, we will assume you have no objection to the court awarding the plaintiff everything you own and everything you will ever earn". Sigh.
>One would conclude from this that the law firm had unmonitored software that >was throwing away mail willy-nilly. Or perhaps that the law firm's system >administrator configured it to do so. Both are serious charges that are >likely to cause fear and doubt among users of e-mail systems. It is unlikely >that either is true. On the contrary, both possibilities are quite likely. >I submit to the court that the most likely facts are that the filter sorted >the court notice into a possibly-spam folder and that the lawyer failed to >look at the folder regularly. This is certainly a possibility. However, anti-spam software has improved to the point where there are very few false positives and so many users don't even bother to review their "possible spam" folders. >The next most likely case is the one I find the most disturbing: that the >law firm's system refused the message (smtp 550) or accepted it and mailed a >bounce notice back. But if this happened, why would the court issue the >show-cause order? In my experience (operating an anti-spam system with over 50,000 users), the most likely causes are mis-configured sending mail systems and accidental problems. Many sending mail systems do not follow modern standards regarding things like being properly configured in the DNS, having the "From" address match the sending system, or even following the RFCs that specify how to format messages. If I were investigating the problem, I would look closely at how the court system's mail server was configured. Accidental problems include things like having a document include innocent words or abbreviations that trigger spam scores. For example, reports including "cumulative grade point averages" which abbreviate words to, say, their first three letters. If I were investigating the problem, I would also look for problems of that sort. [...] I suggest that you may need to revise your expectations about e-mail. Roughly 2/3 of all incoming messages to our system are spam or viruses and neither should receive bounce messages. In fact, if we were to send bounce messages about viruses, we would be soundly trounced for the practice. And, as you should be well aware, sending bounce messages to spammers simply causes them to send you more spam. Finally, even if I were to send a bounce message, the court's system would probably classify _it_ as spam and the judge would never see the bounce. The only reasonable assumption these days is that the message did _not_ make it unless you have received confirmation that it did. >By the laws of wishful thinking I assume that the court does not ignore its >bounces, and that the law firm's system does not throw away mail without >notice. Therefore the court was in error. Unfortunately the filter >software is not a person under law and cannot file for damages! Both laws are indeed wishful thinking. The court's e-mail system probably classifies bounces as spam and discards them. The law firm's system throws away lots of mail without notice. The error is the court's in assuming that sending an e-mail message and not receiving a failure notice means that the message has been delivered. That assumption is not a reasonable or valid one in today's world. Unfortunately. Craig A. Finseth, Firwood Consulting, Inc., 1343 Lafond, St Paul MN 55104 http://www.firwood.net +1 651 644 4027
Paul Smith reported a US bank refusing to believe an address in Enfield, UK. I used to have a US bank account; its web page was useless because it insisted that one give a 5-digit zip code. New Zealand and Australia have 4-digit ones, Canada and UK have 6 or more characters in a mixture of letters and digits, ... John Harper, School of Mathematics, Statistics and Computer Science, Victoria University, PO Box 600, Wellington 6001, New Zealand (+64)(4)463 5341
A few years back I tried to buy something from a website in the USA from New Zealand. New Zealand has a population of 4 million, and is about the same size as the UK. There are no Post Codes, zip codes, provinces, or states. Presumably the situation is similar in other small countries. The website refused to recognize an address without a zip code and state, although it did allow me to live in another country. I sent an e-mail to the webmaster and the problem was fixed the next day. Our nations with their boundaries, laws, and armies are legacies of the kingdoms of medieval Europe. Credit cards, global corporations, and the Internet are making them more and more irrelevant. If you want to do business on the Internet, you have to be able to cater for all your customers. Security Services National Australia Bank Limited +61 3 9886 2401
[This thread is now running thin, so this issue may end it for now. But it is a very important topic, and for that reason I let it run a little longer than usual. PGN] Steve Taylor <steve.taylor@PETARDSCS.CO.UK> notes the fundamental fallacy in comparing the "design" of software with the "manufacture" of physical items. Software "manufacture" is practically cost free, while in physical engineering cost is dominated by manufacturing. So the real comparison is between *design* of software and the *design* of complex physical artifacts: such as a suspension bridge, a CPU or a kitchen. When I design a kitchen I draw out the room to scale on a piece of paper, make cardboard cutouts of the various items, and then try out various arrangements. I abstract away almost everything about a cooker, say, apart from its (scale) size and power requirements. By using a language at the appropriate level of abstraction (cardboard cutouts and paper), the design process is simple and effective. The CPU designer doesn't personally lay out the location of every gate and wire: he uses the appropriate high level abstractions and the CAD software fills in all the details: ensuring that all the constraints on wire separation and length are preserved automatically. The suspension bridge designer uses the appropriate mathematics to *prove* that her bridge will stay up and carry the required load before construction is started. Jan Vorbrüggen points out that physical systems are dampened, or can be designed to be dampened, so that a small change in initial state results in a small change in output: while computer systems are strongly chaotic. On the other hand, the mathematics required to design physical systems (differential equations, nonlinear fluid dynamics etc. etc.) is fairly heavy going, while the mathematics required to *prove* the correctness of a computer program (basic set theory and logic) is comparatively straightforward. Proofs of correctness of programs are possible when the programs are small enough and written at an appropriate level of abstraction. The biggest advances in programmer productivity (discounting advances in hardware due to Moore's Law) came with the switch from machine code to assembler language and again with the switch from assembler to high level languages. The next order of magnitude advance will *not* come from using component libraries in existing OO languages, such as C++ or Java. Instead, what is required are languages at a higher level of abstraction, and this necessarily implies domain-specific languages, which have been designed and implemented with the appropriate formal methods, with the primary aim of enabling correctness proofs to be carried out. Why do we still have buffer overflows and dangling pointers when languages exist in which it is impossible to implement a buffer overflow or a dangling pointer? Unfortunately, there has been very little work over the last 20 years on the design and implementation of very high level domain specific language based on formal methods and correctness proofs. I believe that the way to gain higher productivity and reliability in large software development projects is to turn the large development project into two much smaller development projects: (1) Design and implementation of a domain specific language in which it is easy to develop the required system; and (2) Develop the system in the language designed in step (1). If the language is released as free software, then the work involved in project (1) can be shared among all the designers working in a particular domain: and the cost savings are even greater! The design and development of the FermaT program transformation system follows this approach. FermaT is implemented in MetaWSL, a language for writing program transformations. 54,000 lines of MetaWSL compiles into nealy 200,000 lines of C: but the MetaWSL is easy to understand (for one familiar with the domain), while the C is impenetrable! These ideas are explored in more detail in my paper "Language Oriented Programming", Software---Concepts and Tools Vol 15, pp 147-162, 1994 http://www.dur.ac.uk/martin.ward/martin/papers/middle-out-t.ps.gz Martin.Ward@durham.ac.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
The reliability of components has always been somewhat suspect, for example the Basilica project  tested various POSIX compliant O/S and found that large numbers of the system calls and library routines contained bugs that would cause core dumps. The faults being mostly connected null pointers being passed as parameters etc. Things don't seem to be that much better in the open source world either, Torkar et al.  performed unit testing on a number of open source classes and found that they could trigger errors with minimal effort. The situation doesn't seem to be any better with other sources, Kuhn  surveyed results for the number of variables required to trigger a failure and found that for medical devices approx. 70% of failures involved only one variable, NASA's Deep Space One craft did little better but the Mozilla and Apache open source projects came in at 30-40%. Of course that could be because of inadequate error reporting. This is of course slightly annoying given that Duran and Ntafos  observed nearly 20 years ago that the bugs they were finding could have been found with *any* sort of reasonable test process. Of course the problems is worse that this because the majority of the studies cited above examined functions more or less in isolation and as Peter Ladkin is fond of pointing out safety is not composable, and I suspect neither is the use of components in a software systems. That is, just because the components all work perfectly on there own I'm note sure that it is realistic to assume that this will produce a reliable system though I suspect that it may help. However it does seem to be possible to build reliable software, as noted by Ladkin (RISKS-23.37 after ) automotive software seems to be highly reliable a similar conclusions are reached by Littlewood  and McDermid  at lower levels using the same data. However it should be noted that the data is from the 1998-2001 period and the analysis has not yet been repeated for newer vehicles.  Koopman, DeVale : Comparing the Robustness of POSIX Operating Systems, FTCS 1999  Torkar et al. : An exploratory study of component reliability using unit testing. Proc. ISSRE'03.  Kuhn et al. : Software fault interactions and implications for software testing, IEEE TSE Vol. 30 No. 6, June 2004  Duran, Ntafos : An evaluation of random testing IEEE TSE Vol. 10 No. 4 July 1986  Ellims : On Wheels, Nuts and Software, 9th Australian Workshop on Safety Related Programmable Systems SCS'04  Littlewood, Assessing the dependability of software based systems: the important role of confidence, KKIO2004, Gdansk, Poland.  McDermid, Kelly : Software in Safety Critical Systems: Achievement and Prediction, Proc. Institution of Nuclear Engineers Conference, 2004 (to appear) Mike Ellims, Chief Engineer, Pi Technology firstname.lastname@example.org www.pitechnology.com +44 (0)1223 441 434
The theory of component re-use is great. The implementation often stinks to the point where roll-your-own is the superior alternative. My pet peeve is the combination of... a) you can't get individual components, you can only get a huge library with zillions of components, even though you need just one or two of the routines in the library b) There isn't just one humungous library. Every developer and his dog is bringing out their own "superior" library. perl used to be a "Practical Extraction and Reporting Language". Now it's ballooned into something huge, requiring support libraries of its own. Don't get me wrong, perl is an OK operating system, but it lacks a lightweight scripting language. On linux, some programs require perl. Other programs require python. Other programs require PHP. Some require Gtk 1.x series, while others require Gtk 2.x. Etc, etc. So in order to get a full system, you end up loading a ton of libraries, each of which is huge in its own right. I started using linux 5 years ago on a beat-up old Pentium Pro with 16 megs of RAM, which had originally come with Windows95. Today's full versions of Windows and linux aren't really comfortable in less than 512 megs, although linux allows one to drop the GNOME/KDE "Desktop" eye-candy and run with a lightweight window manager. How long will it be before we start reminiscing fondly of the days when "640 megs of RAM was enough for anybody"? A risk of "component monoculture" is that if a widely used component has a flaw, everybody's vulnerable, especially if the component handles e-mail for websites. This isn't just a Windows problem. A few years ago it was Matt Wright's (in)famous formmail perl script that was a spammer's delight. More recently, PHP-Nuke has been abused by spammers to flood my inbox. Walter Dnes <email@example.com>
Please report problems with the web pages to the maintainer