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…
On 9 March, an unidentified user posted a message concerning backdoors, bugs, and Oracle7. He mentioned a specific (security-relevant) bug that he had reported through Oracle's normal bug reporting mechanisms and which Oracle has subsequently fixed.
It is general - and prudent - security practice not to publish details of security-relevant bugs, in order to protect exposed systems from potential attack. In his rush to expose `backdoors and bugs,' The unidentified user has irresponsibly put other Oracle7 customers - who may not have had a chance to upgrade - at risk, while his systems are, of course, protected.
(As a sidebar, many of his other comments were inaccurate - but a
discussion of the reasons for this properly belongs on
comp.databases.oracle rather than this forum.)
The RISK? That users who think they know a little about security can, by posting before thinking, create or magnify the threat they are allegedly trumpeting against.
Mary Ann Davidson <madavids@us.oracle.com> Manager, Security Product Management, Oracle CorporationI recently got a call from a friend where I used to work (The MITRE Corporation). MITRE recently "re-engineered" their financial systems. It turns out that these "new and improved" systems mis-printed the W2 forms (U.S. tax form showing earnings and tax withholdings. Up here in Canada we call it a T-4 form, eh?) The employer ID number was printed incorrectly. It should start with a leading zero, but this zero was suppressed, leaving the employer ID with the wrong number of digits.
MITRE made a quiet announcement about this problem in its weekly news bulletin, and it was only through a phone call from a friend still there that I found out about this problem.
My mother recently had a problem with a IRS 1099, which mistakenly reported tax-exempt interest income as taxable. She was lucky to catch the mistake. Otherwise, she would have received a dunning letter from the IRS assessing taxes and penalties and requiring lots of back-and-forth to rectify the mistake. (Been there, done that...)
The MITRE incident raises two questions, one technical and one social.
Technically, the problem with the mis-printed number is the distinction between "radix numbers" (e.g. Federal Employer ID number, Social Security Number) which are required to have a fixed number of digits, and where the leading zero is significant, and "cardinal numbers", where the leading zero can (and usually should) be suppressed. Of course, COBOL gets this exactly right, with two different format strings (9 and Z). But other languages don't make this clear distinction, and I suspect that the MITRE system was not written in COBOL... (I shudder to think what it WAS written in. There are lots of horror stories about the failure of this system...)
The other issue concerns the employer's responsibility to report errors on computer-generated forms, to both the IRS and to the former employee. I think that publishing a "by-the-way" notice in the company newsletter is NOT a sufficient response to errors on a legal document. (If anyone thinks that a W2 is not a legal document, good luck arguing this with the IRS!)
The unfortunate thing about computers is that it's so easy to replicate mistakes. (Reminds me of the ``Dear Rich Bastard'' letters...)
[See RISKS-14.89, with a follow-up from Mark Brader in RISKS-15.08. PGN]dave emery
As I sat reading the latest RISKS, the local Radio Station here announced that their computer is down, so they won't be playing any advertisements — just music all afternoon. Apparently all the adverts are now kept as digitised files on the computer rather than on "carts" as they formerly were. I'm sure there's a "risk" in this story somewhere, but I'm not exactly sure what it is.
[Count your blessings, not your adverts But it is amazing that they could not ``Ad lib''! Most stations keep manual backup copies or readable hardcopies for just such situations — they hate to lose ad revenue. But, I hope this outage was not blamed on a home-grown compiler, so that we can conclude that ``The key, we see, is not the KiWi-C.'' PGN]
Has anyone else been surprised by an FTP server, when it denies access because of too many users, affirming that the user-count isn't a bug?
For example, the ftp.adobe.com site gives the following message: # Sorry, there are too many anonymous FTP users
# using ftp.adobe.com at this time.
# There is currently a limit of 90 anonymous users.
# This message is not the result of a bug.
What is the purpose of the last line? I can't imagine that it's actually somehow checking number of users in more than one way, and only generating the "not a bug" comment when both methods match (and therefore generating a "this might be a bug" message if there's a discrepancy). All I can think of is that someone once reported a bug which turned out not to be a bug and the comment was put there to prevent more non-bug reports when the server's busy.
The risks are somewhat obvious, although minor. If there *is* a bug, it'll take longer to find and fix, because it's clearly labelled "not a bug", so it won't get reported as soon or often. I think there's also a risk in the programmer attitude that erroneous bug reports can be best prevented by such disclaimers - I'd much prefer that an informative sentence (such as "it's not uncommon to see 300 users or more trying to access this site") be displayed than a condescending and difficult-to-believe "this is not a bug".
Mark Rafn dagon@halcyon.com <http://www.halcyon.com/dagon/>Here I am, watching the Discovery Channel. There's this show called "Invention", which has this interesting story about Automated Teller Machines. On the show they have the Scottish inventor of the ATM, Shephard Barron (I probably have the spelling wrong). They go and introduce him and show him walking down the street of his home town, and him walking up to an ATM and in plain sight you see him insert his card and TYPE IN HIS PIN! If that weren't ironic enough, later on in the story you hear him talk about how he had some buddies at MI6 try to break the system. (they couldn't) You also got to see at least one other "person off the street" demonstrate the ATM and his poor PIN is seen typed in in plain view. (in closeup this time!) The risk? Shows like this only reinforce people's ignorance of how important it is to keep PINs private.
--DaveI am having a really difficult time working up much sympathy for the folks who complained in RISKS about the html "mailto:" code getting triggered: Netscape 2.0's security flaws have been widely noted. But I find it very interesting that RISKS readers, who ought to know better, are still using a browser with known security problems. (Netscape 2.01, which has been out for a week or so, has plugged this particular hole, and allows you to turn off Javascript altogether).
For all the complaints decrying the ignorance of "those people out there still running unsecure sendmail, etc.", we find that even those that "know better" still do the same thing. Of course, like the majority of drivers who think that they are the minority of very good drivers, RISKS readers probably think that "they know what they are doing".
==Doug Claar[Besides, Netscape is paying good money to folks who are helping them find new flaws! Sounds like a constructive strategy, considering how difficult it is to solve the security problem, especially in the presence of Trojan horses! PGN]
On March 27-30, MIT (and its Laboratory for Computer Science, together with the World Wide Web Consortium) will host the Sixth Conference on Computers Freedom and Privacy (CFP). Since its inception in 1991, the series of CFP conferences has been the premiere forum for exploring the implications of computer and telecommunication technologies for privacy and civil liberties. This year's conference brings together international experts from the fields of computer science, law, business, public policy, law enforcement, and government to confront controversial issues that have dominated public discussions of computer communications policy over the past year.
Highlights of the conference include
> Emily is only 8 years old and, therefore, is not *eligible* for jury duty...
I'm guessing there's more to it than this. As far as I know, all potential juror names are pulled from some known pool. Traditionally, the list of registered voters was used. Some areas are now using lists of licensed drivers. Either pool would yield people of the proper age. The last time I served at the county level here in Pennsylvania I was pulled from the list of registered voters. However, we were told that licensed drivers would be used in the near future to get a larger pool and not discourage people from voting to avoid their "other" civic duty. I don't know if this sort of decision is typically made at the state or local level.
No comment on WPVI. But if you're in Philly and it snows, you can turn to Channel 6 to see every flake.
Steve Sapovits Telebase Systems steves@telebase.com http://www.musicblvd.com and http://www.telebase.comThe *SJ Mercury* article about this had a bit more information. Near the end of the article they listed just what it was that the FTC found in its first busts. The scams had nothing to do with the Internet: they were the same kinds of scams you see flyers for on non-computer bulletin boards and the classified ads of most newspapers (credit history fixing and so on).
The RISK here is that people tacking the word "Internet" onto the job they are already doing makes the job sound more important and the Internet more dangerous than the rest of the world. In this case, neither are true.
--Paul Hoffman, Proper Publishing: ... postings on Motley Fool and other BBSs have contained false information
This is speculative and misleading. No one has demonstrated that online discussion influences the price of a stock. Companies often complain to the SEC about alleged manipulation; such complaints, in my experience, are usually spurious, as there are no adverse consequences to the company from making unfounded claims.
Share prices go up or down primarily on the decisions of mutual fund managers, who don't have the time or inclination to read newsgroups. The amount of capital controlled by Internet users is minuscule compared to the $1+ trillion in equity mutual funds.
Concerning the attempt to record Hare Krishna chants on a telephone answering machine...
When Ma Bell invented touch tone dialing it was quite reasonable to choose frequencies that fall within the range of the human voice — after all, all the equipment was and still is optimized for that range. It was many years before anyone tried detecting these "DTMF" tones in a context where a person would be speaking. It is difficult to avoid false detection of DTMF tones in human speech. Of course, if the telephone answering machine industry had waited around for the development of "out of band" signalling systems such as ISDN, a multi-billion dollar industry would never have gotten off the ground.
Tony Panero / home: panero@netcom.com / work: tonyp@clipper.robadome.com[Also noted by "john (j.g.) mainwaring" <crm312a@bnr.ca>. PGN]
Voice activation of tone-detection equipment is a long standing issue with voice mail/answering machine systems. The problem has been significantly alleviated by the transition from analog circuitry to digital signal analysis, but some voices still register as one or another DTMF signal. Fortunately, digital signal analysis has eliminated the far more annoying problem of the recorded message triggering tone detection when it is played back. If the expected signal may be both quite brief and the margin of error is wide (to accommodate some PBX systems which generate fixed length and remarkably dirty tones), a wide variety of voices may cause a problem.
For the record, my answering machine thinks that Lisa Kudrow and Chrissie Hynde singing harmony on "Smelly Cat" sounds like a DTMF * (end-of-message indicator). Or maybe it just has taste...
Kevin RainierThe Computer Security Institute invites you to submit an abstract of a proposed topic to be considered for presentation at the 1996 23nd Annual Computer Security Conference, November 11-13, in Chicago.
We are looking for presentations on the following possible topics: access control, electronic commerce, remote access security, Internet, cryptography, risk management, business continuity planning, security awareness, telecommunications security, network architecture, wireless network security, LANs, WANs, management issues, network viruses, client/server systems, single sign-on, imaging, privacy issues and e-mail.
We are particularly interested in case studies — in-depth practical discussions of network-related security projects, problems, and solutions for the real world.
Next year's conference will offer approximately 120 scheduled sessions. Faculty are intended to address a broad range of experiences, expertise and interest in networks and related security issues. Sessions generally run one hour and fifteen minutes. Double sessions are scheduled if warranted by the topic. If your abstract is selected, you are required to provide a paper for inclusion in the proceedings.
Applicability to Attendees The proposed presentation should offer successful concepts, models, processes and applications useful to those responsible for information security.
Innovation/Originality A presentation that advances existing or presents new ideas is better than a presentation that merely repeats information already widely known. The timeliness of ideas is important. A presentation designed to sell a name product or service will be rejected. A presentation should focus on the general attributions, benefits and drawbacks of a given application or tool.
Some general guidelines Courses that offer tips and techniques to increase productivity, in addition to theory, are much more valuable. Sessions on novel and unique applications of products and tools are good but keep in mind that emphasis on a single product can limit the scope of appeal for the class. Case studies of computer security projects, problems and solutions are very popular.
To ensure a wide variety of perspectives, no more than three principal speakers per organization will be allowed to present at the conference. Papers presented at other computer security conferences will be disqualified unless they contain substantial new or updated information.
The Submission Process To be eligible for selection as a speaker, you will need to submit an abstract that describes the content of your talk(s), a biography that describes your background, and complete contact information including your e-mail address
and fax numbers. We must receive your submissions by April 15, 1996 to be considered. Please include any scheduling conflicts you have
as well.
The abstract should be approximately 200-300 words (8-10 sentences), and classified by the presenter as entry-level, intermediate or advanced. Please provide 3-6 "bullet points" telling us what attendees will learn from your session. Indicate any special prerequisite knowledge required of participants and emphasize what attendees will learn.
We prefer to receive submissions electronically. E-mail should be sent to prapalus @mfi.com. Upload to the CSI BBS at 415/905-2480. Abstracts can also be mailed to CSI, 600 Harrison St. San Francisco, CA 94107 or faxed to 415-905- 2218. For more
information, please call Patrice Rapalus at
415-905-2310.
Speakers receive complimentary registration for the 2-1/2 day conference and attendance at all lunches and receptions.
[I just received my copy of CSI's NetSec '96 program. It identifies Gene Spafford with Perdue University. Perhaps he has become a Friar? Or he deserves a Pullet-Surprize? PGN]
Please report problems with the web pages to the maintainer