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…
According to the (UK) Daily Telegraph, the Bulgarian parliament has a system of electronic voting, whereby Members vote with cards using a machine attached to their seats. Unfortunately, the designers didn't anticipate that more enterprising MPs would swap seats and also slip a voting card into absent neighbouring colleague's machines! I would have thought the (surely obvious) solution to this problem would have been personalised cards. But instead the parliament is introducing weighing scales set into the seat so that the votes will not be counted unless the weight of whoever is sitting there matches that of the MP whose seat it is. The risks of the initial design are obvious. There appears to have been absolutely no consideration of security or checking whatsoever. The risks of the "solution" are more interesting, including the possibility of preventing someone voting in the afternoon by making sure they have a large lunch!
Pope John Paul says that the Internet caters to the best and worst of human nature and needs regulation to stop depravity flooding cyberspace. He warned that while it offered access to immense knowledge, the Internet did not necessarily provide wisdom and could easily be perverted to demean human dignity. ``Despite its enormous potential for good, some of the degrading and damaging ways the Internet can be used are already obvious to all. Public authorities surely have a responsibility to guarantee that this marvelous instrument serves the common good and does not become a source of harm.'' Although the Pope does not have an e-mail address, the Vatican has an active Web site (www.vatican.va) and the Church is reportedly searching for a patron saint of Internet users. [Source: Pope Says Internet 'Wonderful' but Needs Regulating, by Crispian Balmer 22 Jan 2002, via Reuters; PGN-ed after DM's snipping] http://dailynews.yahoo.com/htx/nm/20020122/wr/pope_internet_dc_1.html
The recent Enron/Anderson shredding frenzies suggest that it is time for UNSHREDDING software tools to come out of the closet. It is certainly feasible to restore a boxful of shreds, particularly for ordinary course-grain linear shredders. The effort for cross-cut shredders would be significantly more difficult, but still possible — although probably less acceptable in court. Anything with some natural language or graphical context is likely to be recoverable, using digram, trigram, etc., statistics for the likely linguistic base(s) and other context. However, in general, it is probably easier to start out with backup tapes and incompletely deleted disks. Easiest of all would be to install scanners and transmitters (or local storage) in the shredder mechanisms, because that would capture precisely the interesting materials deemed worth shredding. There once was a swindler named Fred Whose enterprise went in the red. The lawmen he dreaded, So papers were shredded, And off to the races he fled.
It is a principle in many jurisdictions that a jury should not know about prior charges or convictions of the accused. In a Scottish court a man was accused of a particularly revolting crime, he having been acquitted of a similar offence on a technicality a number of years ago. The judge ruled that the editor of a newspaper was in contempt of court by leaving reports of the earlier trial on line in his archive, because he had made it too easy for jurors to find out what they were not meant to know. The judge apparently believed that the greater ease of access of the on line archive as compared to a paper archive was a difference not of degree but of kind. Roger Needham
Henrico County, Va. school officials are recalling all 11,000 laptop computers that it distributed to its high school students in order to retrofit them with security software that will prevent students from using the devices for accessing pornography or changing their grades — abuses that reportedly have occurred since the machines were handed out last fall. Game and music downloading capabilities will also be eliminated or heavily restricted and instant messaging will be limited to home use. Teachers have complained that in-class use of entertainment file-sharing and messaging are disruptive. (AP/*Wall Street Journal*, 20 Jan 2002; NewsScan Daily, 21 Jan 2002) http://interactive.wsj.com/articles/SB1011563803808773240.htm
SAS Institute has developed software that it says can sift through e-mails and other electronic text to discern falsehoods. "The patterns in people's language change when they are uncertain or lying," says Peter Dorrington, business solutions manager at SAS. "We can compare basic patterns in words and grammatical structures versus benchmarks to detect likely lies." For instance, over-use of the word "or" and too many adjectives can be giveaways, according to Aldert Vrij's book, "Detecting Lies and Deceit." SAS says its software can also be used to detect inaccuracies in resumes and job applications. (*Financial Times*, 20 Jan 2002; NewsScan Daily, 21 Jan 2002) http://news.ft.com/news/industries/internet&e-commerce [Risks? What risks? PGN]
http://fyi.cnn.com/2002/fyi/teachers.ednews/01/17/cheating.software.ap/index.html A recent CNN article describes a computer program that Georgia Tech has employed to detect cheating in its "Introduction to Computing" and "Object Oriented Programming" programming courses. 186 possible violations were found (over ~1700 enrolled students.) I found this paragraph particularly interesting: But for the most part, the degree of similarity that this program is looking for — the commas are in the same place, the semicolons are in the same place, the spacing is the same, they've made the same mistakes — the only explanation, and what most students will eventually concede, is they actually did it," Eislet says. It seems to me that placement of commas, semicolons and spacing would tend to be the same for the more experienced programmers who have adopted coding standards — or for anyone who runs their program through a "code beautifier". (Unless perhaps Eislet was referring to the -comments- rather than the code!) I gather from my readings and discussions with teachers of introductory programming classes, that, year after year, beginning programmers tend to make the same -kind- of mistakes. Gross syntactic mistakes are rejected by compilers, and modern compilers that would be used in teaching environments usually remark on error markers such as using assignment instead of comparison in an "if" statement; or use of a variable before it is initialized. This filtering that takes place in the compiler would tend to concentrate the errors more and more into common problem areas such as incorrect handling of boundary conditions, and failure to test return codes on I/O operations and library calls, so coding errors are -not- likely to be uniformly randomly distributed. I would also note that every submitted program is being compared to every other submitted program for the same class, as "cheating" is pair-wise, not something that is in reference to an absolute standard. Any-time you have pairwise interactions, the number of pairs goes up as the square of the number of samples. If the marker variables are discrete and are limited in range, then one encounters "the birthday paradox", wherein it takes an unexpectedly small number of samples in order to find -some- pairwise match. My calculation is that the probability of an accidental match would have to be less than 1 in 721292 in order for there to be less than a 50% chance that the program will deem at least two innocent students in a class of 1000 to have copied from each other. Considering that Eislet is quoted as saying that for a match, "the only explanation" is that the students cheated, I would have to question whether the program authors undertook a proper statistical analysis.
Story at: http://uk.news.yahoo.com/020108/80/cnoy6.html "Compact flash memory cards used to store data on many name-brand digital cameras and handheld computers face not just data loss but become entirely inoperable when subjected to electron beam irradiation, the CompactFlash Association said on Tuesday" (I just checked the CompactFlash Association web site at www.compactflash.org and didn't see any related news-release about this, so I don't know how much research has gone into this assertion or if this is a potential birth of a new "urban legend") It does bring up an interesting technology related risk I think most (North-American) people make the following two assumptions: 1. postal service will generally deliver anything small & non-dangerous. and 2. postal service doesn't alter contents of things it delivers. When you add "technology" to either of these in isolation, there is no problem. However the technology-related risk here is that when you add "technology" (irradiation & flash cards) to BOTH of these assumptions, the result can be unexpected and damaging. Thomas Dzubin Network Analyst & PDP-11 enthusiast Vancouver, Saskatoon, or Calgary CANADA
Southern Cross Healthcare, New Zealand's largest health insurer, bought out Aetna locally. At the time, acquisition of Aetna's patient and practitioner database was one of the Southern Cross's goals. Since before Christmas Southern Cross has run into increasing delays in paying claims. This has caused cash flow difficulties for some private hospitals. Southern Cross published ads saying it was all due to difficulties with their new computer system. More recent articles tell us the predictable story - that the transition to a different system has, once again, been poorly handled. http://www.stuff.co.nz/inl/index/0,1008,1073278a11,FF.html http://www.stuff.co.nz/inl/index/0,1008,1073362a1896,FF.html
Some time back, I was doing work that involved a lot of cut-and-pasting data between Excel files. Open source file, select cells, Ctrl-C, select destination file, Ctrl-V, repeat for dozens of source files. I got tired of having lots of source files open at once, so I changed this slightly: open source file, select cells, Ctrl-C, close source file, select destination file, Ctrl-V, repeat. At first this looked like it was accomplishing exactly the same thing, with exactly the same numbers appearing in the target cells, but when I tried further processing of the data (examining differences between adjacent cells) it became obvious that something was wrong - the results were much too 'grainy'. Eventually I discovered the cause of the problem. When pasting from an open file, Excel correctly pastes the full contents of the selected cells. But if the source file is closed before pasting, it does not paste the full contents - only the *displayed* contents. The result of this is to automatically round pasted data at the display precision (so with a precision of two decimal places, a value of 1.59835 would be pasted as 1.59835 from an open file, but as 1.60 if the file was closed before pasting.) And because the rounding precision here _is_ the display precision, the pasted data looks correct until you change the precision to examine it... Fortunately, the display precision I was using was low enough to make for very large errors, so it was obvious that there was a problem. At a slightly higher precision, I could quite easily have ended up with significant but non-obvious errors. The risk here: one operation with two modes of behaviour that _look_ identical, but aren't. Geoffrey Brent
I have experienced several, apparently unrelated, incidents where Lotus Notes is quietly losing data. * I printed a mail message before I sent it. Some of the cc: addresses were quietly and permanently removed. (Did anybody say buffer overflow recently? Maybe it is more like buffer truncation, but certainly member of the same family) * Trying to reply to a mail I received, I discovered that 3 out of the about 10 cc: addresses in the incoming message had been truncated, rendering them invalid. No addresses were lost completely, but the amount of truncation that occurred suggests that a short address might be "truncated into extinction" if it is in the right place in the list of addresses. I checked the original RFC-822 header that is accessible. It was correct. By the way, correcting the addresses in place and re-sending had a very strange effect: The corrected addresses, and only those, were turned into an X.400-like address with a number of attributes pointing to my local environment. I had to remove and re-type the "sick" addresses to have them accepted. * I copied and pasted about 100 addresses from a spreadsheet into the bcc: field of a mail. Everything looked OK, the pasted addresses appeared neatly in the address window, I could scroll through them, etc. But the message was only sent to the first address. No warning of any kind appeared that a good hundred addresses had been discarded. I only discovered the error because I had asked for delivery notification, and got very few. Had I not discovered this, only a handful of people would have been invited to a presentation. (there were a few other addressees that had not been pasted in - those worked OK even though some were entered AFTER the skipped addresses). * Notes allows you to format messages, with facilities more or less equivalent to an HTML editor. If a message is sent outside the Notes domain, ALL formatting is removed, even things like indentation and paragraph numbers. So a nicely formatted message may become rather unreadable, even ambiguous (indentation may imply a lot about the meaning of a text). No warning is given that formatting information is being removed. The RISK of all this is that Notes accepts instructions to do something, does not complain about the input, and then goes ahead and does something else than what could reasonably be expected. You can obviously check for any of these events, but they are rare enough, and different enough, that you don't really know when to expect a problem, and what to look for in order to make sure everything went as expected. Erling Kristiansen
According to the *Detroit News*, Becky Sivek doesn't even have long distance service. Nevertheless, "thousands" of long distance calls all over the USA are being made. The calls disconnect as soon as someone picks up. Some people are getting this same call dozens of times a day. Although Sivek isn't making the calls, and they don't appear on her bill, caller ID shows her number, meaning that she's now getting many angry and/or threatening calls from people demanding she stop harassing them. Phone phreaks, maybe? http://www.detnews.com/2002/metro/0201/18/d06d-393292.htm Carl Fink, I-Con's Science and Technology Programming http://www.iconsf.org/
On a recent Sunday, walking past an office building in my area a woman asked me for help getting into the building. She explained she had an appointment with a tenant in the building but couldn't get in. She had dialed the company's extension on an outside phone and gotten a recorded message to 'enter #2000 to come in, if you have an appointment'. The phone used '##' to hang up calls, and it was the number of #s required that caused the problem for the woman, but I find it baffling that an answering machine is considered acceptable weekend security.
An organisation I am familiar with has a Microsoft support contract for the Microsoft components of their infrastructure; in order to access Microsoft's on-line resources, a Passport account is required. Microsoft has allocated the company a Passport account, with a numeric login whose password is set to the surname of their primary contact in the company. The risk? This is a totally predictable scheme. It would be trivial to scan the numeric Passport logins looking for passwords set to common surnames. Rodger Donaldson <rodgerd@diaspora.gen.nz>
In RISKS-21.86, Skip La Fetra ('Other blunders on "secure" Web sites')
claims that request parameters contained in a URL are not protected
(encrypted) when the request is sent via a HTTPS GET.
This is a misunderstanding regarding the actual risk of using the GET method
instead of the POST method. The traffic in an HTTPS session is always
encrypted, whether the GET or POST method is used. However, use of the GET
method encodes the parameters (including e.g. credit card numbers) into the
request URL. This exposes such info in your browser history and in the site
logs of the web server (rendering it vulnerable to the electronic equivalent
of 'dumpster diving') — the info is not, however, transmitted in cleartext.
j debert <jdebert@garlic.com> writes in RISKS 21.86 > Kaiser Permanente has a Web site for members at http://www.kponline.org/ . > > The first page here is the signon page, where one enters a medical record > number and their region to enter the site. > > A statement concerning online security ... indicates in the first > paragraph that the medical record number will be sent via SSL: > ... > However no SSL connection is possible. Every attempt to obtain a secure > connection gets redirected to the non-secure page. It's not *quite* this bad. True, if you try to go to https:/www.kponline.org, you invariably get redirected back to the unprotected page. However, the ACTION part of the sign-on form points to https://kponline.kp.org/signon/signonmember, which is SSL-protected. All further interaction with the Kaiser site after signing on appears to be through SSL via kponline.kp.org. But they make the same mistake mentioned by Skip La Fetra earlier in the same RISKS digest: the medical record number is transmitted in the URL. So Kaiser's claim is incorrect; the medical record number is not protected by SSL. Once you've registered, you need a PIN to sign-on, and that *is* sent via SSL, so the PIN and the rest of your session apper to be reasonably well protected. But in order to *get* a PIN, the only "authentication" data required (besides the record number) is your full name. I guess if you're a Kaiser member you should register on this site before someone else does it for you. George C. Kaplan, Communication & Network Services University of California at Berkeley 1-510-643-0496 gckaplan@ack.berkeley.edu
This is familiar to Web designers, and should be known by someone like McAfee. First, many people have JavaScript turned off. If the script is not going to be completed, then the designer should have more sense than to write out the "This page current as of ". This should be included in the script as well, so that people with JavaScript turned off will not see anything at all. Second, the JavaScript date may be presented by a source that is unreliable - such as the client's system date - or unsupported - such as "date modified" in some browsers. The site seems to lack a good "sniffer" to find out (1) if JavaScript is on and (2) if the "date modified" function is supported. There is little risk presented by this site, but one wonders if the people who designed it have since moved on to emergency services or air traffic or defence sites.
> Also note that a "bounce" message would take this whole saga out of the > "risks" venue (or at least move it to the margin). Would that that were true, but bouncing spam merely introduces new risks. I was intimately involved in AOL's mail system for most of the past decade, and our motto was It's Not That Simple. AOL hasn't always had spam filters. Years ago, we would see huge numbers of bounce messages generated for spam runs, since spammers often send to e- mail addresses that are no longer valid. One spammer actually sued us for delivering his bounces back to him - he said we were trying to overload his small mail server! (Apparently the huge volume crashed it.) And once spammers started forging return addresses, these bounces began causing no end of trouble for the poor site that found itself receiving millions of undeliverable e-mail reports from AOL. Additionally, we had to make sure that these huge queues of bounce e-mails didn't interfere with the delivery of legitimate communications, or even bounces of legitimate communications. Far from taking minutes to deliver, these bounce queues can quickly back up to infinity without constant babysitting. With SMTP, if you can detect that a message is undeliverable early enough in the process, you can simply refuse it, rather than bounce it back. But that presumes that the machine sending to you is the originator of the message. Spammers often relay their e-mail off unsuspecting third-party mail servers that are configured to accept mail from anywhere and deliver it to anywhere. (This was the default configuration of all mail servers until just a few years ago; remember, the Internet began as a cooperative effort.) If you refuse mail from a third-party relay, THEY then have to deliver the bounce messages, which again can crash or hobble their systems. Of course, if you simply turn off spam filters on a system as target-rich as AOL, you're left with a fairly useless mail system - we've often estimated that 30-50% of all the incoming messages are spam. I've since left AOL, but I know that the folks there were doing everything they could to detect spam as early in the transaction as possible, and refusing it rather than bouncing it whenever they could. The real risk is taking a protocol designed to cooperatively exchange messages within a small community, and using it for worldwide, mission- critical communications, sometimes from hostile senders. The rest is imperfect band-aids.
WORKSHOP ON OPEN SOURCE SOFTWARE DEVELOPMENT, 25-26 FEBRUARY 2002
Newcastle upon Tyne, UK
http://www.dirc.org.uk/events/ossdw/main.html
The focus of the Open Source Software Development workshop is on
dependability and open-source software development. Dependability is a
deliberately broad term which, among others, covers reliability, security,
safety and availability.
We have put together an exciting programme and would welcome further
participation from the community. Participation would be particularly
welcomed from any of those engaged in, or affected by, the design,
development or operation of open source software. An important objective of
this workshop is a greatly improved understanding of the complete
organisational and cultural context of complex systems of which computers
are a part. To this end, we especially encourage participation from
interdisciplinary researchers and practitioners, since we believe that such
research is crucial for progress towards the safe deployment of new
technologies.
Those interested in participating in this event should send an e-mail
stating their interest to Cristina.Gacek@ncl.ac.uk, preferably by 15th
February 2002.
Cristina Gacek, Centre for Software Reliability (Bedson Building)
Department of Computing Science, University of Newcastle upon Tyne
NE1 7RU - United Kingdom Telephone: (44 191) 222 5153
FAX: (44 191) 222 8788 cristina.gacek@ncl.ac.uk
Please report problems with the web pages to the maintainer