David A. Wheeler's Blog

Success on Fully Countering Trusting Trust through Diverse Double-Compiling

Sun, 29 Nov 2009 19:30 GMT

My November 23 public defense of Fully Countering Trusting Trust through Diverse Double-Compiling went well. This was my 2009 PhD dissertation that expands on how to counter the “trusting trust” attack by using the “Diverse Double-Compiling” (DDC) technique.

Most importantly (to me), my PhD committee agreed that I successfully defended my dissertation. Whew! As a result, I'm essentially done with my PhD.

I learned a lot about creating formal proofs using computers by doing this dissertation. I wanted to give the strongest possible evidence that DDC counters the trusting trust attack, and formal proofs are the strongest form of proof that I know of... which is why I created them. Frankly, creating proofs was kind of fun once I knew what I was doing, but getting there was more painful than it needed to be. Many books are on the underlying mathematics (e.g., giving you extreme detail about various logic systems)... which is great if you're a mathematician, but not so helpful if you are simply trying to use the mathematics. Some books explain how to do things by hand, but that is an unnecessary amount of pain; one of my proofs is 30 steps long, and I sure wouldn't have wanted to create that by hand. Some books seemed to assume that you already knew everything the book covered, which is an odd assumption to me :-).

Here's a trivial example: Most logic systems can prove anything if you give them inconsistent assumptions. That's bad! You can get rid of that problem by sending the assumptions to a model-builder like mace4... if it can create a model, then the assumptions are consistent. So, make sure you send your assumptions through a model-builder to see if your assumptions are consistent.

I've posted detailed data from my dissertation so that people can reproduce my results. I think it's really important that results be reduceable, otherwise, it's not science. As part of that data, I've included a few files that may help potential proof tool users get started. In particular, I've posted prover9 input to prove that Socrates is mortal, a prover9 input to prove that the square root of 2 is irrational, and prover9 input showing how to easily declare that terms in a list are distinct.

The "trusting trust" attack has historically been considered the "uncounterable" attack. Now the attack can be effectively detected — and thus countered.

Fully Countering Trusting Trust through Diverse Double-Compiling

Fri, 20 Nov 2009 11:06 GMT

A last-minute reminder — my public defense of Fully Countering Trusting Trust through Diverse Double-Compiling is coming up on November 23, 1-3pm. This is my 2009 PhD dissertation that expands on how to counter the “trusting trust” attack by using the “Diverse Double-Compiling” (DDC) technique.

It will be at George Mason University, Fairfax, Virginia, Innovation Hall, room 105. [campus location] [Google map] Anyone is welcome!

I've made a few small tweaks over the last few weeks. I modified proof #2 to reduce its requirements even further (making it even easier to do); I had mentioned in text that this was possible, but now the formal proof shows it. I also used mace4 to show that the assumptions of each proof are consistent. Formal proofs aren't easy to create, or trivial to read, but the reason I went to that trouble is to show that it's not just my opinion that I've countered the trusting trust attack... I want to show, conclusively, that the trusting trust attack has been countered. I know of no stronger method to show that than a formal proof.

The "trusting trust" attack has historically been considered the "uncounterable" attack. Nuts to that. Now the attack can be effectively detected — and thus countered.

New PhD Dissertation: Fully Countering Trusting Trust through Diverse Double-Compiling

Mon, 02 Nov 2009 12:19 GMT

An Air Force evaluation of Multics, and Ken Thompson’s Turing award lecture (“Reflections on Trusting Trust”), showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this “trusting trust” attack goes undetected, even complete analysis of a system’s source code will not find the malicious code that is running. Previously-known countermeasures have been grossly inadequate. If this attack cannot be countered, attackers can quietly subvert entire classes of computer systems, gaining complete control over financial, infrastructure, military, and/or business system infrastructures worldwide.

Thankfully, there is a countermeasure to the “trusting trust” attack. In 2005 I wrote a paper on Diverse Double-Compiling (DDC), published by ACSAC, where I explained DDC and why it is an effective countermeasure. But some people still raised concerns. Would DDC really counter the attack? Would DDC scale up to real-world compilers? Also, the ACSAC paper required “self-parenting” compilers — can DDC handle compilers that are not self-parenting?

I’m now releasing Fully Countering Trusting Trust through Diverse Double-Compiling, my 2009 PhD dissertation that expands on how to counter the “trusting trust” attack by using the “Diverse Double-Compiling” (DDC) technique. This dissertation was accepted by my PhD committee on October 26, 2009.

On November 23, 2009, 1-3pm, I will be giving a public defense of this dissertation. If you’re interested, please come! It will be at George Mason University, Fairfax, Virginia, Innovation Hall, room 105. [campus location] [Google map]

This dissertation’s thesis is that the trusting trust attack can be detected and effectively countered using the “Diverse Double-Compiling” (DDC) technique, as demonstrated by (1) a formal proof that DDC can determine if source code and generated executable code correspond, (2) a demonstration of DDC with four compilers (a small C compiler, a small Lisp compiler, a small maliciously corrupted Lisp compiler, and a large industrial-strength C compiler, GCC), and (3) a description of approaches for applying DDC in various real-world scenarios. In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Many people commented on my previous 2005 ACSAC paper on the topic. Bruce Schneier wrote an article on ‘Countering “Trusting Trust”’, which I think is one of the best independent articles describing my work on DDC.

This 2009 dissertation significantly extends my previous 2005 ACSAC paper. For example, I now have a formal proof that DDC is effective (the ACSAC paper only had an informal justification). I also have additional demonstrations, including one with GCC (to show that it scales up) and one with a maliciously corrupted compiler (to show that it really does detect them in the real world). The dissertation is also more general; the ACSAC paper only considered the special case of a “self-parenting” compiler, while the dissertation eliminates that assumption.

So if you’re interested in countering the “trusting trust” attack, please take a look at my work on countering trusting trust through diverse double-compiling (DDC).

Limiting Unix/Linux/POSIX filenames simplifies things: Lowercasing filenames

Sun, 26 Jul 2009 08:40 GMT

My essay Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems argues that adding some limitations on legal Unix/Linux/POSIX filenames would be an improvement. In particular, a few minor limitations (which most people assume anyway) would eliminate certain kinds of bugs, some of which end up being security vulnerabilities. Forbidding crazy things (like control characters in filenames) simplifies creating programs that work all the time.

Here’s a little example of this. I wanted to convert all the filenames inside a directory tree to all lowercase letters. I didn’t want to lose any files without checking on them first, so I wanted it to ask before doing a rename in a way that would eliminate a file (i.e., I wanted to use mv -i). I didn’t find such a program built into my distro, so I wrote a short script to do it (which is just as well, because it makes a nice simple example). I wanted it to be portable, since I might need it again later.

So how do we write this? A simple glob like “*” won’t work, because it needs to recursively descend through a tree of directories, and simple globs will skip hidden filesystem objects too (and I want to include them). I could write a more complex glob that included hidden files and directories, and recursed down through subdirectories, but the naive way of recursing down subdirectories can have many problems (e.g., it could get stuck in endless loops created by symbolic links). If we need to handle a tree recursively, there’s a better tool designed for the purpose — find.

Unfortunately, an ordinary find . has an interesting problem — it will pick the upper-level names first, and if we rename the upper-level names first, find will fail when it tries to enter them (since they will no longer exist). No problem — if we are manipulating the tree structure (including renames), we can use the -depth option of find, which will process each directory’s contents before the directory itself. We can then rename just the basename of what find returns, so we won’t change anything before find descends into it.

Now, if we could assume that newlines and tabs cannot be in filenames, as recommended in Fixing Unix/Linux/POSIX Filenames..., then we can do a simple for loop around the results of find. My shell script mklowercase renames filenames to lowercase letters recursively. Here is its essence:

  #!/bin/sh
  # mklowercase - change all filenames to lowercase recursively from "." down.
  # Will prompt if there's an existing file of that name (mv -i)
  # Presumes that filenames don't include newline or tab.

  set -eu
  IFS=`printf '\n\t'`
  
  for file in `find . -depth` ; do
    [ "." = "$file" ] && continue                  # Skip "." entry.
    dir=`dirname "$file"`
    base=`basename "$file"`
    oldname="$dir/$base"
    newbase=`printf "%s" "$base" | tr A-Z a-z`
    newname="$dir/$newbase"
    if [ "$oldname" != "$newname" ] ; then
      mv -i "$file" "$newname"
    fi
  done

This script skips “.”, which is not strictly necessary, but I thought it would be a good idea to point out that you may need to skip “.” sometimes.

Yes, this could be modified to handle literally all possible Unix/Linux/POSIX filenames, but those modifications make it more complicated and uglier. One approach would be to use one program to use find...-exec, which then invokes another script to do the renaming. But then you have to maintain two scripts, and keep them in sync. You could embed the command into find, but then the find command becomes hideously complicated.

Another solution to handling all filenames would be to change the loop to:

  find . -depth -print0 |
  while IFS="" read -r -d '' file ; do ...

However, this requires non-standard GNU extensions to find (-print0) and bash (read -d), as well as being uglier and more complicated. Also, if “mv” is implemented as required by the Single Unix Standard, then the “mv -i” will fail badly if it tries to rename a file into an existing name. That’s because when it tries to get an answer, it will send a prompt to stderr, but it will expect a RESPONSE from stdin... and yet, stdin is where it gets the list of filenames!!

And it’s all silly anyway. If you put newlines in filenames, lots of scripts fail. It’s simply too much of a pain to deal with them “correctly”. Which is the point of Fixing Unix/Linux/POSIX Filenames — adding some limitations on legal Unix/Linux/POSIX filenames would be an improvement. At the least, by default let’s forbid control characters (so simple “find” and filename display is safe), forbid leading dash characters (so simple globbing is safe), require that all filenames be UTF-8 (so displaying filenames always works), and perhaps forbid trailing spaces (since these are dangerously misleading to end-users). I would like to see kernels build in the mechanisms to forbid certain kinds of filenames, so that administrators can then specify the specific “bad filename” policy they would like to use.

So please take a look at: Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems. I’ve made a few recent additions, thanks to some interesting comments people have sent, but the basic message is the same.

CSIS Cybersecurity Report

Tue, 09 Dec 2008 23:11 GMT

The Center for Strategic and International Studies (CSIS) has just released an interesting new report titled "Securing Cyberspace for the 44th Presidency: A Report of the CSIS Commission on Cybersecurity for the 44th Presidency". The project was co-chaired by Representative James R. Langevin, Representative Michael T. McCaul, Scott Charney, and Lt. General Harry Raduege, USAF (Ret). If you're interested in getting our computer infrastructure more secure, I think this is worth looking at.

The three major findings were: (1) cybersecurity is now a major national security problem for the United States, (2) decisions and actions must respect privacy and civil liberties, and (3) only a comprehensive national secuirty strategy that embraces both the domestic and international aspects of cybersecurity will make us more secure.

Among their recommendations, they suggest "Regulate cyberspace. Voluntary action is not enough. The U.S. must ... set minimum standards in order to ensure that the delivery of critical services in cyberspace continues if the U.S. is attacked... [avoid] prescriptive mandates [and] overreliance on market forces, which are ill-equipped to meet national security and public safety requirements". I agree that market forces, without any help, aren't well-equipped to deliver security, but the challenge is in the details... it's difficult to strike that balance well.

They recommend conducting research and development for cybersecurity - I'm glad they do, that's vitally important. (I just saw the video The Science of Victory, which briefly discusses the importance of research to U.S. national defense.) CSIS also recommends not starting over - instead, they recommend building on and refining the existing "Comprehensive National Cybersecurity Initiative".

In any case, computers and computer networks are no longer interesting toys, they are vital services. We need to improve how we protect them.

Internet Wishlist

Wed, 29 Oct 2008 19:24 GMT

It's election season in the United States, a fact that's rather hard to miss in Northern Virginia (where I live). Popular Science is running a letter by Daniel Engber (of Slate Magazine) in which he offers the US Presidential nominees advice on using the full potential of the Internet upon their election into office. This letter is being discussed in Slashdot. Terry Sweeney believes that issues related to the Internet Won't Matter in this election, and unfortunately, I think he's right. But still, we can hope, can't we?

In any case, election season is a good excuse to think of helpful things that the U.S. government could do relating to the Internet and related IT technology. Engber's letter certainly got me thinking that direction. I think it's useful to try to think of such things, because by examining and discussing them, some of them might come to pass. So in that spirit, here's my candidate list:

Make spam illegal. Make sending unsolicited bulk email (spam) illegal, and in particular, require that people OPT-IN to receive messages sent in bulk. The current 'opt-out' system in the U.S. is silly, and always was. As essentially all information about spam notes, "Never Reply To Spam". "Don't [reply] to the spam message or [try] to send email to an email address given in the body of the spam and asking to be removed from the mailing list... spammers are much too sophisticated now for replies to affect them at all. And the From: addresses in spam messages are usually faked anyway." Responding "just identifies you as a real person who read their message". Europeans have the more sensible opt-in system. Laws do make a differenace; far more spam is U.S. than European in origin, due to the U.S.'s lax laws. It's not that spam hard to define; if more than 1000 people (say) receive it, and they didn't sign up for it (e.g., by signing up for a mailing list), it's spam. A law will not solve everything, but it would help; technical measures can only go so far, and need laws to help make them work. The U.S. currently protects fax machines from spam, and that has worked! The current CAN-SPAM law legalizes spam - and thus is a sick joke. It's time to make it illegal, to protect all of our inboxes.
Require public access (free via web) to federally-funded research. Put all federally-funded unclassified research papers on the web, with no fees or sign-ins, so that a Google search can find it. NIH is already doing this; see the NIH public access policy. NIH isn't perfect; their "12 month" period is silly (the web publication should occur immediately). Still, it's an improvement, and it's absurd that this is limited to NIH; federally-funded research should be published government-wide, no matter what arm it came from. Why should the public pay for research, then pay again to read it? Just imagine how much faster research could go if anyone could quickly click and review the latest research. Just imagine how much better the public could be informed if they could easily read U.S. research on a topic... instead of only having the flim-flam artists. I think I could make a good case that in academic research, the word "published" is increasingly meaning "accessible via Google"; anything Google can't find doesn't exist to many people. It's shameful how certain publishers effectively steal U.S. research for private gain through monopolistic publishing contracts - they do not pay for the research, and typically they don't even pay the researchers or reviewers! If you want exclusive rights to publish research, then you should pay all the costs of performing the research. I can see a case where the publisher footed 50% of the research bill (not just the paper-writing costs) and got a one-year publication delay, but the "owning" of research papers is indefensible. If you accept government money - and the government is of the people, by the people, and for the people - then the people should be receiving the research results. Let's get rid of the unnecessary intermediaries and "poll taxes" on U.S. funded research.
Federally-developed unclassified software: Open source software by default. By default, if the government funds unclassified software development (e.g., via research), that software should be released as open source software (under some common license). That way, anyone can use it, modify, and redistribute it (in modified or unmodified form). Again, why should the public pay for software, then pay again to use it? Currently, if researcher B wants to continue work of researcher A, both of which were paid via government funds, researcher B typically has to re-implement what researcher A did - and that can stop the research before it begins. This even applies to the government itself; often the government pays for re-development of the same software, because there's no public information on software the government has already paid to develop. If the funds are mixed, try to break it down into pieces; if that won't work, release the mixed-funding software after some fixed time (the U.S. DoD has a 5-year clock, starting at contract signing, for when the DoD could release some mixed-funding software as open source). If you are starting a proprietary software company, and want exclusive rights to developed software, then go to the bank or a venture capitalist (VC). The government is not a VC, so don't expect it to be one. Exceptions will be needed... but they should be exceptions, not the rule.
Increase funding on computer security. Some is done now, of course, but it pales compared to the problem. I guess this could be construed as being self-serving; after all, I try to improve computer security as a living. But the reason I do it is because I believe in it. There are many tools that enhance our muscles (cars, jackhammers, etc.), but essentially only one tool that enhances our mind: Computers. Which is one reason why computers are everywhere. Yet their very ubiquity is a problem, because they were generally not designed to be secure against determined attackers. I believe governments should not try to do all things; there are a lot of things government just isn't good at. But defense is an area that is hard to do on an individual or business-by-business basis, yet we need it collectively - and it's those kinds of problems that governments can help with.
Increase formal methods research. The world is globalizing, and we increasingly depend on software. Testing is not a good way to make (or verify) high quality software; you can't even fully test the trivial program "add 3 64-bit numbers" in less time than the age of the universe. In the long run, if we want really high levels of quality for software, we need better approaches, and there's one obvious one: Formal methods. Formal methods apply mathematical approaches to software development. There are a lot of reasons people don't use them today in typical software development projects, though. We need research to help turn those reasons into the past tense for most projects.
Drop the DMCA's anti-circumvention measures. The anti-circumvention stuff is just nonsense; they don't fight piracy, but they do try to inhibit legal activities - and thus encourage lawlessness. XKCD's "Steal this comic" shows the nonsense that Digital Restrictions Management (DRM) schemes bring, ones that the DMCA is absurdly trying to prop up. As far as I can tell, people are still making music and movies, even though the DRM schemes (and the anti-circumvention measures that prop them up) are a failure. Anti-circumvention measures make obviously lawful uses illegal (e.g., viewing DVDs on a Linux machine or putting your DVDs on your hard drive) - encouraging everyone to break the law.
Drop software patents. Software patents have been a massive unjustified government intervention in the market. There is still no evidence that they are an improvement, and a lot of evidence that they are causing serious market failures. Save massive amounts of government money by getting rid of the whole useless bureaucracy.
Fix copyright laws so that they make sense to normal people. I believe that the current copyright laws were written under the assumption that only large publishers, with reams of lawyers, needed to understand them. Now 9-year-olds need to understand them... except that they're completely nonsensical. "Normal" people expect that short extractions aren't copyright infringements, yet current U.S. law and court cases endorse such nonsensical interpretations (e.g., Bridgeport Music Inc. v. Dimension Films, 410 F.3d 792 (6th Cir. 2005) seems to say that even 3 notes can be an infringment). Strictly speaking, many Youtube videos break the law, even when a normal person would expect that the use would be okay. The term lengths of copyright far exceed the minimum necessary to obtain such works (which should be the criteria), and "fair use" needs to be clearer and more expansive. The penalties are also absurd; I disapprove of illegal copying, but the current penalties ($750 for a $1 song??) are so disproportionate that they probably violate the U.S. Constitution's 8th amendment ("Excessive bail shall not be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted."). I believe that copyright law is in principle a good idea, but it sure isn't working in practice like it's supposed to. See Tales from the Public Domain: Bound by Law for an interesting perspective on this. For a specific example, I think that anything not marked by its author as copyrighted should be in the public domain; currently every jot and tiddle on the Internet is "copyrighted" by someone, making it nigh-impossible to keep track of all the claims over rights. It used to be that way - there's no reason it couldn't be again. A much shorter copyright term would be helpful, too - something within people's lifetimes. In the past, publishers got disproportionate control over the process of modifying the copyright laws. We need to fix these laws so that they balance the needs of creators, publishers/distributors, and recipients. They need to be very simple, clear, and fair, because with the Internet, 9-year-olds can and do become publishers.

So, there's my Christmas list. Some of them don't even cost money; they simply remove bad laws, and actually save money. This is my personal list, not influenced by my employer, my pets, and so on. Perhaps this list (and others like it) will start the ball rolling.

Oracle letter to Universities: Educate software developers on security/assurance!

Thu, 15 May 2008 12:08 GMT

I am delighted to point out a really interesting letter to Universities by Mary Ann Davidson, the Chief Security Officer of Oracle Corporation. It basically tells colleges and universities to stop ignoring security, and to instead include software security principles in their computer science curricula. I'm so delighted to see this letter, which has just been released to the public (it had been privately sent to many colleges and universities). Let me point out and comment on some great points in this letter, because I think this letter is really important.

In this letter, she notes that "many security vulnerabilities can be traced to a relatively few types of common coding errors". I've noted that myself, by the way; simply educating developers on what the common (past) mistakes are goes a long way towards eliminating vulnerabilities. She then notes, "most developers we hire have not been adequately trained in basic secure coding principles in their undergraduate or graduate computer science programs." I agree and think it's horrific; more on that in a moment. She clarifies that this is a really important problem: "Security flaws are widely recognized as a threat to national security and to the privacy and financial well being of individual citizens, in addition to the costs they impose on us and our customers." They haven't just let this be; as they note, "We have therefore had to develop and roll out our own in-house security training program at significant time and expense." Kudos to Oracle for doing such training, by the way; far too many organizations don't do that, which explains why software continues to have the same old vulnerabilities as it did 30 years ago. But clearly Oracle cannot train the world, nor it is reasonable to expect that they do so.

She also states that "We believe that the ability to recognize and avoid common errors that can result in catastrophic security failures should be a core part of computer science curricula and that the above measures will foster such change. We strongly recommend that universities adopt secure coding practices as part of their computer science curricula, to improve the security of all commercial software, and ensure that their graduates remain competitive in the job market." To that I say, Amen.

By itself, that's great, but here's the kicker: "In the future, Oracle plans to give hiring preference to students who have received such training and can demonstrate competence in software security principles." Do you see this? Students at colleges and universities that fail to properly prepare them will be at a competitive disadvantage!

Today, almost all computer science and software engineering graduates will develop software that connects to a network, or must take data from a network... yet almost all are absolutely clueless about how to do so. Not because they don't know what a "socket" is, but because they don't know how to counter attacks. And if you're hooked to a network, or take data from one, you will get attacked.

Yet the education community (with a few wonderful exceptions) still completely ignores the need to educate software developers on how to develop secure software. "It's not my job" is not just wrong; it's almost criminal. Society is depending on the educational community to educate students in the fundamentals of what they need to know. Society depends on software, and essentially every student in a software-related field will, after they graduate, write software that will be attacked. Attacks are no longer a surprise - they are a guarantee. Yet the educational system that's supposed to prepare our developers fundamentally fails to do so. Since attacks are guaranteed, and the students are guaranteed to not know how to counter them, what other results would you expect? The basics of developing secure software should be a mandatory part of computer science and software engineering undergraduate curricula. The vulnerabilities that the students will embed in software, if they do not get this education, will lead to great loss of life and the loss of billions of dollars. Sure, schools already have a lot of material to cover, but practically nothing in a computer science curricula is as important as how to develop secure software; I can think of no other omissions in the CS curricula that cause so much damage. Don't tell me that you only teach the "fundamentals"; programming languages change, but the need for security will never go away; it is fundamental. I think computer science and software engineering departments that do not explain the basics of developing secure software to all of their undergraduate and graduate students should be shut down, as a menace to society, until they change their ways.

Oh, if you want to see more about this letter, see Mary Ann Davidson's blog article about it, "The Supply Chain Problem", where she talks about what led up to the letter, and the follow-on from it: "Last year, I got fed up enough with Oracle having to train otherwise bright and capable CS grads in secure coding 101 that I sent letters to the top 10 or so universities we recruit from (my boss came up with the idea and someone on my team executed on it - teamwork is a wonderful thing)... I am sorry to state that only one of those universities we wrote to responded to my letter... We need a revolution - an upending of the way we think about security -and that means upsetting the supply chain of software developers... To universities, I cannot but contrast the education of engineers with that of computer science majors. Engineers know that their work product must above all be safe, secure and reliable. They are trained to think this way (not pawn off 'safety' on 'testers') and their curricula builds and reinforces the techniques and mindset of safe, secure and reliable product. (A civil engineer who ignores the principles of basic structures - a core course - in an upper level class is not going to graduate, and can't dismiss structures as a 'legacy problem.')"

I would love to see many organizations banding together to sign a letter like this one. If enough organizations band together, I think many universities and colleges will finally get the message. I would expand it beyond computer science, to any curricula with a significant amount of software development (such as software engineering, MIS, and so on), but that's a quibble. My goal is not to shut down any departments (I hope that's clear); it's to repair a serious omission in our educational system. Kudos to Mary Ann Davidson, for writing the letter and sending it to a number of Universities. When I learned of it, I begged her to please post it publicly. To her great credit, she's now done so. Thanks, from the bottom of my heart! Now colleges and universities have even fewer reasons to claim the nonsense, "well, no one wants information on developing secure software." The companies that will hire your students know otherwise.

Securing Open Source Software (OSS)

Tue, 06 May 2008 21:17 GMT

I've just posted my presentation titled "Securing Open Source Software (OSS or FLOSS), which is to be presented at the 8th Semi-Annual Software Assurance Forum, May 6-8, 2008, Sheraton Premiere, Tyson's Corner in Vienna, Virginia. In it, I discuss how to improve the security of an OSS component by modifying its environment, as well as securing the OSS component itself (by selecting a secure component, building a secure component from scratch, or modifying an existing component). I include a number of examples; they're necessarily incomplete, but I hope it will help people who are developing or deploying systems. (Here is "Securing Open Source Software (OSS or FLOSS)" in OpenDocument format.) Enjoy!

Twisted Mind of the Security Pro

Fri, 21 Mar 2008 10:08 GMT

Bruce Schneier's "Inside the Twisted Mind of the Security Professional" is highly-recommended reading - he explains the different kind of thinking required to be good at making things secure. Security pros are able to see the bigger picture, and in particular, they are able to see things from from an attacker's perspective.

For example, "SmartWater is a liquid with a unique identifier linked to a particular owner. 'The idea is for me to paint this stuff on my valuables as proof of ownership,' I wrote when I first learned about the idea. 'I think a better idea would be for me to paint it on your valuables, and then call the police.'" Similarly, on opening up an ant farm, his friend was surprised that the manufacturer would send you ants by mail; Bruce thought it was interesting that "these people will send a tube of live ants to anyone you tell them to."

Being able to think like an attacker is so important that in my book on writing secure programs, I gave it its own heading: paranoia is a virtue. It's still true. My thanks to Bruce Schneier for expressing this need so eloquently.

We would live in a better world if all of us could see the world as attackers do - or at least make the effort to try. In particular, we'd stop doing many foolish things in the name of "security", and instead do things that actually secured our world.

Software Assurance 2007

Thu, 04 Oct 2007 13:22 GMT

Lots of interesting things are happening with the various efforts to eliminate or counter software vulnerabilities. The Software Security Assurance (SwA) State-of-the-Art Report (SOAR) tries to list what's going on, especially in things related to the U.S. government. As with any such document, it's incomplete, and it's only a snapshot (things keep changing!). But if you haven't been following this world, and want to know "what's going on", it's the best place I know of to start. Of course, you can also look at sites such as the U.S. DHS / CERT "build security in" site.

The U.S. National Vulnerability Database tracks specific vulnerabilities in specific products; they identify each vulnerability using the unique id defined by Common Vulnerabilities and Exposures (CVE). But if the world is going to prevent these kinds of vulnerabilities from happening in the future, we need to categorize them in a way that everyone agrees what the categories are. Informally, there are lots of ways to categorize them, but their meanings differ between people. That's a real problem when comparing tools; different tools find different problems, but without agreed-on terminology, it's hard to even describe their differences. MITRE is currently developing a way to categorize all vulnerabilities in a way that everyone can agree on, called Common Weakness Enumeration (CWE). The U.S. National Vulnerability Database and MITRE have worked out a set of CWEs that they will use to categorize vulnerabilities. The CWE is still being developed, but at least some common terminology is getting worked out.

Audio for "Open Standards and Security" online

Tue, 20 Mar 2007 18:28 GMT

Last year in Boston I gave a presentation titled "Open Standards and Security", explaining why open standards are needed for security; here is "Open Standards and Security" as a PDF. You can also get it in OpenDocument format (for the OpenDocument version, make sure you have the fonts you need). I had earlier posted a blog entry about it, and Newsforge had some very nice things to say about my talk. I used several stories in my talk, which the reporter called "parables". I didn't use that word, but I wish I had, because that's exactly what those stories were.

Many people never got to hear it, so I've finally made an audio version of it and posted it here in several formats: [OGG (Vorbis)], [MP3], and [FLAC]. Download and enjoy! You should be able to understand the talk just from listening to the audio, but if you listen to the audio while reading the slides, all the better!

Of course, having to post multiple audio formats shows how immature the audio standards area is. While ISO has a standard (MP3), MP3 is not an open standard because it's patent-encumbered. I recommend using the Ogg Vorbis format instead - it's the smallest file, and it has very good quality. Ogg Vorbis produces smaller files with better sound than MP3, so the only real reason to use MP3s is because your equipment can't handle anything else. The FLAC format is lossless, and is useful for recoding later (it's much smaller than a WAV or AIFF while still being lossless).

The solution to this nonsense is not to have no standards. The solution is to either (1) get countries to stop permitting software patents (the best solution), or at least (2) get standards organizations to stop publishing closed standards like MP3 for software. I think the tide has already started turning for option 2. After all, when MP3 was created, many still thought that patents in IT standards were okay, and relatively few understood the problems that patents could cause. Fundamentally, of course, this made no sense; the whole point of a patent is to create temporary monopolies, while the whole point of an open standard is to enable competition (the opposite of monopolies). People have tried to make compromises that don't really work, such as having so-called RAND policies. But I think these are clear failures; all royalty-bearing patents discriminate (for example, they prevent open source and no-cost implementations). The point of patents is to prevent competition, and thus they have no place in software standards. Now that software patents have been shown to be a "Wild West" where anyone can be sued for billions, the need for unencumbered standards should be quite clear. The W3C has already changed its policies to make it very hard to publish patent-encumbered standards, and the IETF has already thrown out several proposals specifically because they were encumbered by patents.

One of the people at my talk made the claim that, "today, every successful open standard is implemented by FLOSS." That should be easy to disprove -- all I need is a counter-example. Except that counter-examples seem to be hard to find; I can't find even one, and even if I eventually find one, this difficulty suggests that there's something deeper going on. So as a result of thinking about this mystery, I wrote a new essay, titled Open Standards, Open Source. It discusses how open standards aid free-libre / open source software (FLOSS) projects, how FLOSS aids open standards, and then examines this mystery. It appears that it is true -- today, essentially every successful open standard really is implemented by FLOSS. I consider why that is, and what it means if this is predictive. In particular, this observation suggests that an open standard without a FLOSS implementation is probably too risky for users to require, and that developers of open standards should encourage the development of at least one FLOSS implementation. The point of the "Open Standards and Security" talk was on open standards, not on FLOSS, but there's much to be learned from their inter-relationships.

Internet Explorer 7: Still a security problem, keep using Firefox

Mon, 05 Feb 2007 18:38 GMT

Microsoft's Internet Explorer (IE) is a major security problem. The Washington Post found some horrific statistics that justify this claim pretty well: "For a total 284 days in 2006 (or more than nine months out of the year), exploit code for known, unpatched critical flaws in pre-IE7 versions of the browser was publicly available on the Internet. Likewise, there were at least 98 days last year in which no software fixes from Microsoft were available to fix IE flaws that criminals were actively using to steal personal and financial data from users... In contrast, Internet Explorer's closest competitor in terms of market share -- Mozilla's Firefox browser -- experienced a single period lasting just nine days last year in which exploit code for a serious security hole was posted online before Mozilla shipped a patch to remedy the problem."

Let's sum that up: in 2006, IE was unsafe 78% (284/365) of the time - 27% (98/365) had known criminal use - compared to Firefox's 2% (9/365). This is an improvement for IE; in 2004, it was unsafe 98% of the time, and 54% of the time there was known active exploitation of them. But Firefox is improving too; in 2004 it was unsafe 15% of the time (with 0% known exploitation), and half of that time only affected Macintosh users. (I blogged on these Internet Explorer / Firefox security statistics in 2005.) You really want to be using the safer product, and now we have two different years with the same result. But none of these studies considered IE version 7... so has it all changed?

IE version 7 is finally out, and I'd like to think it's better than IE 6. Indeed, I suspect IE 7 is better than its predecessor; Microsoft did try to improve IE security, and IE 6's security was so bad that it was hard to get worse. But IE is not the only browser available, and early signs suggest that IE is still far behind Firefox.

In particular, there are already signs that Microsoft still isn't addressing vulnerabilities aggressively the way that the Mozilla/Firefox team have been doing for years. Why? Because recent "Full disclosure" and Bugtraq postings give room for worry. Michal Zalewski's "Web 2.0 backdoors made easy with MSIE & XMLHttpRequest" (3 Feb 2007) noted that the XMLHttpRequest object (used by many so-called "web 2.0" applications) allows "client-side web scripts to send nearly arbitrary HTTP requests, and then freely analyze and manipulate the returned response, including HTTP headers. This gives an unprecedented level of control over your browser to the author of a visited site. For this reason, to prevent various types of abuse, XMLHttpRequest is restricted to interacting only with the site from where the script originated, based on protocol, port, and host name observed. Unfortunately, due to a programming error, Microsoft's Msxml2.XMLHTTP ActiveX object that MSIE relies on allows you to bypass this restriction with the use of - BEHOLD - a highly sophisticated newline-and-tab technology." (This last bit about being "highly sophisticated" is quite sarcastic; security problems with control characters like newline and tab are as old as computer security problems.)

One poster found a previous May 2006 article about this problem: "IE + some popular forward proxy servers = XSS, defacement (browser cache poisoning)". Indeed, the basic information goes back to September 2005. (There are hints in January 2003, but to be fair few noticed its implications at the time.)

Now it turns out that this kind of error is easy to make; even the Mozilla/Firefox people made this kind of error. In particular, this basic problem (differing in some details) was identified and fixed in Mozilla in 2005 as bug 297078.

The problem in this case isn't that the Microsoft people made an error, and the Mozilla/Firefox people didn't. Certainly, there's evidence that Mozilla's policy of releasing the source code for people to review, combined with worldwide development/review and a "bug bounty" to encourage additional review, really does produce good results. But in this case, both Microsoft and Mozilla made the error; what's different is what happened next. Mozilla fixed it in 2005, the same year the issues had become clear, yet Microsoft still hasn't fixed it in 2007. (And no, this particular defect isn't included in the Washington Post study above; it sure wouldn't improve IE's statistics if they had.)

If a supplier won't quickly fix known security problems, that's a really big warning sign. The Washington Post earlier found that Microsoft took far longer to fix a vulnerability than Mozilla, and this latest report is consistent with that sad news. I do not understand why Microsoft hasn't addressed this; hopefully this will turn out to be a false alarm (that seems unlikely) or they will fix it soon.

The only way to really see which browser is more secure is examine its vulnerability pattern over time into the future - for example, does it have more vulnerabilities over time (of a certain criticality), and how fast are reported vulnerabilities repaired? But note a key issue: unless you throw away the entire program and start over from scratch, it's difficult to turn an insecure program into a secure one. Thus, while past performance is no guarantee of future results, it's a good way to bet. It appears that Microsoft still hasn't fixed all the problems in IE 7 that were publicly known at least two years earlier (in some of the most widely publicized vulnerability discussion groups!). If that's true, it's a really bad sign... how can they have removed most vulnerabilities not publicly known, if they haven't even addressed the ones already publicly known?

I continue recommending that users switch to Firefox and not use IE for security reasons. And I highly recommend that web developers ensure that their systems conform to web standards so that users can choose and switch their browsers. These are only my personal opinions, but I think you can see why I think it makes sense. Even ignoring this particular issue, IE has a terrible track record. I'm glad that Microsoft is starting to take security seriously (they are at least saying the right things), and I'd delight in a race between suppliers to see who can produce the most secure software. But these recent reports reinforce the supposition that IE is still too dangerous to use safely. There's nothing "user friendly" about a program that is easily subverted.

Flawfinder version 1.27 released!

Tue, 16 Jan 2007 23:41 GMT

I've released yet another new version of flawfinder - now it's version 1.27. Flawfinder is a simple program that examines C/C++ source code and reports on likely security flaws in the program, ranked by risk level.

The big functional addition is that flawfinder can now examine just the changes in a program. If you're modifying a big program, it can be overwhelming to view all of the warnings flawfinder can produce... but if you can look at only the ones relevant to the change you are making, it can be easier to handle. My thanks to Sebastien Tandel - he suggested the feature, I replied in a brief email describing how I thought it could be done, and in the same day he replied with code to implement it. Wow, that's truly amazing. His original patch only worked with Subversion; I modified it so that it also works with GNU diff. For this to work, you use the new "--patch" option and give flawfinder a patch file (in unified diff format) that describes the changes... and flawfinder will only report on the potential vulnerabilities on the changed lines (or the lines immediately above and below them).

An administrative change is that flawfinder is now hosted on SourceForge.net, with a mailing list and a Subversion repository for code changes. This should make it easier for people to discuss the program, submit changes, and generally keep track of things. And it also deals nicely with the "what happens if he's hit by a bus" problem.

You can view the Flawfinder ChangeLog for the details on the other changes. It deals more gracefully with unreadable files and when there are zero lines of code. Also, it now skips by default any directories beginning with "."; this makes it work nicely with many SCM systems (use "--followdotdir" if you WANT it to enter such directories). My thanks to Steve Kemp, cmorgan, and others.

For more info, or a copy, just go to my original flawfinder home page or the new flawfinder page on SourceForge.net. Enjoy!

DRM Nonsense, HD DVD, AACS, and BackupHDDVD - why "content protection" doesn't

Sun, 07 Jan 2007 23:58 GMT

Hollywood wants to prevent piracy - and that is understandable. But in their zeal it sometimes appears that some who create movies or music don't care what privacy, security, legal rights, or laws of physics they try to violate. And that is a real problem. DRM proponents want to release digital information to people, yet make it impossible to copy them. Yet the whole point of digital processing is to enable perfect copies. DRM (Digital Rights Management or Digital Restrictions Management) is truly "defective by design". As others have said, DRM is an attempt to change water so it's not wet.

The recent reports about HD DVD are showing the folly of DRM in general. HD DVD encrypts a movie, and then encrypts that movie key many different times on the DVD as well - once for each player. The theory here is that the movie industry could then revoke a player key by simply not including that key on future DVDs. I think the first time they try to actually do this, they'll see the folly of it -- it would mean that millions of customers would suddenly no longer have access to future movies through a device they purchased that they expected to work with them. Can anyone say "class action lawsuit"? I knew you could!

But it turns out that this idea has a fatal flaw technically, as shown by BackupHDDVD (you can see the code, comments, NY Times article, and Slashdot discussion). The code itself is no big deal - it just implements the decryption protocol, which is publicly known anyway. But the interesting trick is that the released software requires the master decryption key for that specific movie, and the implementor is claiming that he has found a way to get this key from a player. To be fair, he hasn't proven he can get such keys by actually sharing any real keys, but let's presume that he is telling the truth; his described method for getting them is very plausible. Yet the implementor is not revealing the player that he got this from or the exact details of how he got them.

That's more clever than it first appears. The creators of the DRM scheme assumed that anyone who broke a player would reveal the player's private key. But because BackupHDDVD's creator doesn't reveal that key, he never reveals the player he's broken into. Since the DRM scheme masters don't know which player was broken into, their revocation scheme won't work. Many other revocation schemes for media use the same basic approach, and so they would fall the same way.

Some Blu-ray folks are claiming that this shows their scheme works better, because they can include additional crypto stuff on the media. But this shows that they don't understand the nature of the problem; it's not hard to implement the crypto interpreter, and since you wouldn't know which player to revoke, you would give all the crypto interpreter information away too. They'd just need to send around the decrypted decryptor... which would be trivially acquired. Once again, DRM is doing nothing to stop piracy, but it's certainly interfering in legitimate use. Sorry, but water stays wet.

I do not approve of piracy. I don't approve of murder, either, yet I approve of the sale of steak knives and cleaning supplies... and would oppose trying to halt their sales. Certainly the costs to consumers of DRM measures are considerable, yet they are actively against the interests of customers.. and they even fail to do the one thing they are supposed to do. DRM proponents are often laughingly referred to as the MAFIAA (Music And Film Industry Association of America), in part because their actions towards their own customers seem actively hostile. DRM seems to be primarily about preventing people from using in legitimate ways the products they've already purchased, and has nothing to do with actually preventing illegal activities. Why can't I transfer that music or movie I bought to a new device I just bought? Or to an old CD so I can play it on older equipment? Why can't I watch what I bought using GNU/Linux or BSD systems? Why can't I use a $3000 display's full resolution at all times for movies I have legitimately bought? Measures this extreme that create monopolies and inhibit legal activities are not a good thing, and are worse than the piracy that DRM measures are trying to prevent.

What's worse, the anti-consumer impacts of DRM don't even inhibit piracy. The big piracy operations will just continue to make direct copies of the bits using specialized equipment, and DRM cannot affect that at all. Individuals can make recordings of the displays or sounds... again, DRM can't really counteract that (there are anti-sync measures for video, but they are easily foiled). So DRM will fail against individuals, and against large-scale piracy, period. Since DRM tries to prevent many legitimate uses, it also encourages law-abiding citizens to break them... and so far they've all fallen, given that additional incentive. The fact that DRM is not even successful at doing what it's supposed to do is just icing on the cake. Even if DRM worked, it is still worse than the problems it is trying to stop.

DRM is the disease, not the cure. It's time for content industries to take advantage of technology, instead of trying to halt the use of technology. Instead of DRM, they should sell non-DRMed content using standards that everyone can implement... and then they can sell their content to a very large unified market.

Direct Recording Electronic (DRE) Voting: Why Your Vote Doesn't Matter

Sat, 14 Oct 2006 23:51 GMT

Direct Recording Electronic (DRE) voting machines have been installed in many locations across the United States. In a DRE machine, votes are only recorded electronically -- there's no paper that voters check. DREs can be rigged to forge any election, fairly easily, so DREs are completely inappropriate for use in any serious election. In fact, I suspect that vote-rigging has already occurred with DREs, and there is no way to prove otherwise.

In September 2006, Feldman, Halderman, and Felten posted "Security Analysis of the Diebold AccuVote-TS Voting Machine", showing how trivial it was to completely control a common DRE voting machine. It turned to be trivial to write programs to do vote-stealing. The manufacturer's reply didn't really address the issue at all. A report on the Nedap/Groenendaal ES3B voting computer found that anyone given brief access to a different voting machine can gain complete and virtually undetectable control over election results - and how radio emanations from an unmodified ES3B can tell who voted what from several meters away.

On the Secure Coding mailing list (SC-L), Jeremy Epstein noted that election officials' responses was "amusing and scary"; when shown that DREs could be trivially subverted, instead of forbidding the use of DREs, they ignored the problem and asked why the researchers didn't attack real systems. That's a foolish question - anyone who really wanted to control an election would just do it and not tell anyone. The manufacturer of that system claims that all the problems reported by the researchers have been 'fixed'. I'm willing to believe that some elections were fixed, but if there's no voter-verifiable paper trail, the machines are not appropriate for real elections. Since they lack a voter-verifiable paper trail, no DRE can be trusted. Period.

I used to do magic tricks, and all magic tricks work the same way - misdirect the viewer, so that what they think they see is not the same as reality. Many magic tricks depend on rigged props, where what you see is NOT the whole story. DREs are the ultimate illusion - the naive think they know what's happening, but in fact they have no way to know what's really going on. There's no way to even see the trap door under the box, as it were... DREs are a great prop for the illusion. Printing "zero" totals and other stuff looks just like a magic show to me - it has lots of pizazz, and it distracts the viewer from the fact that they have no idea what's really going on.

I'm of the opinion that elections using DREs have already been manipulated. No, I can't prove that an election has been manipulated, and I certainly can't point to a specific manufacturer or election. And I sincerely hope that no elections have been manipulated. But there's a lot of money riding on big elections, and a small fraction of that would be enough to tempt someone to do it. And many people strongly believe in their cause/party, and might manipulate an election on the grounds that it's for the "greater good" - it need not be about money at all.

It's crazy to assume that absolutely no one's subverted a DRE in an election, when it's so easy and the systems are known to be weak. The whole problem is that DRE designs make it essentially impossible to detect massive fraud, almost impossible to find the perpetrator even if you detected it, and allow a single person to control an entire election (so there's little risk of a "squeeler" as there is with other techiques to subvert elections). And if an unethical person knows they won't be caught, it increases the probability of them doing it. Anyone who thinks that all candidates and parties are too honest to do this needs to discover the newspaper and history books. Ballot-stuffing is at least as ancient as ancient Greece, and as modern as Right Now.

These voting systems and their surrounding processes would not meet the criteria for an electronic one-armed bandit in Las Vegas. Yet there's more at stake. Many people have motives for subverting elections - DREs provide the method and opportunity. The state commissions cannot provide any justifiable evidence that votes are protected from compromise if they use DREs. And that is their job.

For more information about the problems with DREs, see Frequently Asked Questions about DRE Voting Systems. Another interesting article is Bruce Schneier's "The Problem with Electronic Voting Machines"

There's a solution, and that's verified voting - see the verified voting site. The Verified Voting Foundation advocates the use of voter-verified paper ballots (VVPBs) for all elections (so voters can inspect individual permanent records of their ballots before they are cast and so meaningful recounts may be conducted), insists that electronic voting equipment and software be open to public scrutiny, and that random, surprise recounts be conducted on a regular basis to audit election equipment. I would add at least three things: (1) there must be separate voting stations and ballot readers, where the ballot reader totals are the only official votes (this prevents a collusion by the voting station), and (2) there should a standard paper ballot format; this makes it possible to have independent recounts using equipment from different manufacturers, as well as making it possible to mix-and-match vendor equipment (lowering costs for everyone); (3) there should a standard electronic formats for defining elections and producing results, again to make it possible to dramatically reduce costs by enabling mixing and matching of equipment. I also think having 100% of the source code of these systems publicly available for inspection is important - the public must depend on these systems, so the public should be able to know what they are depending on. The Open Voting Consortium (OVC) is a non-profit organization dedicated to the development, maintenance, and delivery of open voting systems for use in public elections. OVC is developing a reference version of free voting software to run on very inexpensive PC hardware, which produces voter-verifiable paper ballots.

I hope that election officials will see the light, and quickly replace DREs with voting systems that could actually be trusted. If not, I think we're headed for election disputes that will make the year 2000 disputes look like like a picnic. If election officials don't get rid of DREs, sooner or later we will have an election where one candidate wins even though all the polls will say he/she lost... and then the courts will find out that they're untrustworthy and do not permit any kind of real audit or recount.

DREs are unfit for use in any elections that matter. They should be decommissioned with prejudice, and frankly, I'd like to see laws requiring vendors to take them back and give their purchasers a refund, or add voter-verified paper systems acceptable to the customer at no charge. (As I noted earlier, the paper needs to meet some standard too, so that you can use counting machines from different manufacturers to prevent collusion.) At no time was this DRE technology appropriate for use in voting, and the companies selling them would have known better had they done any examination of their real requirements. The voters were given a lemon, and they should have the right to get their money back.

Two new presentations: "Open Source Software and Software Assurance" and "Open Standards and Security"

Thu, 30 Mar 2006 19:28 GMT

I've put two presentations on my website you might find of interest.

The first one is Open Source Software and Software Assurance. Here I talk about Free-Libre / Open Source Software (FLOSS) and its relationship to software assurance and security. It has lots of actual statistics, and a discussion on review. I also deal with the chestnut "can't just anyone insert malicious code into OSS?" -- many questioners don't realize that attackers can change proprietary software too (attackers generally don't worry about legal niceties); the issue is the user's supply chain. I gave this presentation at FOSE 2006 in Washington, DC, and I've given variations of this presentation many times before.

The second presentation is "Open Standards and Security". Here I focus on the role of open standards in security, which turns out to be fundamental.

I'll be giving the "Open Standards and Security" presentation at the "LinuxWorld Government Day: Implementing Open Standards" track, April 4, 2006, in Boston, Massachusetts. I'll speak at 12:45, so come hear the presentation... you'll miss much if you only read the slides.

Unsigned characters: The cheapest secure programming measure?

Tue, 28 Mar 2006 21:39 GMT

Practically every computer language has "gotchas" -- constructs or combinations of constructs that software developers are likely to use incorrectly. Sadly, the C and C++ languages have an unusually large number of gotchas, and many of these gotchas tend to lead directly to dangerous security vulnerabilities. This forest of dangerous gotchas tends to make developing secure software in C or C++ more difficult than it needs to be. Still, C and C++ are two of the most widely-used languages in the world; there are many reasons people still choose them for new development, and there's a lot of pre-existing code in those languages that is not going to be rewritten any time soon. So if you're a software developer, it's still a very good idea to learn how to develop secure software in C or C++... because you'll probably need to do it.

Which brings me to the "-funsigned-char" compiler option of gcc, one of the cheapest secure programming available to developers using C or C++ (similar options are available for many other C and C++ compilers). If you're writing secure programs in C or C++, you should use the "-funsigned-char" option of gcc (and its equivalent in other compilers) to help you write secure software. What is it, and what's it for? Funny you should ask... here's an answer!

Let's start with the technical basics. The C programming language includes the "char" type, which is usually used to store an 8-bit character. Many internationalized programs encode text using UTF-8, so a user-visible character be stored in a sequence of "char" values. but even in internationalized programs text is often stored in a "char" type.

The C standard specifically says that char CAN be signed OR unsigned. (Don't believe me? Go look at ISO/IEC 9899:1999, section 6.2.5, paragraph 15, second sentence. So there.) On many platforms (such as typical Linux distributions), the char type is signed. The problem is that software developers often incorrectly think that the char type is unsigned, or don't understand the ramifications of signed characters. This misunderstanding is becoming more common over time, because many other C-like languages (like Java and C#) define their "char" type to be essentially unsigned or in a way that it wouldn't matter. What's worse, this misunderstanding can lead directly to security vulnerabilities.

All sorts of "weird" things can happen on systems with signed characters. For example, the character 0xFF will match as being "equal" to the integer -1, due to C/C++'s widening rules. And this can create security flaws in a hurry, because -1 is a common "sentinel" value that many developers presume "can't happen" in a char. A well-known security flaw in Sendmail was caused by exactly this problem (see US-CERT #897604 and this posting by Michal Zalewski for more information).

Now, you could solve this by always using the unambiguous type "unsigned char" if that's what you intended, and strictly speaking that's what you should do. However, it's very painful to change existing code to do this. And since many pre-existing libraries expect "pointer to char", you can end up with tons of useless warning messages when you do that.

So what's a simple solution here? A simple answer is to force the compiler to always make "char" an UNSIGNED char. A portable program should work when a char is unsigned, so this shouldn't require any changes to that code. Since programmers often make the assumption, let's make their assumption correct. In the widely-popular gcc compiler, this is done with the "-funsigned-char" option; many other C and C++ compilers have similar options. What's neat is that you don't have to modify a line of source code; you can just slip this option into your build system (e.g., add this option to your makefile). This is typically very trivial to do; typically you can just modify (or set) the CFLAGS variable to add this option, and then recompile.

I also have more controversial advice. Here it is: If you develop C or C++ compilers, or you're a distributor who distributes a C/C++ compiler... make char unsigned by default on all platforms. And if you're a customer, demand that from your vendor. This is just like similar efforts going on in operating system sales to users; today operating system vendors are changing their systems so that they are "secure by default". At one time many vendors' operating systems were delivered with all sorts of "convenient" options that made them easy to attack... but getting subverted all the time turned out to be rather inconvenient to users. In the same way, development tools' defaults should try to prevent defects, or create an environment where defects are less likely. Signed characters are basically a vulnerability waiting to happen, portable programs shouldn't depend on a particular choice, and non-portable software can turn on the "less secure" option when necessary. I doubt this advice will be taken, but I can suggest it!

Turning this option on does not save the universe; most vulnerabilities will not be caught by turning on this little option. In fact, by itself this is a very weak measure, simply because by itself this doesn't counter most vulnerabilities. You need to know much more to write secure software; to learn more, see my free book on writing secure programs for Linux and Unix. But stick with me; I think this is a small example of a much larger concept, which I'll call no sharp edges. Chain saws are powerful -- and dangerous -- but no one puts scissor blades next to the chain saw's handle. We try to make sure that "obvious" ways of using tools are not dangerous, even if the tool itself can do dangerous things. Yet the "obvious" ways to use many languages turn out to lead directly to security vulnerabilities, and that needs to change. You can't prevent all misuse -- a chain saw can be always be misused -- but you can at least make languages easy to use correctly and likely to do only what was intended (and nothing else).

We need to design languages, and select tools and tool options, to reduce the likelihood of a developer error becoming a security vulnerability. By combining compiler warning flags (like -Wall), defaults that are likely to avoid dangerous mistakes (like -funsigned-char), NoExec stacks, and many other approaches, we can greatly reduce the likelihood of a mistake turning into a security vulnerability. The most important security measure you can take in developing secure software is to be paranoid -- and I still recommend paranoia. Still, it's hard to be perfect all the time. Currently, a vast proportion of security vulnerabilities come from relatively trivial implementation errors, ones that are easy to miss. By combining a large number of approaches, each of which counter a specific common mistake, we can get rid of a vast number of today's vulnerabilities. And getting rid of a vast number of today's vulnerabilities is a very good idea.

Countering Trusting Trust through Diverse Double-Compiling, ACSAC 2005

Mon, 12 Dec 2005 14:25 GMT

Something new: I have a section about my work to counter the "Trusting Trust" computer security attack. The "Trusting Trust" attack is a very old and incredibly nasty attack in computer security. Karger and Schell published information about this attack in 1974, and Ken Thompson (of Unix fame) made it much more widely known in 1984 in his Turing award speech "Reflections on Trusting Trust." Ken Thompson even demonstrated it; he gained complete control over another system, and that system's owners never detected the subversion. Up to now it's been presumed that the "Trusting Trust" attack is the essential uncounterable attack.

What exactly is the trusting trust attack? Basically, if an attacker can get a Trojan Horse into the binary of a compiler, at any time, you're essentially doomed. The subverted compiler can subvert itself, indefinitely into the future, as well as anything else it compiles.

I've worried about this attack for a long time, essentially since Thompson made his report. If there's a known attack that cannot be effectively countered, even in theory, should we really be using computers at all? My hope is that my work in this areas aids the computer security field writ large.

The reason I note this in my blog is that I've finally formally published my paper that describes a technique for countering this attack. The paper is Countering Trusting Trust through Diverse Double-Compiling (DDC), and it was published by ACSAC 2005. Here's a local copy, along with more info and material. Here's the abstract of that paper:

An Air Force evaluation of Multics, and Ken Thompson's famous Turing award lecture "Reflections on Trusting Trust," showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this attack goes undetected, even complete analysis of a system's source code will not find the malicious code that is running, and methods for detecting this particular attack are not widely known. This paper describes a practical technique, termed diverse double-compiling (DDC), that detects this attack and some compiler defects as well. Simply recompile the source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary. This technique has been mentioned informally, but its issues and ramifications have not been identified or discussed in a peer-reviewed work, nor has a public demonstration been made. This paper describes the technique, justifies it, describes how to overcome practical challenges, and demonstrates it.

I just got back from the ACSAC 2005 computer security conference. Several interesting papers there, on a variety of topics.

An aside: At ACSAC 2005, Aleks Kissinger (from the University of Tulsa) also presented work that he and I had done on micro-tainting. This was the presentation "Fine-Grained Taint Analysis using Regular Expressions," which was part of the Works in Progress. Basically, we noted that instead of assigning "taint" to a whole value, such as a string, you could assign taint on subcomponents, such as each character. Then you could assign rules that identified the input paths and what could come in -- typically zero or more tainted characters -- and rules on output paths. We concentrated on defining regular expressions for what is legal, though any other expression for patterns such as BNFs would be fine too. We noted that you could then check statically or dynamically. For the static case, when you work backwards, if the check "fails" you can even trivially derive the input patterns that cause security failures (and from that information it should be easy to figure out how to fix it). Aleks has recently made some good progress by transforming the regular expressions into DFAs. There was another ACSAC presentation on doing taint analysis with Java, but this was the traditional "whole variable" approach that is used in many languages, but through which many vulnerabilities slip by. We hope this micro-tainting approach will lead to improved tools for detecting security vulnerabilities in software, before that software is delivered to end-users.

Internet Explorer: So insecure, it's only safe 7 days a year?!?

Sat, 06 Aug 2005 10:25 GMT

I recently learned some amazing -- unbelievable -- shocking data. It turns out that there were only 7 days in 2004 that you could have somewhat safely used Internet Explorer (it was October 12-17), even assuming that attackers only used publicly-known attacks, and that you were only worried about the worst kind of attacks. What does that mean? Let me set the stage first... and I'll conclude what to do at the end.

In my article how to secure Microsoft Windows (for home and small business users), I give advice for people who want to keep using Windows but have some security. One piece of advice: stop using some of the most vulnerable programs, such as Internet Explorer (IE) and Outlook, and instead more secure alternatives (such as the freely-available Firefox and Thunderbird). It should be self-evident that replacing insecure programs with more secure programs will make you more secure! But let me deal with two complaints: (1) why should I change, and (2) is Internet Explorer (IE) really so much worse?

First - why should you change to using more secure software? Because if you're not willing to select a more secure program, then you are part of the problem -- you are causing everyone to have insecure programs, as well as causing your own misfortune. Why? Because vendors will not make secure products unless customers prefer them. "The marketplace" decides what's successful, and you are part of it. I'm tired of hearing "my machine is full of spyware"; if you chose to use a product that is known to have that problem, then you need accept the consequences of your choices. You can't claim ignorance at this point, the news has been circling for a long time. Sure, the attackers should be convicted. But since there are prowlers in the alleyway, please don't invite them into your house, and then act surprised when they take the silverware. Yes, you can't spend all your time on securing things, and you need to have useful (not just secure) products, but it's easy to replace these programs with perfectly good alternatives.

And second -- IE really is worse. This isn't just a random opinion, and it's not Microsoft-bashing. There is lots of evidence that, in particular, Internet Explorer has become a malware delivery system. See, for example, David Hammond's comments on Internet Explorer.

But I'm blown away by one particular study I just learned about, which shows the problem is even more serious than I thought. Scanit's Browser Security Test group "A Year of Bugs" analyzed the vulnerability reports in 2004 for three popular browsers: Microsoft's Internet Explorer, Mozilla-based browsers (including Firefox and Netscape), and Opera. Since not all vulnerabilities are equal, they only considered the especially dangerous "remote code execution" vulnerabilities, i.e., defects that allow a "malicious web page or e-mail message to execute arbitrary code or OS commands on the viewer's computer." They then compared the time from the "public announcement of the vulnerability to the time when the fix is available to the general user population." They had an incredibly simple metric: every day there's a publicly-known vulnerability, for which there is no patch available from the vendor, is an unsafe day. That's a metric anyone can understand: how many days are you vulnerable to the worst attacks that are (1) known worldwide but (2) there's nothing you can do about it?

Their results: there were only 7 days Internet Explorer was safe to use in the entire year of 2004. That means that 98% of the year, Internet Explorer was not safe to use. Is it any wonder people like me say "please don't use it?"

Let me quote their study: "there was only one period in 2004 when there were no publicly known remote code execution bugs - between the 12th and the 19th of October - 7 days in total." That means that someone who diligently kept their installation patched every day of the year (do you install the latest patches every day?) was still known to be vulnerable 98% of the time in 2004. The rediculous excuse "well, it wasn't exploitable" doesn't work, either; they found that for "200 days (that is, 54% of the time) there was a [known] worm or virus in the wild exploiting one of those unpatched vulnerabilities." And that only counts known attacks. Frankly, 2004 was a disturbing year for IE; at the beginning of the year there were two known unpatched vulnerabilities, and 2004 ended with an "unpatched HTML Help ActiveX control vulnerability and [the worm] Trojan.Phel using it to install a backdoor." And remember, this is only the publicly-known attacks, of the worst kind.

Now let's not let alternatives off the hook; Mozilla-based programs and Opera had unsafe days too. But compared to IE's "98% unsafe" value, Opera had unsafe days only 17% of the time, and the Mozilla/Firefox were only unsafe 15% of the time (and about half of that 15% only affected MacOS users). Let's look at the details:

In 2004 Opera had publicly known unpatched remote code execution vulnerabilities for 65 days (17%). It could have been worse, but two different "unpatched periods" happened to intersect, so it actually faired better by this measure than it might have otherwise.
Mozilla and the family (including Firefox, Netscape Navigator and the Camino browsers) has the shortest attack window of opportunity. There were 56 days (15%) in 2004 when there was a publicly known remote code execution vulnerability with no publicly-available patch. There was a 30 day period in May-June for an attack that only affected MacOS users, one day in July for a "shell: protocol" vulnerability (with a very rapid fix), one day in August for a libPNG vulnerability, and 24 days in October-November for problems problems found by Michal Zalewski's mangleme program. (The shell weakness in Mozilla is a weird case; it might be more accurately described as a vulnerability in the Windows operating system. Mozilla ended up creating a Windows workaround; I'm still counting it against Mozilla since sometimes applications just can't trust the operating system to "do the right thing", and the workaround is the same as Microsoft's own Internet Explorer.) Note that in several cases, the time between the report and fix was one day or less. At no time were any vulnerabilities being actively exploited.

On June 28, 2004, Microsoft’s Bill Gates told Australians that while other operating system vendors took 90-100 days to release a security patch, Microsoft had this time “down to less than 48 hours.” And Microsoft has clearly stated that IE is part of their operating system. Yet ZDNet found that Microsoft had failed to fix a critical known IE vulnerability for nearly nine months Things got so bad that in late June 2004, the U.S. Department of Homeland Security’s Computer Emergency Readiness Team (CERT) recommended using browsers other than Microsoft Corp.’s Internet Explorer (IE) for security reasons. (That's not exactly how they officially worded it... but I think many people correctly realized that that was the subtext). And even after all that, IE still had unpatched vulnerabilities for the worst kind of vulnerabilities through most of the rest of the year.

Let me throw in an aside about reporting vulnerabilities. Some companies try to convince vulnerability reporters to "keep quiet" until they fix the problem... and then just never fix it. The vulnerability is still there, though it's officially not publicly known... and if one person can find it, others will too. That head-in-the-sand approach used to be common, but our systems are just too important to allow that to continue. That's why I think it's a good idea for vulnerability reporters to give suppliers 14 days to fix the problem, with a few more days if there's a really good reason to allow unusual delays. Fourteen days should be more than enough time to fix a critical problem in the vast number of cases, but it puts the supplier on notice that leaving its customers permanently vulnerable to a known weakness is unacceptable. Certainly 30 days should be plenty for even complex problems. If your supplier can't normally turn around patches for critical fixes in 14 days or less -- and certainly by 30 days -- perhaps you need a new supplier. Gates says 48 hours is enough, half of the Mozilla problems had one-day turnaround times, and all the Mozilla problems (even the complex ones) were fixed within 30 days of a confirming report.

I will say, with relief, that Microsoft is finally going to release a new version of Internet Explorer, with some attempt at fixing the security problems. But the reports worry me. CERT's July 2, 2004, notification noted some of the major design decisions that make Internet Explorer so easy to exploit: "There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME type determination, and ActiveX." Yet everything I've read suggests that they will not fundamentally change all of these major design decisions, so at least some of their fundamental design weaknesses will probably still be there. Disabling ActiveX completely by default for all sites would be a help, for example: The "zone" model doesn't work (it's too easy to fool), a massive number of signed or pre-installed ActiveX components are vulnerable, and people just click "ok" when another ActiveX component is sent that ActiveX is a synonym for "send me malware". I really hope that IE is much more secure, but we'll see. The past does not necessarily predict the future.. but it's usually a good way to bet.

And the next version of Internet Explorer will still not support the Internet standards. This was reported by Paul Thurrott in Windows IT Pro, among others. So many standards-compliant web sites will still be inaccessible to Internet Explorer users.

But even worse... the next version of Internet Explorer is only going to go to XP Service Pack 2 users. Microsoft has various excuses for this. That's rediculous; why does everyone else, who already paid for Internet Explorer, have to suffer? Unless you pirated Windows, Internet Explorer was part of the purchase price of your machine or included in a separate license; it's actually possible you paid for Windows several times. But most Microsoft Windows users don't use XP Service Pack 2; even many XP users haven't installed Service Pack 2 because of the legion of incompatible changes and machine lockups it caused many. A vast number of people do not have Windows XP; Windows 2000 is in widespread use, and even Windows 98/ME have significant use (25% by some measures). It's not true that a secure browser requires Service Pack 2; other browser makers manage it.

Don't use the current versions of Internet Explorer normally, and wait a number of months before thinking about using the new version. In particular:

If you use Windows XP, upgrade to Service Pack 2, and upgrade Internet Explorer when the new one becomes available. But for heaven's sake, don't use the new version of Internet Explorer in normal operation until it's been proven to be relatively safe by many months of relatively safe operation. You probably shouldn't use Internet Explorer at all until it adds better standards support, too; hopefully Internet Explorer version 8 or so will do so.
If you use any version of Windows other than Windows XP, or won't use Service Pack 2, then abandon hope of ever using Internet Explorer (except to download a better browser). For those machines, there doesn't seem to be much hope that you will every be able to use Internet Explorer safely, it's been just one problem after another and the vendor will not even offer a replacement that they hope is safer.
If you use a site that requires IE, try to change to someone who accepts alternatives. If it's a company-internal site, then you could certainly consider using IE for just that site. In the meantime, continue to use an alternative (like the freely-available Firefox) for all other browsing.
If your bank or other security-critical site actually requires IE, switch to a bank that takes the security of your money and identity seriously, now, and make sure they know why. See Can You Bank on IE Security? from Bankers Online, a magazine for bankers. They say, "No longer are the major organizations suggesting that users merely download the latest patches, check their security settings, and scan their systems for viruses, this time the advice is - CHANGE TO A DIFFERENT BROWSER! And the advice is not coming from any lightweight organization with a bias. This is coming from the most respected international security watchdog organizations. [including CERT, SANS, NIPC]"
If you develop a website, make sure that it's standards-compliant so that any standards-compliant browser can view it. Internet Explorer has been losing marketshare to other web browsers (such as Mozilla Firefox) since mid-2004, so customers may start avoiding your site because they will probably increasingly not be using IE. It really makes no sense to tie your website to any browser; it's unnecessary, and creates a situation where your customers may be unable to securely use your website.

Note: I don't make any money no matter what web browser or operating system you choose. I suggest preferring advice about this topic from others who can say the same. And obviously I'm speaking only for myself, not anyone else, though it's clear that many, many others have come to the same conclusions.

E-Password comment deadline (April 4) looms - COMMENT NOW

Wed, 23 Mar 2005 17:02 GMT

As noted in a Wired article, the U.S. Department of State plans to issue U.S. passports that can be read wirelessly (remotely), and it won't even encrypt this extremely personal data. This plan is absurd; it appears to give terrorists and organized crime a way to remotely identify U.S. citizens (for murder or kidnapping) and to provide enough detailed personal information to significantly aid identity theft.

The Department of State claims that the new passports can only be read from 10 centimeters and that fibers will prevent any reading while closed. However, most security experts scoff at these claims, noting that people have to open their passports eventually, and doubting that the fiber's protection will be perfect anyway in real life. Lee Tien, an attorney at the Electronic Frontier Foundation, reports the reading distance as more like 10-30 feet. Bruce Schneier, who just renewed his passport to make sure he will not have an unencrypted passport for another 10 years, says he has yet to hear a good argument as to why the government is requiring remotely readable chips instead of a contact chip -- which could hold the same information but would not be skimmable. "A contact chip would be so much safer."

I think this Department of State plan is going to kill people. There are people in this world who want to hurt or kill Americans, or citizens of some other countries -- now we're giving them an easy tool to help them find Americans (or citizens of some other countries) in foreign countries so that they can be murdered, tortured, raped, or kidnapped for ransom. The ransom stuff alone would fund huge efforts to use this technology in foreign countries to target victims, because it'd be insanely profitable for the immoral.

In my mind, the real problem is the use of wireless technology. This is an area where the convenience of wireless is far outweighed by the disadvantages of getting murdered. Frankly, for data storage, a 2D barcode (which is MUCH cheaper) would have all the advantages of permitting quick storage of a lot of data. If the purpose of the chip is to make forgery harder, then requiring contact would be sufficient.

Is the lack of encryption a problem? Not necessarily, as long as contact is required. After all, if there's no encryption, then it's easier to see exactly what data is on the passport (e.g., to verify that it's correct for you), and the data is supposed to be the same as what's already on the passport. But it's a disaster if it's wireless, because then people who have no business getting the data will be able to retrieve it. Indeed, it's a disaster that this is wireless at all.

Those who wish to protest this plan have until April 4, 2005, to send their comments to PassportRules@state.gov. I urge you to send in emails asking State to abandon this wireless approach, and that they instead use a system that requires contact. Do it, before someone dies.