Secure Coding Secrets?

A recent article titled “NSA posts secrets to writing secure code” caught my eye in part because the words “writing secure code” always get my attention! But also because anything that can advance the science of securing software is of interest to me.

There is another reason why the article got my attention; my manager, Steve Lipner, is one of the few people to have designed and built a TCSEC A1 assured system and lived to tell the tale. None were sold, but they built one!

The NSA-directed project, the Tokeneer ID Station (TIS), involved building a low-defect system that conforms “to the Common Criteria requirements for Evaluation Assurance Level 5 (EAL5)” in a “cost effective manner.” I’m all for this, because building high-assurance solutions is not cheap.

There’s a paper with more technical detail about the project that is worth a read.

In my opinion, the project is only a science project, an experiment, for the following reasons:

  • It’s tiny. Weighing in at a little under 10 KLOC.
  • It’s only a very small portion of a much larger solution which has not been developed using the same rigor. This bit of context makes the solution as a whole moot. Call me cynical, but my question is “can the entire solution be built with same rigor in a ‘cost effective manner’?” Perhaps it can, but that is not what is presented.
  • It sits on top of many operating systems (Windows, Mac OS X and Linux) that are not EAL5 certified. So it would be a little like having an EAL5 certified CharMap application running on EAL4 Windows Vista.
  • It’s written in a subset of Ada called SPARK, and SPARK skills are not common in the marketplace. Interestingly, SPARK makes use of annotations to help drive the static analysis process. While not a total analog, we also recommend Microsoft development teams use annotations (SAL) to help drive the required static analysis process.
  • The application has a large number of dependencies that are not part of the project:

 

Directory of C:tokeneerdata

18/08/2007 08:51 605,333     libgdk-win32-2.0-0.dll
18/08/2007 08:51 166,177     libgdk_pixbuf-2.0-0.dll
17/08/2007 18:07 642,115     libglib-2.0-0.dll
17/08/2007 18:07 28,853      libgmodule-2.0-0.dll
17/08/2007 18:07 223,026     libgobject-2.0-0.dll
18/08/2007 08:52 3,170,609   libgtk-win32-2.0-0.dll
08/08/2008 16:32 4,868,618   libgtkada-2.10.dll
07/04/2004 11:47 44,100      libintl-1.dll
17/08/2007 18:29 522,940     libcairo-2.dll
17/08/2007 18:36 262,784     libpango-1.0-0.dll
17/08/2007 18:36 62,334      libpangocairo-1.0-0.dll
17/08/2007 18:37 88,626      libpangowin32-1.0-0.dll
07/10/2001 01:52 171,008     libpng-3.dll
07/04/2004 11:46 58,077      libz.dll
07/04/2004 11:47 843,776     iconv.dll
17/08/2007 18:22 142,762     libatk-1.0-0.dll
16/01/2007 12:27 131,784     libjpeg6b.dll

 

In the SDL we call these files ‘giblets’ because they are components needed for your application to operate, but they do not belong to your team. Some of the files look old and highly vulnerable, such as libpng-3.dll from 2001! OSVDB lists 23 vulnerabilities since 2002 in libpng!

In summary, the TIS project is very interesting to a small number of important but specialized customers, such as the NSA, for whom this kind of research is critical. I too found it interesting, but the process is far from a set of “secrets to writing secure code” and the tools are certainly not within reach of day-to-day applications and not applicable to developing complete solutions.

As usual, all comments are very welcome.

About the Author
Michael Howard

Principal Security Program Manager

Michael Howard is a principal security program manager on the Trustworthy Computing (TwC) Security team at Microsoft, where he is responsible for managing secure design, programming, and testing techniques across the company. Michael is an architect of the Security Development Read more »

Join the conversation

3 comments
  1. asteingruebl

    Michael,

    The premise behind the programming paradigms and languages espoused by the Praxis folks (SPARK, Correctness by Construction) is that to achieve the assurance required for certain classes of applications (Flight control systems, automated train controls, etc) only these techniques will work.

    I think we continue to delude ourselves that our current programming practices are going to get us where we need to go from an assurance standpoint.  

    None of this of course excuses all of the dependencies this component has on weak elements of the overall system. You’re obviously spot on there.

    Imagine you were strictly liable for all security defects in Windows, and it was a different economic equation than it is today.  What elements of the SDL and software development at Microsoft do you think you’d need to change to get to that higher assurance?

  2. sdl

    the background of SPARK is clearly for building high assurance solutions for military etc etc, but the article declares that this can all work for classic COTS stuff which is often way more complex and general purpose. So that’s why I wrote the article, I don’t think it can be done because the demonstration didn’t show it can be done. call me cynical :)

Comments are closed.