The CodeGuard Blog

Back in 2007, I heard a speaker talk about planned updates to an ISO standard.  In his presentation, he indicated that one of his colleagues had asked him to update the ISO standard to include language on “Information Assurance.”  To make a long story short, the ISO standards couldn’t accommodate an update if assurance meant “Security.”  However, too often, we find that entire federal departments say the word “Assurance” when they mean “Security.”  The Defense Department is the worst offender.

Dictionary.com says this:

1. Assurance – a positive declaration intended to give confidence.
2. Security – freedom from danger, risk, etc. 

This problem is almost as old as the Unix operating system.  Back then, some bright people in the intelligence community began using the term “assurance” because a purist engineer told them that no computer could truly be labeled “secure.”  Obviously, this happened in the days before “portable computers” or “Service Oriented Architecture,” but I digress.

Instead of saying “secure systems,” they said “assured systems” (which was a condensation of “security assured systems”) to please the theoreticians and an entire industry grew up to support this thing they call “assurance.”  It was further shortened to “information assurance” at some point in the 1990’s.

Fast forward to the 21^st Century and we find that many aspects of computing must be assured.  Safety assurance is important, as is reliability assurance.  If we travel from “The Beltway” to “The City,” we must stop saying “assurance” and start saying “security.”  If you’re starting to feel like an edge router, you’re not alone.

All of this might be entertaining, if there wasn’t a real underlying problem with the misuse of this term.  It turns out that saying security when we mean security helps us to balance risks.  If assurance only means security assurance, how can we do tradeoffs between security and safety?  Can we ever have safety assurance if every one of our software developers is looking over his or her shoulder at the security group?  Even if we could, could we teach a computer to understand the nuance?

For example, how would you interpret the following business requirement?  “The system must provide high assurance for all valve management safety processes.”  If you read ISO 15226, it means that the safety systems have to work.  If you read the SOAR report or any of the major DoD Assurance directives, it means that your safety systems should not have read up or write down.  These are two fundamentally different things.

So let’s begin reclaiming the language that our global audience understands.  When you want security – say security.

Jim Molini, CISSP, CSSLP

Dan Kaminsky was back at BlackHat this year talking about an SSL hack that would allow a web site to spoof other sites.  He shared the glory for this with Moxie Marlinspike, who also identified the same vulnerability.  The hack was an interesting attack, not against the design of SSL, but against the coding of certain SSL implementations.

The vulnerability is demonstrated by placing “\0” into a URL used to identify a subdomain.  Since some browsers translated “\0” into a single character (ASCII zero), some browsers failed to fully qualify the domain name of the site.  While looking into the problem, I originally wondered why any system would let you insert null characters into the name.  RFC 3986 says the following:

As a result, a common security concern for server implementations that handle a URI, either as a whole or split into separate components, is proper interpretation of the octet data represented by the characters and percent-encodings within that URI.

It went on to say that the ‘\’ character should be handled with care, along with things like: ‘/’, ‘.’, ‘..’, and others. That made sense.  The fact that someone strung together the characters ‘\’ and ‘0’ should not have made any difference when the URL was processed by the browser.  Although nothing should have happened, it apparently did in certain browsers.  It could have happened when the parsing algorithm passed the byte sequence off to a routine that reprocessed the characters according to standard C/C++ tokenizing rules.  This is a classic coding error that exposes an underlying vulnerability.  Your attempt to correctly implement a standard syntax is obstructed by the tools you use.  It’s also notoriously difficult to spot in any type of code review.

Now, you may ask, did this really represent a coding error or should they have specified the syntax of URLs to exclude ambiguous interpretations.  We see many crypto standards specifying rules to prevent ambiguity, should it have happened here?  Before you answer, remember that these standards must be interpreted for both English language sites and those that use alternate character sets.  I’m interested in hearing what you think.

Jim Molini, CISSP, CSSLP