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…
Homemade machines costing about $50 are being used to read credit-card mag-stripes, without having to steal the cards. The information is then e-mailed abroad, where cloned cards are fabricated. This has become a billion-dollar-a-year enterprise. [PGN-ed from Monty Solomon's e-mail to Dave's IP, subtitled Terrorists, mobsters in on hacking racket, by William Sherman, *NY Daily News* http://www.nydailynews.com/today/News_and_Views/City_Beat/a-137421.asp] [The gadget was first demonstrated in maybe 1960s at Caltech as part of a demo on how poor the mag-striped credit cards were. In spite of that, they won. Dave]
Here's a link to an article on MSNBC that I found interesting -- http://www.msnbc.com/news/598102.asp?0dm=C216T&cp1=1 Many retailers are replacing paper gift certificates with small plastic cards containing magnetic stripes, similar to credit cards. Ideally, the purchase of a gift card would result in a database being updated to reflect the balance associated with the card's unique account number. Some retailers are using sequential account numbers and have no provisions to protect against a thief using a mag-stripe reader/writer to re-program a stolen card or small denomination card so that it matches the account number of a larger valued card purchased by someone else. Many retailers even provide a convenient 1-800 number so that the thief, knowing many valid account numbers, can "shop" for a card of significantly greater value. The RISK: A form of fraud, difficult to trace, involving a minimal investment in equipment by the thief. Also note that the thief only requires the ability to query the back-end database (through the toll-free number), not the ability to manipulate the records. Perhaps more ominously, the risk is angry family members who find a zero balance on their gift cards! Solutions: One retailer, mentioned in the article, uses optical bar-coding which can't be re-encoded without defacing the card. Another follows a technique used by many credit card companies — extra check digits are included in the mag-stripe that are not visible on the face of the card. It seems astounding that this isn't being done by all.
I hope you won't mind another Euro-related story, but this one is rather charming. The facts are taken from my local newspaper, the *Luton on Sunday*, but the story made a brief appearance in some national papers. Although the UK is one of the three European Union countries not to have adopted the Euro, many large retailers in the UK announced that they would accept them, but would give change in pounds sterling. Among these was the Debenhams chain of department stores. (Incidentally, I'm told that officially the plural of Euro is Euro, presumably to prevent language wars.) Robert Sheilds, a 15-years old Luton schoolboy, decided he would like experience of using Euro, so he changed 10 pounds to Euro at a bank, and went on to his local branch of Debenhams to spend them. He found that they had programmed their tills as if there were 1.6 pounds to the Euro rather than 1.6 Euro to the pound, but none of the sales assistants was experienced enough to notice the error. So after his initial purchase, he still had more than 10 pounds in change. He tried to tell the store staff of their mistake, but they said the rate was programmed into the computer, and nobody had the authority to change it. So he carried on spending, and after two hours, ended up with 130 pounds of goods, and 20 pounds in cash. At this point the store manager asked him to leave, saying "I think you've had your fun". Richard then took a train to Bedford (about 20 miles away) to try his luck at another branch, but by this time staff had been alerted, and refused all Euro transactions.
Here is one more example of the unexpected implications a large project (such as the introduction of a new currency) can have. It is not a murderous risk, but you may find the story instructive, and perhaps amusing. Today, I received an assessment from the local tax office. The amount due was the former amount converted from DM to EUR — almost, but not exactly: it was rounded up to the nearest multiple of 0,1 EUR. Thus, the new annual amount was no more a multiple of 4. As the amount is due by quarterly installments, the assessment told my to pay three equal amounts (at certain dates every year) and another amount, which is 0.02 EUR larger, at some other date. Of course, my bank had already converted my standing remittance order from DM to EUR. However, this being not adequate, I tried to adapt it to the new tax assessment. (I dare not risk the trouble of owing anything to the tax office, not even 0,02 EUR, would you?) It turned out that the bank is not prepared to handle a standing order of this type. I could have four annual orders instead, one per quarter. I preferred to do it the other way: I left my original order as it was, and placed a new order for 0,02 EUR (roughly 0,02 US$) per year. I hope well that somebody at the tax office will be irritated with this extra paying. The lesson to be learned: any change in a large, working system will have unexpected, possibly undesired, results. Be on your guard!
I received an e-mail this morning with an unknown .exe attachment which on
inspection seemed to do something with registry keys. Since it doesn't look
like any of the viruses I heard about recently I tried to look for it on
<http://www.mcafee.com/>.
Therefor, I visited <http://www.mcafee.com/> first using Netscape 4.72 for
Solaris (I use a Solaris workstation). The site shows a pop-up asking me to
enable an ActiveX plug-in, but I might be able to use the site without
it. The fact that I am using a different operating system for which an
ActiveX plug-in isn't available at all has never crossed the mind of whoever
designed that.
To top that, when I visit the site using Lynx 2.8.2 (a text-mode browser for
Unix, quite popular with blind or near-blind Internet users) I just get a
page asking me to enable scripting by LOWERING the 'Internet security'
setting on my Web browser. Never mind the fact that there are browsers for
which there is no scripting and that it can be a decision made for security
reasons. Literal text:
3. In the Internet Control Panel, Select the Security tab
4. Select the "Internet" zone
5. If the security level is set to "High"
a. Change the setting to "Medium" or click the "Reset" button
for the Internet Zone
If McAfee wants to look like a company that sells products for 'Securing
your PC' they might want to set up their Web site so I don't have to LOWER
the security of my browser.
The security history of Javascript and ActiveX do not suggest to me that
they are welcome on a 'Securing your PC' site.
[Genuine virus investigators interested in the mail with 'ASD.EXE'
attachment should contact me privately]
Koos van den Hout koos@kzdoos.xs4all.nl http://idefix.net/~koos/
In RISKS-21.84, Jeffrey Mogul ("When a 'secure site' isn't") points to some
"secure" sites which fail to properly implement https secure protocols.
In an incident from two years ago, my employer required use of an online
form which required credit-card info for cards which were billed to
employees. This "secure site" was provided by an external supplier.
Naturally I checked for https use and browser "lock" icons.
All went well until the final confirmation screen. In addition to the
"you have ordered zzzzz with credit card yyyyyy" expected, imagine my
surprise when I noticed that the URL of the page contained ALL of my
information:
"https://securesite.com/verification.htm?name=3Dyyyyyy,CardNumber=3D12345=
6789,ExpirationDate=3D12/31/2001" etc.
Being part of the URL "address", this information (including my name,
address, credit card number, and expiration date) was not protected,
even though the page was sent using "https".
A discreet call to the webmaster for this site provided a quick reply --
that all was okay, and all pages were sent using "https".
A second call (and a CC to a very-high-ranking IT manager) explaining
the difference between "PUT" and "GET" in forms processing produced a
fix — and an apology.
Moral: Even when the technology is secure, people can still blunder
around it. The analogy which was effective in this case was talking to
their IT engineers about the US postal system — and pointing out that
writing information on the outside of an envelope isn't secure even if
the envelope itself is protected.
I'll doubtlessly draw a lot of flack in my inbound e-mail for this comment yet what the hell: Harvard sent a lot of e-mail out to people who submitted entrance requests with an AOL return e-mail address and then AOL filtered them out as bulk spam. As much as many people hate to admit it — whether it's deserved or not — AOL users have a reputation in newsgroups approximately one step above that of WebTV users. "Get a real ISP and people will talk to you" is something I see in newsgroups from time to time. I doubt that Harvard's admissions department looks at an AOL address and decides the applicant should be rejected based solely upon that fact but what about prospective employees? People in IT departments might wonder whether someone's using AOL because they're not Internet savy enough to figure out how to install, set up, configure and use a real ISP with real client software packages. AOL is marketed toward the average smuck with a plug-it- in-and-it-will-just-work requirement. It doesn't take a genius to figure out how to use a real ISP with real servers and slients but AOL _is_ targeted to people who don't want to read "Internet For Dummies."
The Web surfing habits of people who used the LimeWire, Grokster and KaZaA music-sharing programs were surreptitiously tracked because those programs were linked to an online sweepstakes game called ClickTillUWin, in which players pick numbers and win cash prizes. The company that operates the sweepstakes game says it told outside distributors to get users' permission before installing the software, but in these cases that action was not taken. The three companies have posted new versions of their software without the tracking component, and LimeWire has issued an apology. (AP/*USA Today*, 4 Jan 2002; NewsScan Daily, 7 January 2002) http://www.usatoday.com/life/cyber/tech/2002/01/04/limewire-tracking.htm
Here's yet another example of how an organization fails to abide by it's own security policies: 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 can be seen at: "http://www.kponline.org/ns/signon/signonmember?view=Security" <http://www.kponline.org/ns/signon/signonmember?view=Security> . This statement indicates in the first paragraph that the medical record number will be sent via SSL: Signing On You need to sign on using your Kaiser Medical Number. This number will be transmitted using secure technology (SSL). We need your Kaiser Medical Number before you get into the site for two main reasons: (Note that this is the statement still in effect as of 1 Jan 2002.) However no SSL connection is possible. Every attempt to obtain a secure connection gets redirected to the non-secure page. The people in Kaiser's kponline service center seem to have no clue and no concern about this lapse. They say to disregard the security statement because it applies only to those already signed up for access which is not indicated in the security statement and cannot understand what the problem is. Pointing out that that is not what is stated just annoys them. The service reps say that no one can use the medical record number to access personal information online. Seems like that's all they are concerned with. They also claim that there is no way a medical record number can be associated with a patient. I am fairly certain that these claims are easily proven false. The RISKS are quite obvious but Kaiser seems oblivious to the obvious even when pointed out in detail.
Yet another example of how an organization ignores its own published privacy policy: ATT allows customers to send form mail using SSL on their Web site. This is to keep their customer's info and the message private. But their people include the entire message in plaintext e-mail messages sent in response defeating the purpose of the secure form. Their privacy policy as published online essentially says that they will keep customer info private. RISKS? What RISKS? TO customers? So? What's the problem???
Well, it took five months of letters and contacting the local news media and several regulatory agencies, but I finally got Peoples to explain why their interest calculations for June 2001 differed from mine. So this message is the retraction I promised I would submit if Peoples proved to me that their interest calculations were correct. (This, of course, does not change the fact that they stonewalled me for five months and caused me all sorts of other grief when they "upgraded" their computer systems in June.) The technical explanation, for those of you who are interested.... In their old computer system, they calculated interest for the month on the second-to-last day of the month, using the ending balance for that day as the ending balance for the last day of the month as well. If in fact the ending balance changed on the last day of the month, a credit or debit was applied to the interest payment for the *next* month. My calculations of what my interest payment should have been did not include this credit, and indeed *could* not include this credit because the bank never explained this part of their algorithm to me (despite my multiple requests for a precise explanation of how they were calculating interest). On the bright side, their new computer system pays interest at the beginning of the month for the entire previous month, so this particular bit of brain-damage is gone. But I won't be staying with this bank for long enough to enjoy that particular "perk" — would you stay with a bank whose officers either were incapable of explaining to you how they calculate interest, or simply refused to take the time to do so, until you pressured them about it for five months? See <URL:http://www.mit.edu/~jik/pfsb_problem/> for the whole story, including this latest installment. Jonathan Kamens
The primary problem here is not the C language, but the associated standard library, because the library is responsible for a lot of the C/C++ programming culture. Almost every book on C programming had lots of examples using sprintf(), strcpy() and other buffer overflow prone functions. And programmers took these examples to heart, duplicating them in the programming interfaces they wrote. If the topic of buffer overflows came up, then strncpy() would probably be mentioned. What a fine example this was for the beginning programmer: it wouldn't overwrite the destination buffer if called correctly, but the copy of the original string in the buffer had an unbounded length! (since the copy would not be properly NUL terminated if the source string was as long or longer than the buffer size). Its a great pity the first C standards didn't provide two variants of the standard library and a standard means of selecting which variant would be used. Safe versions of the problematic functions would be include in both variants, and the recommended variant library would have omitted the unsafe functions completely (for completely new code). Stephen C. Steel <stephen.steel@kvs.com>
PL/I also supports string subscript range checking, in addition to Array Bounds checking, but in working with PL/I since 1973 I've never seen a site that had them as the site default. The site I currently work with runs at 100% processing capacity from 07:00 to 23:00 every day. OTOH, they feel that DB2 is the way to go even though IMS still beats DB2 by at least 2:1, so perhaps it would be worth giving this a try as the site At the moment I can't recall whether a protection exception or a data exception is the most common symptom, but I've got it down to the point where I can quote the PL/I manual section advice about adding a Subscript and Array bound Check prefix in my sleep for "unidentified routine malfunction" types of errors when on call programmers give up and ask for DB Admin advice. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea1110/2.4.1.7?ACTION=MATCHES&REQUEST=subscriptrange&TYPE=FUZZY&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT It rarely shows up in that overt form. I'm more concerned about it happening quietly without ringing alarm bells. BTW, in the only major program where I ever had to worry about array overflow(why not use a DB instead) I made the array CONTROLLED with a REFER clause and checked the array size explicitly, allocating a new larger array and printing and warning message if I reached the array size limit. It is always interesting to compare the confidence with which programmers state that they don't feel they have an Array bound problem with their quite manner when they get back to me with confirmation that adding the stringrange and subscriptrange checks zeroed in on the problem.
As a long-time practitioner of software testing, let me mention that, while buffer overflows are commonly exploited for security breaches, plenty of software quality problems--some of which are quite risky to the users--arise from other causes. Just off the top of my head, I can spout off the following unforgivable "buggy software" stories, none of which have anything to do with buffer overflows as far as I can tell: * An expense reporting program, QuickXPense, that didn't have any data quality bugs at all...at least until the operating system crashed. (Gee, what are the odds of that?) Once the OS did crash, the file was randomly corrupted, and the corruption cascaded with subsequent use, so ultimately the entire expense report file was garbage. The vendor's technical support staff was aware of the problem, but rather than a patch or a file report utility, they suggested that I "e-mail your file and we'll fix it." Well, sure, there's nothing private or personal in that file. * The fact that some PowerPoint presentation files, if corrupted--by, say, the computer going into power-saving hibernation at just the wrong time--in as much as a single bit in some cases, can become totally unreadable by the program. (See the first and last bullet for ways this might happen.) Microsoft knows about this bug, but they choose not to include recovery utilities in their applications. Instead, after a $100 paid support call, they send you to a software developer--who would be called a "highwayman" a couple centuries ago--who charges $400 for his recovery tool. Talk about turning the incompetence of others into a business opportunity! * The Windows NT network driver that came with a 3Com network card which, on two out of three boots, is unable to see the network. No diagnostic messages come up. Cold booting the system until communications are re-established is the only cure. * The automatic update software in my Toshiba laptop that recently "upgraded" the drivers for the built-in Xircom MPCI modem--without prompting me--which resulted in the loss of all modem definitions in my Windows "Device Manager". (Device mismanager?) I wasted an entire day trying to get the drivers reloaded. Toshiba's technical support was worse than clueless, having me try the same thing over and over until the batteries on my cell phone died, ending the call. Ultimately I had to go out and buy a new modem, which also turned out to solve a bunch of connection problems I had, indicating that the buggy setup problem was only the tip of the iceberg, quality-wise, with this modem. * The Lexmark printer I bought that didn't say anything in the manuals or installation process about the fact that you couldn't install it on a networked PC and access it from other systems on the network. After a few hours of trying, I e-mailed tech support, only to get response that boiled down to, "Oh, yeah, you can't do that." Oh, really? Why can't I do that? I have a twelve-year-old Epson dot matrix printer that was built before anyone had a small office network. I can share that printer just fine with every computer on my network. This whiz-bang color printer-scanner-copier that I bought in the day of ubiquitous small office/home office/home computer networking can't be shared with other computers? Pshaw! * The daily (or more often) crash that my Windows Me laptop computer subjects me to, generally without warning, usually losing a good fifteen minutes worth of work. I guess I should learn to save every thirty seconds? If experienced people like me have problems like this, imagine the average computer user who has no idea whatsoever about what is going on when her system screws up. And why should they have to understand a computer to use them? (Don Norman, in his book *The Invisible Computer*, discusses this situation at length.) Ultimately, a computer is a tool, nothing more, nothing less. I think we have a long way to go before we can claim levels of quality consistent with what the makers of almost any other tool could claim. Rex Black, Principal, Rex Black Consulting Services, Inc., 31520 Beck Road Bulverde, TX 78163 USA +1 (830) 438-4830 www.rexblackconsulting.com
[This feels like my days reading comp.programming (Been "clean and sober" off Usenet for over a year now :-) MEA ] ... As someone who, until very recently, wrote primarily code that was executed from ROM, I need to point out that "corrupting running code" is not needed. If one can corrupt the subroutine return-address (normally _part_ of a buffer-overflow attack), one can point it wherever one wishes. If a sufficiently dangerous set of instructions (or bytes that could be interpreted as instructions) already exists in the "instruction memory", one can do the intended mischief. As for Henry's assertion that such devices are "more vulnerable" because "nobody bothers to run virus-checking software on them", I think this exhibits touching faith in anti-virus authors and a mis-understanding of the most common recent viruses. Outlook could be in ROM and "Execute Only" (No-Read) and I still would have gotten a mailbox full of mail whose subject I won't include so this copy of RISKS will get through :-) Buffer-overflows are indeed examples of shoddy programming practices, but they are hardly the most popular vulnerability. People who leave their doors open need not fret overly about the quality of their locks.
Please report problems with the web pages to the maintainer