David A. Wheeler's Blog

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.

OWASP Legal Project - Secure Software Development Contract Annex

Wed, 23 Feb 2005 10:41 GMT

The Open Web Application Security Project (OWASP) Legal Project has just announced the "Secure Software Development Contract Annex". This is basically a starting point for a contract to do software development; it tries to spell out exactly what's required so that the results are secure.

I didn't develop this text, but I'm glad to see that some people are working on it. In the contracting world, if you don't specifically ask for it, you don't get it. Since most contracts today don't specifically say that a secure result is needed (and what that means), currently the person paying for the software isn't getting a secure product. Hopefully this sort of thing will solve the problem.

Personally, I think this is a "first draft"; there are things I'd like to see made more specific. For example, I think it should clearly state that in the development environment it should be possible to determine specifically, by name, who wrote any given line of code. And there are many other issues (like automated examination of code) that aren't covered. In particular, there are many more common vulnerabilities than the top ten list of OWASP. But this is a very interesting and encouraging first start, and I'm glad to see it.

New "Secure Programmer" Article on Calling Components Safely

Thu, 23 Dec 2004 21:40 GMT

The latest article in my "Secure Programmer" series is now available! This series is a developerWorks series on secure development for Linux/Unix.

Article #7 is Secure programmer: Call Components Safely. The posted date is 16 December 2004, but it's only been available since around 23 December 2004.

Here's the abstract:

Application programs typically make calls to other components, such as the underlying operating system, database systems, reusable libraries, Internet services (like DNS), Web services, and so on. This article explains how to prevent attackers from exploiting those calls to other components by discussing the use of only secure components, passing only valid data, making sure the data will be correctly interpreted, checking return values and exceptions, and protecting data as it flows between applications and components.

New paper on how to secure Microsoft Windows for home and small business users

Tue, 14 Dec 2004 13:30 GMT

As a security expert, I occasionally get asked by Microsoft Windows users questions like “I got this strange error message -- do I have spyware?” or “How do I keep my [Windows] computer secure?” Large businesses employ people who secure computer systems as a full-time job, but that doesn’t help if you’re a home or small business user. "Small business" here includes small non-profits, too.

So, I've posted on my website information on how to secure your Microsoft Windows system. It's basically a checklist of things you can do to make things better.

Get it here: Securing Microsoft Windows (for Home and Small Business Users)

Comments on Email Authentication for Countering Spam

Thu, 02 Dec 2004 17:42 GMT

The Federal Trade Commission (FTC) and National Institute of Standards and Technology (NIST) are considering their options for email authentication as a technique to partially counter spam. I recommend that they make two fundamental decisions. First, FTC and NIST should urge lawmakers to make spam illegal, so that technological measures will have legal standing. Authentication has little anti-spam value without it. Second, FTC and NIST should insist that any anti-spam technical standard must be implementable by all suppliers of email infrastructure, both proprietary and open source software.

This essay responded to a Federal Register request supporting the “Email Authentication Summit” of November 9-10, 2004. I sent the original version of this essay on September 27, 2004. Although it was publicly posted, and quoted in places such as Groklaw’s FTC Email Authentication Summit article, it had various formatting problems, a few minor grammatical mistakes, and it mentioned only NIST and not the FTC. This version is much easier to read since I converted it to HTML and had these minor problems fixed.

So, for those of you who wanted a nicer copy of this essay -- enjoy! It's here, at:
Comments on Email Authentication for Countering Spam

New Edition: Countering Spam by Using Ham Passwords (Email Passwords)

Tue, 16 Nov 2004 21:41 GMT

I've released a new version of my article, Countering Spam by Using Ham Passwords (Email Passwords). In particular, I've christened the approach with a new name: "ham passwords". I've found that ham passwords are a simple and effective technique for countering spam; I use it myself. A ham password is a special password you ask strangers, or senders in general, to include in email they send to you, typically in the subject line. If the sender wants the receiver to receive an email, then the sender should send the ham password to prove that they are authorized to send the email. This technique is excellent in countering the major weakness of spam filters: incorrectly labelling ham as spam. This approach is inexpensive, requires no changes to any software code, and is simple to understand. It especially works well when combined with other techniques that handle non-strangers.

New Security Article on Race Conditions

Fri, 08 Oct 2004 01:07 GMT

Well, I'm happy to announce that another one of my developerworks article on secure development is now out for the public. Go take a look at Secure programmer: Preventing Race Conditions.

This was a trickier article to write, because race conditions are harder to describe in a simple way. No matter what, they always involve subtle timing interactions, and that makes them hard to describe. Even the conventional definitions are too complicated and don't really help explain the issue. So, I ended up writing my own definition: A "race condition" occurs when a program doesn't work as it's supposed to because of an unexpected ordering of events that produces contention over the same resource. Notice that a race condition doesn't need to involve contention between two parts of the same program; many security problems occur if an outside attacker can interfere with a program in unexpected ways.

And from there, it shows some of those big surprises. A whole bunch of race conditions have been found over the last few months, so this is certainly still a serious problem.

Flawfinder version 1.26 released!

Tue, 15 Jun 2004 20:34 GMT

I've released yet another new version of flawfinder - now it's version 1.26. Flawfinder is a simple program that examines C/C++ source code and reports on likely security flaws in the program, ranked by risk level. When I announced flawfinder version 1.25, people responded with a flurry of useful improvements, so I thought I'd incorporate those right away for all to enjoy.

You can view the Flawfinder ChangeLog for the details. Here are some of the highlights:

Added code to better support Microsoft's approach to internationalization, based in large part on work by Jared Robinson (thanks!!). This adds many more functions: _getts(), vswprintf(), _stprintf(), _vstprintf(), vwprintf(), vfwprintf(), _vtprintf(), _ftprintf(), _vftprintf(), _sntprintf(), _vsntprintf(), _ftscanf(), and _gettc(). The macros _T() and _TEXT() are treated like gettext(), to eliminate spurious warnings.
Added two new rules for GLib functions, "g_get_home_dir" and "g_get_tmp_dir", per a suggestion by Steve Kemp. This closes the wishlist item in Debian bug report #250432. Contributors - please email wishlist items to me; I can't monitor every distribution's local bug tracking system. PLEASE tell upstream developers when there's a bug/wishlist item, we can't fix it if we don't know.
I added rules, e.g., for curl_getenv() (another getenv-like function), as well as more rules for input functions: recv, recvfrom, recvmsg, fread, and readv.
I tightened the false positive test slightly; if a name is followed by = or - or + it's unlikely to be a function call, so it'll be quietly discarded.
I modified the summary report format slightly, to make it nicer.
I modified the getpass text to remove an extraneous character, thanks to a bug report from Joerg Beyer (thanks!).
I modified the installation instructions to clarify how to set INSTALL_DIR at run-time so it installs elsewhere. Flawfinder uses the standard GNU conventions, but not everyone knows about them. By default, flawfinder installs in /usr/local. Just use normal make overrides to change that, e.g., make INSTALL_DIR=/usr INSTALL_DIR_MAN=/usr/share/man install I do NOT use the ?= macro-setting commands in the makefile, because that's not standard (e.g., it's not in SUSv3), so while that would work in GNU make, it wouldn't work in others. I did this to answer some questions about installation - the flexibility has always been there, but now it's documented in a clearer way.

NOTE: Due to an error on my part, the tar file for version 1.25 on my website was for a short period (between 2004-06-05 and 2004-06-15) actually a functional equivalent of version 1.26 (without some stuff that only affects me), incorrectly labelled as 1.25. This wasn't true for the RPM packages (the 1.25s stayed as 1.25), so suspicious people could look inside the RPM packages to see if the tar file within was correct. In some sense this wasn't a serious problem - tar users got the latest version of flawfinder a little sooner than I intended. But I really want version numbers to mean what they say, and I know others do too; for those folks, my sincere apologies!! Please upgrade to 1.26, since that way you'll be SURE to get the right version. If you want to check, here are the md5sum's of various correct files:

dcdd0a7a5b9dc8d0ffc85c1a5833bc43  flawfinder-1.25-1.noarch.rpm
744f0cc317c583de6d295860db3c7cbe  flawfinder-1.25-1.src.rpm
fa5b644e00aa4862de5b790f0e1a3ad7  flawfinder-1.25.tar.gz (the real 1.25)
530b11016c52d473ebb7bc9639d4338b  flawfinder-1.26-1.noarch.rpm
cbc61513620bc7b17bcc29f8eb50fb9f  flawfinder-1.26-1.src.rpm
242a90ecf2f21a709a2425c8771ef38e  flawfinder-1.26.tar.gz

Here's the md5sum of the file that was briefly labelled as flawfinder-1.25.tar.gz, but was actually a functional equivalent of 1.26:

e1fa5fcb540b91d27c3ae427595a182e  flawfinder-1.25.tar.gz-actually1.26

Just go to the flawfinder home page to get the latest version.