[This is a nifty piece of work, and presents one more argument for open-source software -- although I suppose proprietary software purveyors might prefer to apply it themselves to closed-source systems! But it is noteworthy that this analytic tool is itself open source. PGN] I've put together a command-line tool for statically scanning C and C++ source code for security vulnerabilities. The tool is called ITS4. ITS4 scans through source code for potentially dangerous function calls that are stored in a database. Anything that is in the database gets flagged. ITS4 tries to automate a lot of the grepping usually done by hand when performing security audits. The tool is available from: http://www.rstcorp.com/its4/ Also on this site is a research paper on ITS4 submitted to this year's Usenix Security conference. ITS4 is open source software. The license puts some minor restrictions on commercial use. In essence, you can't use this tool to make money (such as by reselling it, or by using it in a consulting practice). However, you are encouraged to run the tool on your own product in order to make it better. ITS4 does more than just grep-type work. It allows for arbitrary handlers to refine the initial analysis. This version of ITS4 comes with some simple handlers. Some of these handlers check for uses of common string operations that often are not significant problems. For example: strcpy(buf, "\n"); sprintf(buf, "%d", i); In the first case, ITS4 will look at the second argument to a strcpy. If it is a string constant, the severity of the problem site is reduced to the lowest possible level. The tool will not output this kind of problem in its standard mode. In the second case, a similar reduction in severity occurs, since the sprintf format string contains no %s's. The tool also has handlers that scan for file access race conditions, similar to the prototype tool discussed in [BD96]. We slightly improve on their tool by allowing for interprocedural and intermodular problems. There are some technical limitations to this tool, many of which we hope to improve in the future. We'd like to have the help of the security community. I'm personally dedicated to improving this tool, and Reliable Software Technologies is willing to put some resources towards doing so. Changes from the community will certainly be considered for inclusion in future ITS4 releases. Currently, the weakest area of ITS4, where the input of the security community is most important, is the vulnerability database, which was largely taken from some very preliminary work done by Tom O'Connor. It's perhaps a good start, but far from complete. Many new things could be added, and the entries that do exist can likely be improved substantially. For each database entry, we have a description, a default severity, and a recommended alternative. Generally, the descriptions are pretty scant, and the severities are not overly well thought out. The next area for improvement is the handlers. It would be great to see people writing some good handlers, or even suggesting good handlers, and then we could write them. Beyond that we're interested in the following: 1) Flagging the allocation mechanism used on important variables (i.e., stack-allocated buffers are usually easier to exploit than heap-allocated buffers if there is an overflow). 2) Performing much better static analysis. We'd probably like to start by building some sort of heuristic alias analysis, and then doing something similar to the analysis done in [WF+00]. We do have plans to ultimately do these things, but if other people want to code them up and contribute to the project, that's great. I've set up a mailing list for people who are interested in helping out in any capacity. Hopefully we can get a good discussion going that will improve the vulnerability database, and make ITS4 a far more useful tool. The mailing list signup is available at: http://www.list.org/mailman/listinfo/its4. John Viega, Software Security Group Co-founder Reliable Software Technologies email@example.com References: [BD96] M. Bishop and M. Dilger. Checking for race conditions in file accesses. Computing Systems, 9(2):131-152, Spring 1996. [WF+00] D. Wagner, J. Foster, E. Brewer, and A. Aiken. A first step towards automated detection of buffer overrun vulnerabilities. In Proceedings of the Year 2000 Network and Distributed System Security Symposium (NDSS), pages 3-17, San Diego, CA, 2000.
A fake press release announced a merger of Aastrom Biosciences Inc. with Geron Inc., a California biopharmaceutical house. Aastrom stock fell, while Geron rose. Aastrom asserted that the message on their Website was totally bogus, and presumably the result of a penetration. [Source: United Press International - 17 Feb 2000; PGN-ed]
According to a 17 Feb 2000 AP item (18 Feb 2000 article in *The Washington Post* by David Ignatius, the US State Department has its shorts in a knot because they have just realized that a software package called the Mission Performance Plan that is running on embassy computers around the world was written by programmers from the former Soviet Union. On 2 Feb 2000, the Department of State sent an urgent cable to 170 embassies ordering them to remove the package by the 7th while security specialists examine the code for trap doors, logic bombs and other cybernasties. [Comment by MK: this incident reinforces the view that the trustability of software writers is even more important than quality assurance where security is concerned. As many commentators have noted, it may be impossible in practice to apply adequate quality assurance to untrusted code. I have frequently urged QA specialists to ensure that they use code-coverage logging to ensure that every line of code is actually executed during the SQA process; however, even total coverage does not necessarily mean that a program is guaranteed safe, since variable sequence of execution could result in different outcomes for the same subroutines because of data dependencies.] M. E. Kabay, PhD, CISSP / Security Leader, INFOSEC Group / Adario, Inc.
http://www.wired.com/news/politics/0,1283,34362,00.html The Crash of a Dot.Gov, by Declan McCullagh (firstname.lastname@example.org) Wired, 15 Feb 2000 As government aides were frantically preparing for the president's last-minute Internet-reliability summit with technology leaders, thousands of visitors couldn't reach the U.S. Senate's own Web site. It was offline for over nine hours Monday, from early afternoon to after 11 p.m. (EST) due to technical problems, Senate officials said. The embarrassing site failure comes just as the U.S. government is telling private firms how important it is that they increase the reliability and security of their own networks. "Our administration has been working for years now to reduce vulnerabilities in government computers and to encourage the private sector to do more," President Clinton said before Tuesday's one-hour meeting with corporate information officers, academics, and Cabinet members. From Declan's POLITECH, a moderated mailing list of politics and technology. To subscribe: send a message to email@example.com with this text: subscribe politech More information is at http://www.well.com/~declan/politech/
The full article resides at http://search.tulsaworld.com/archivesearch/default.asp ?WCI=DisplayStory&ID=000219_Ne_a10court <A HREF="http://search.tulsaworld.com/archivesearch/default.asp?WCI=DisplayStory&ID=000219_Ne_a10court"></A> A new state-run computer system for the Tulsa County Court Clerk's Office that was supposed to be the envy of the rest of the country is still malfunctioning, sometimes for days on end. The new system was put in place just a few days before the end of 1999 in an effort to make the court records system Y2K compliant. Still, (Sally) Howe Smith said, the old days under the clunky mainframe are starting to look pretty good. The new system has been down completely for at least a day twice in the last two weeks and regularly has system errors that hinder access to records for hours at a time, she said. The court records system uses Windows 2000, and the new software was deployed early for the state system. (Website coordinator Gregg) Lambert said state technicians were hoping to confer with Microsoft officials about some of the system's problems. Michael S. Keller, Technical Solutions Consultant, Sprint Enterprise Network Services, Amateur Radio N5RDV
Microsoft (hereinafter MS) Windows 2000 has a kind of "immune system" feature which causes it to reject any driver or DLL update which has not been digitally signed by Microsoft. The signature system looks to be similar to Authenticode. In RISKS-18.89, I suggested that the real utility of MS' Authenticode was to assist MS marketing. I offered a test for my hypothesis: that an offer by MS to sign others' code (for a fee) would validate my theory. Well, if you want to supply a new device driver (say, for a variant peripheral) or library update (adding, say, some spiffy cryptographic features) for Windows 2000, you must give your code to MS for early review and pay MS a fee. If you do these things, MS may sign your software. If you do not, then no Windows 2000 machine will run your code (or at least, not without big trouble, too big for non-techies). As with Authenticode, MS' scheme is not unbreakable, nor does it even attempt to assure the quality (as opposed to the provenance) of signed code. (Oh, MS says their lab will review 3rd-party code for "compatibility," but they won't check for malware, and unlike, say, Java's sandbox, MS signature scheme has no inherent malware-inhibiting qualities). MS marketing will stop at nothing, Q.E.D.. Mark Seecof
> ...pronounce "DoS" to rhyme with "sauce" -- and sound just like "DOS". For those of us that don't speak American that sentence makes no sense at all. The pronunciation of "DOS" comes nowhere near that of "sauce". In English, they rhyme more with "moss" and "morse" (with a silent `r') respectively. Risky assumptions about your readership? [Webster of course gives a British spin on "doss" -- 1. doss \'da:s\ vi [origin unknown] chiefly Brit : to sleep or bed down in any convenient place 2. doss n chiefly Brit : a crude or makeshift bed Dictionaries and linguistic differences make strange bedfellows. I presume the OED doss even better. But phonetically auf deutsch, we have "Dos ist gut, net?" (where "net" is regional dialect for "nicht"). PGN]
You say "tomato"? > I heard more than one reader pronounce "DoS" to rhyme with "sauce" [...] It took a few seconds for me make any sense at all of his comment: when did "DOS" ever rhyme with "sauce"?! And then I realised that Ken is probably an American-English speaker and that he had missed another risk: that all readers of english will pronounce words the same way. Let's call the whole thing off. Paul Oldham, Milton, Cambridge, England http://the-hug.org/paul/
It could easily be argued that DOS is a DoS against the Intel processor family.
This reminds me of a counter example. Three or four years ago the following joke made the rounds. "What do you get if you cross Lee Iacocca with a vampire? AUTOEXEC.BAT" I was astounded at how many people got it. Even technophobes and Mac owners understood it and laughed. Maybe Murray Hill NJ would be the only place on earth that it would flop. :) My point is that these things are less jargon-like than we might think. They are at least slang and perhaps mainstream American English by now.
The attorney general of Michigan has filed a "notice of intended action" against DoubleClick, charging the Web advertising firm with "failing to disclose to Internet users that DoubleClick is systematically implanting electronic 'cookies,' or electronic surveillance files, on hard drives of users' computers without their knowledge or consent." In addition, the notice criticizes DoubleClick's recent attempts to combine its tracking data with personal data such as names obtained through its acquisition of Abacus Direct last year. Michigan's filing, which is preliminary to a lawsuit, is the third action taken against DoubleClick this week -- the Federal Trade Commission and the New York attorney general earlier launched separate inquiries into the company's business practices. [*Financial Times*, 18 Feb 2000, http://www.ft.com/; NewsScan Daily, 18 Feb 2000]
I find Jim Alchin's rebuttal in RISKS-20.80 dispelling the rumour of 63,000 defects in Windows 2000 hilarious. This statement got me laughing out loud, "We also have a special advanced source code analyzer that we use. This tool generates a significant number of false positives (it thinks the code should be changed, but in fact it should not be)." This "advanced" analyzer generates "significant" false positives. I guess it must be as advanced as Windows 2000. So how many defects are logged against the analyzer, Jim? Mr. Alchin goes on to state, "We love this tool." And we all love Windows, Jim. Truly we do. ...Tom
> The bug is with pine -- it returns multipart/alternative and > should have returned multipart/mixed. [...] This is the sort of "force the user to adapt to the software instead of vice-versa" attitude that seems to permeate PC software. I find it incredibly frustrating that I'm constantly fighting software because someone assumes their way is the ONLY way something should be done. Just because the client is HTML-aware doesn't mean it should hide the alternatives from you. My personal choice for e-mail (not what I'm forced to use at work) tells me there are alternate views available and lets me choose which one I would like to view. Sometimes I get e-mail which is all HTML. Having an HTML-aware client is handy in these cases. However, I don't like HTML, I don't want HTML, and given a choice I will view as non-HTML. A product which forces HTML on me is broken, IMHO. I agree that in this case there is a problem with Pine. However, while Outlook may be working as designed I would certainly argue that it is not working as it should!
The situation: Because of high-speed processing of bank checks without any human intervention, banks (at least in California) will no longer honor requests by depositors that checks have two signatures. Even when a check has imprinted on it "Two Signatures Required", banks will honor that check with only one signature. When establishing a new account or when changing signature authorizations on existing accounts, banks are requiring depositors to sign a waiver that releases the bank from any liability for paying a check with only one signature. As long as the signature is in the bank's files, the loss will then fall on the depositor even if the signature card in the files or the check clearly indicates "Two Signatures Required". The risk: This can be a problem for non-profit organizations, many of which depend on amateur help -- unpaid volunteers -- to handle administrative tasks, including disbursing funds. The California Attorney General -- who regulates charities through the state's Registry of Charitable Trusts -- recognizes the risk of embezzlement or other losses and strongly urges all non-profits to require two signatures on all checks. The use of a single authorized signature on a check has already proven insufficient. Losses to PTAs, high school booster clubs, and other volunteer-run non-profits are far too common. Of course, businesses and other organizations are also at risk of loss without the safeguard of requiring two individuals to approve payments of funds. For that reason, a company's independent auditors will often require the use of two signatures if they are to certify the adequacy of the company's internal fiscal controls. Some questions: Automated pattern-recognition capabilities might not be sufficient to verify check signatures. However, the technology has surely advanced to the point where at least the presence of two signatures could be verified. It certainly can detect a preprinted "Two Signatures Required" on a check. Why have the banks not incorporated this technology into their check-clearing systems? The banks claim they cannot stop the automated processing of checks and examine each check to ensure that it has the correct number of signatures. That is why they do not want to be held liable when a check marked "Two Signatures Required" is honored with only one signature. However, they also cannot stop the automated processing of checks and examine each check to ensure that it has a valid, authorized signature. Yet they remain liable if a check with an invalid signature is paid. What is the difference? David E. Ross <http://www.vcnet.com/~rossde/>.
Amazon.de has a very simple scheme for changing your account's password in case you forget it: Just tell their server your e-mail address, the title or ISBN number of a book you have ordered with them, and the last five digits of a bank account or credit card number you have used to pay. The server will happily permit you to change your password. The RISK? The information to be supplied may be easily guessed. Bank account numbers are readily accessible to - almost - the public; it's even common to put them onto letterheads. As opposed to credit card numbers, they aren't treated as secrets. Guessing what books have been ordered can frequently be easy, too - people tell about books, people write reviews, or you just know peoples' interests. Trying best-sellers will work nicely as a large-scale attack. The one and only element of control you have is a confirmation message sent to your e-mail address. While this may work if you are reading your e-mail regularly, a prolonged week-end vacation may be sufficient for an attacker to order a book, get it paid with your credit card (or from your bank account), and get it delivered to some empty building.
>However, there is a more serious vulnerability here: infinite loops between >two or more closed lists. [Kabay] Bounces should honor the Received: line count and add an extra one. Not only does this prevent infinite loops, but it also makes spam more trackable. I'd think many already do something to prevent infinite looping; otherwise what happens if a from address is invalid? Bounce bounce bounce... until some sysadmin stops the flood?
I have to fly to California for training. As my wife has never been to CA, I did book her ticket on American Airlines (My company has an agreement with them). When I called after a couple of days to ask why I did not get a confirmation in the mail, I was informed that my credit-card processing was not complete as they had incorrect information about my ZIP code. I did ask as to why I was not informed and they said they di try to do so - by sending me a post card!!! YES, that's right - to inform me that they had an incorrect address on file they "mail" a post card. I did speak to a supervisor who informed that "this is the official policy". I did ask him how this could be implemented and how it would work - "this is official policy". The only way to inform Customer Relations is to call or send mail via the USPS. They do not have an e-mail address. American Airlines Customer Relations MD 2400 P.O. Box 619612 DFW TX 75261 (817)967-2000 Rumy Driver, Sybase Technical Support [By all means, write them and complain! PGN]
In connection with an item posted recently in RISKS on using automated rejection messages as a spam relay, I received the following correction from a list manager who asked to remain anonymous: > Therefore I recommend that at the very least, administrators > for closed e-mail lists prevent their listserv from sending ... LISTSERV is a registered trademark of L-Soft International. See: http://www.l-soft.com/ Unfortunately, like "Kleenex" and "Rollerblades", "LISTSERV" has come to be commonly used to refer to any mailing list management package (or worse, the mailing list itself). Please pardon this one-man campaign to try and stop this practice. :-) I responded that I would henceforth use the phrase "list-server software." M. E. Kabay, PhD, CISSP / Security Leader INFOSEC Group / Adario, Inc. [RISKS has being doing so for a long time. PGN]
>... Simson recounts that people are able to get their credit records or >medical records from MIB, but then doesn't provide any information on how to >get them or who to contact; ... That's because anyone who is contacted by MIB gets a little light flashed in their eyes and forgets all about it. Dave Weingart, Randstad North America firstname.lastname@example.org 1-516-682-1470
Please report problems with the web pages to the maintainer