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.
path: /security | Current Weblog | permanent link to this entry
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:
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.
path: /security | Current Weblog | permanent link to this entry
Oracle letter to Universities: Educate software developers on security/assurance!
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.
path: /security | Current Weblog | permanent link to this entry
Securing Open Source Software (OSS)
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!
path: /security | Current Weblog | permanent link to this entry
Twisted Mind of the Security Pro
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.
path: /security | Current Weblog | permanent link to this entry
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.
path: /security | Current Weblog | permanent link to this entry
Audio for "Open Standards and Security" online
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.
path: /security | Current Weblog | permanent link to this entry
Internet Explorer 7: Still a security problem, keep using Firefox
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.
path: /security | Current Weblog | permanent link to this entry
Flawfinder version 1.27 released!
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!
path: /security | Current Weblog | permanent link to this entry
DRM Nonsense, HD DVD, AACS, and BackupHDDVD - why "content protection" doesn't
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.
path: /security | Current Weblog | permanent link to this entry
Direct Recording Electronic (DRE) Voting: Why Your Vote Doesn't Matter
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.
path: /security | Current Weblog | permanent link to this entry
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.
path: /security | Current Weblog | permanent link to this entry
Unsigned characters: The cheapest secure programming measure?
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.
path: /security | Current Weblog | permanent link to this entry
Countering Trusting Trust through Diverse Double-Compiling, ACSAC 2005
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.
path: /security | Current Weblog | permanent link to this entry
Internet Explorer: So insecure, it's only safe 7 days a year?!?
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:
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:
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.
path: /security | Current Weblog | permanent link to this entry
E-Password comment deadline (April 4) looms - COMMENT NOW
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.
path: /security | Current Weblog | permanent link to this entry
OWASP Legal Project - Secure Software Development Contract Annex
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.
path: /security | Current Weblog | permanent link to this entry
New "Secure Programmer" Article on Calling Components Safely
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.
path: /security | Current Weblog | permanent link to this entry
New paper on how to secure Microsoft Windows for home and small business users
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)
path: /security | Current Weblog | permanent link to this entry
Comments on Email Authentication for Countering Spam
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
path: /security | Current Weblog | permanent link to this entry