2006 Underhanded C Contest

long unsigned int maxwordsize(char *inputFromStdIn)
{
long unsigned int tmpwordsize=0,maxword=1,i;
for (i=0; i <= strlen(inputFromStdIn); ++i,++tmpwordsize)
{
[etc etc]

So sayeth the winner of the "2006 Underhanded C Contest." (Underhandedly, they've titled the page, "2005 Underhanded C Contest:" I bet they're checking to see who's paying attention.)


I'm a huge fan of the Underhanded C Contest. When I was with Reflective, we spent a lot of time talking with executives concerned about trojans in their code. Now, detecting trojans in the code is a lot harder than detecting buffer overflows, and, I think, there are a lot more of the latter.

I'm glad to have samples of underhanded C code, because they allow us to study the problem, and the problem looks awfully hard.

Extra! Extra! Read Nothing About It! (Latest on Apple V. Maynor)

In “SecureWorks Backs Out of Macbook Demo,” Brian Krebs writes:

David Maynor, the SecureWorks researcher who was set to demonstrate how wireless driver flaws could be used to compromise an Apple Mac laptop, suddenly has been yanked from the ranks of Toorcon presenters.

At around 12:50 p.m. PT, SecureWorks issued the following press release:

“SecureWorks and Apple are working together in conjunction with the CERT Coordination Center on any reported security issues. We will not make any additional public statements regarding work underway until both companies agree, along with CERT/CC, that it is appropriate.”

TRUSTing Mary Ann Davidson

Yesterday, Mary Ann Davidson had a fascinating post about the classics of Western literature. As usual for Mary Ann, the apparent basis of the post is really just exposition for her main point. In this case, the thrust of her post is the need for developers to have more training in secure coding at the university level. Mary Ann and several others have started working with several universities (including UC Berkeley, Stanford and CMU) and corporations (including GE, Sun and Visa) to produce such a curriculum. They are calling this program “The Team for Research in Ubiquitous Secure Technology” or TRUST and have bunch of resources and information online.
[Edit: Gunnar Peterson over at 1 Raindrop points out that: Ken Van Wyk and John Steven have an article “Essential Factors for Successful Software Security Awareness Training” in the current issue of IEEE Security and Privacy, that is also relevant to the general issue.]

Computers Will Make Our Lives More Private

secure-tapes.jpg

Social Security Administration officials believe computerization of files has contributed to their security. In the manual era, the applicant’s record was an individual ledger sheet. Thus if a person could get to the file drawer and then the ledger, he could check any record. Although entry to the files area was restricted by guards who checked workers’ identification, it was impossible for the guards to keep track of everyone. Under SSA’s computerized system, however, the individual has to secure the tape from locked storage. Then, because SSA runs a batch processing operation, the entire tape must be run to gain access to any single record.

From “Databanks in a Free Society,” Alan Westin and Michael Baker 1972, Quadrangle/New York Times Book Company. Thanks to Andre Frech for the quote.

Photo: An IBM 360 operations room, from Cray-Cyber.org.

Words to live by

No free man shall be seized or imprisoned, or stripped of his rights or possessions, or outlawed or exiled, or deprived of his standing in any other way, nor will we proceed with force against him, or send others to do so, except by the lawful judgement of his equals or by the law of the land.

Magna Carta, Article 39
An opposing view was today expressed by the United States Senate.

Breach Datasource Design Criteria

 Most readers of these words are probably familiar with at least one of the lists of data breaches commonly referenced in the media and in specialized blogs.  Among these are Attrition.org’s Dataloss, and Privacyrights.org’s Breach Chronology.  The ID Theft Center also maintains a list (available, it seems, only as a PDF), and various academic researchers have also compiled breach datasets.  Clearly, there is interest in having a handy source of current information about such incidents.  This post is my take on what such a source should contain, and what sorts of activities it should allow.  I want to state right away, and emphatically, that these remarks are not a criticism of any existing list or database.  Indeed, those resources are the shoulders of giants on which I think we all can stand.  Seriously.

 First, the datasource should not be a simple list, oriented toward on-screen viewing or printing in its entirety.  It should be a database.  I am not speaking of its physical representation or storage format, but the kinds of uses it should be amenable to.  I’m saying that it should contain a rigidly-enforced set of data elements, and allow random access to records based on criteria pertaining to those elements.  That can be done with flat files, with a full-blown relational database, with a spreadsheet, or any number of other things.

Second, this datasource should have a web interface.  This interface should make easy the types of arbitrary queries referred to in the preceding paragraph.  For example, it should be possible for a user to obtain a listing of all breaches with a specified date range, or within a certain industry. The result sets obtained through these arbitrary queries should be made available for download in as universal a format as possible, for example as a CSV file, and should also be viewable on-line if their size permits.

Third, the datasource should contain a wider range of data pertaining to each breach than is currently available.  Today’s datasources typically contain variables such as these:

  • Date breach became known
  • Affected Company
  • Industry of Company
  • Number of records disclosed
  • Type(s) of information revealed
  • Names of third parties involved in the breach
  • Reference to a media account of the incident
  • General Comment

These, I would say, are “the basics” and are fine for many purposes.  However, deeper understanding requires more information.  Specifically, as my fourth point, I would like to see:

  • Full address information for the Affected Company
  • Company stock symbol and exchange (where relevant)
  • Indicator of company size, such as number of employees or gross revenue
  • Dates for the discovery of the breach, the occurence of the breach, and the reporting of the breach to “victims”, law enforcement, and regulators.
  • The proximate cause of the breach
  • Whether notice to victims took place
  • Whether this notice was required by law
  • The minimum and maximum number of affected individuals, where a precise count is not known.

 All of these variables are easily represented in text form, although some discipline is needed in coding the breach cause — there are many ways of saying “web server config error”, after all.  Similarly, maintainers of this ideal datasource should publish their coding guidelines, so that users of the datasource understand just how a “web server config error” is determined to be a breach cause, rather than (say) “improper firewall ruleset”. 

Fifth, the datasource should  be easy to extend and link to other sources of information about an incident.  The DLDOS datasource has begun using a unique identifier for each of its records, which allows others (of whom I am one) to link related information.  Since, unfortunately, much of the work in amassing the data on breaches has been a part-time thing conducted by amateurs, it may be important to allow others to “connect” and reconcile different ways the same event has been recorded.  

Sixth, and related to the preceding, the datasource should allow for easy linkage of non-textual data.  My personal favorite example would be the notification letters and paperwork I have obtained from New York.  As interest in this subject grows, particularly among academics who can do this full-time (or more — grad students don’t work 9-5), notification letters contributed by their recipients may be sanitized and added.  For some breaches, I can even see Wiki-like possibilities.

Last, the datasource should be free, as in beer.  We can argue over which license is best in another post :^).

At any rate, those are some quick thoughts.  I’ve tried to instantiate them, but have been hampered by my lack of skill as a DBA and data-modeller, and my lack of time.  If others are interested in this subject, as I think the example of Attrition and PogoWasRight.org easily demonstrates, we may all benefit from cooperating openly.  I’m interested in reactions, criticisms, suggestions, and even flames.  Let’s hear them.

Well, At Least TSA Isn’t Driving People to Drink

tsa-lotion-bag.jpg

“Everybody personally and professionally that I know who is afraid to fly gets their hands on Xanax,” said Jeanne Scala, a psychotherapist in Roxbury, N.J., adding that she has seen an increase in patients and friends talking about taking medication for flying jitters. “They’ll do anything to take the edge off the anxiety of sitting in a plane,’’ she said. “They just want to zone out, they want to sleep. So they’ll take Ambien, Sonata, even pain medication like Soma, which is for back pain. People use whatever they have — the pharmacy in their house.”

You Are Cleared For Takeoff,” The New York Times.

In case it’s not obvious, I’m posting out of sheer glee that TSA is driving people to illegal drug use as they work to make flying as unpleasant safe as they can, and for the phrase “the pharmacy in their house.” What a great image. Its too bad you can’t go to the drugstore and buy the drugs you want, but that’s not the TSA’s fault. A different government agency screws that one up.