Thou shalt have no other gods before the ANSI C standard 1597

David Wagner

Sory it was quite proprietry. I'm certin it is no longer in use. Not sure where to look to find it.

The language was C. The only non-standard aspect was a comercial mulit-tasking subsystem (buttembler).

RAM, no hard drive.

Things I (re)learned from that experience:

1. Hire the best software engineers you can find. Look harder. If you have to pay 2-3x times the going wage to get them you are getting a bargain.

2. Tell them what you want as carefully and completely as possible. In this instance the reliability and security requirements were given high priority from the start.

3. Stay out of the way. Which means don't change the specs in mid-stream, instead wait until you have what you originally asked for before you change your mind. This probably had the greatest impact on reliability and security.

The reason those changes have to be prohibited is partly due to the skew that occurs as the change traverses the existing specs-design-code-qualifications. The other reason is that changes make it effectively impossible to manage the project beyond signing checks and hoping for the best. The destructive effect of late changes cannot be overemphasized.

4. Develop the threat model prior to defining the feature set. This is necessary because the threat model is usually invariant (as it was in this case), but features can be traded off against schedule, cost, and quality. And features need to conform to the threat model rather than the other way around (I like want to talk about that, but it is important.)

5. Use articulate external qualifiers. (Clbuttically testing is everything that happens to the software after the it appears to be functional and before it is realeased to non-testers. It gets the name from the waterfall phase rather than from the low-level activity. But since you have restricted the term testing to mean running code, we need a new term. I am using qualification to mean everything that happens to the software in the phases that is clbuttically called "testing". The people involved are qualifiers.

Those people have to be able to communicate about software even better than the developers themselves. It helps if they are app-domain experts as well. This is a specialization of #1, but it is worth the mention because "best" sometimes does not mean articulate.

6. Attack the components not the overall "system". The system doesn;t break. Components certainly do.

We need to distinguish reads from writes. I'm buttuming you are interested in errant writes rather than errant reads. Are you aware of any exploits based upon errant buffer reads?

Given the complexity of the incoming data parser I have no delisions that it never wandered. It wandered a lot and probably did even in the fielded systems.

In the front-end project there were several errante write problems that existed until they were detected and corrected. The claim is that I believe there were no such problems (excepting the compiler optimization bug) in the versions that made it to the field. So even in the situation with extremely careful development, some problems are going to occur. Expect them. Prepare for them. Find them. Fix them.

Most C coders are familar with NDEBUG because it is the basis of buttert(). There's a similar idiom, NCHECK, that can be used to control the compilation of parallel implementations, one for production (speed, size, etc) and one for correctness (big & slow). The NCHECK symbol is most useful when it controls not only comparison of the results, but also comparison of the process. NCHECK is not part of the C standard, but I certainly wish it were.

For example, moving data around is checked by not only verifying that the destination receives the same contents form both of the parallel implementations, but also that adjacent areas were not affected. More importantly checking should verify the side effects and measurable aspects of the movement process. For example, a block move has a beginning, end, and item count that should all match between the two implementations.

As I write this I recognize that the above sounds so trivial as to be ridiculous. But I was astonished at how often NULL-checking pointer arguments that could not possibly (in theory) be NULL actually detected violations. Similarly, having the count or end address not match was unreasonably frequent. I found that the obsessive attention to what appear to be trivial details often illuminated colliding boundary conditions (AKA corner cases) that escaped the attention of the developers. It was not the case that they were not paying attention to the boundaries. I surmised that one or more boundaries were occupying their attention and an extra boundary got by them.

One of the other aspect of that develoment effort was an goal of emilinating data movement. I.e., movement costs time and soace and complexity. ALl of which are bad for reiability. So a lot of effort was spent eliminating unnecssary copy-moves, and that effort had the beneficial side effect of causing the copy-move code to get a lot of attention during design, implementation, and qualification -- more attentioan that it would have gotten in a more natural environment. many real-time-embedded projects benefot from this synergy.

The real reason for my confidence is that there was a very dramatic errant write problem several years after the initial release. It manifested itself as trashed BSS variables and occasionally trashed heap entries.

I don't remember whether there were any trashed stacks. I suspect not because the multi-tasker had to manage all of the stacks for the separate threads, so there was a great deal of emphsis on keeping the stack usage down. The threads were dedicated. I think they each ran with a 256-byte margin over the historically largest usage recorded.

So given the certainty that something was stomping on memory I was partly responsible for finding the culprit. I worked with a guy who learned COBOL by studying hex ABEND dumps. He actually diagnosed the problem. But as part of that effort I had to inventory every single write that was indirect or indexed.

It was not the case that I had to find the bug. It was the case that I was supposed to find all the places that could be causing the bug on an occasional basis. See Deety's rule re searching.

The inventory process took some time. That detailed search produced no errant-write candidates, and is the basis for my confidence that were were none.

Eventually we were able to localize the memory that was being corrupted. But the problem did not manifest itself in the debugger, because it disabled optimizations. Only when my buttociate forced me to single step the optimized code were we able to find the function that was doing the writing and then deduce from the binary that it was a register management bug.

What do you mean "we" white man? ;-)

Of course in the impersonal sense you are correct. But I'd like to hear your description of what "good enough" would be. Can you articulate a criteria than can be applied at the project level to determine whether hat project is good enough or not?

OK, but it is necessary to know that there are no memory management problems in order to know that there are no security holes? How could any software ever be shipped under that constraint?

I disagree. While many people have underestimated or even deprecated the attackers, I suspect that most people just didn't care. That's why point #2 above is the second most important point. If you want securiry and reliability you have to say so. And you have to say so early. And you have to not flinch when you get the estimate of the time and money it will really cost. See any good book on software estimates being ignored, e.g., Glbutt's facts & fallacies.

IMO, underestimating the attackers is not the current problem. Not caring is. Not caring may be caused by underestimation, but I don't believe that is the true causation of the bad atbreastude.

OK, I lack the experience to be able to tell the difference. From your endorsement of the total elimination policy I infer that you, with substantially more experience, may not be able to describe the difference either. Is that inference accurate?

If not, please elaborate on the characteristics that make bugs exploitable. I ask because those characteristics may make exploitable bugs easier to catch than all bugs in general.

Absent knowedge of the distinction, of course. And even with knowedge of the distinction the default buttumption should be that any bug may become exploitable as time pbuttes and code rots.

At the risk of repeating myself I'll ask again: can you remember any based on errant reads? I cna theorize about it, but have never seen it in practice. I'd like an example (to use as a sledge to open some minds I've been unable to open with theory).

That is true of all complex endeavors. Murhpy is the name we give to the emergent behavior that afflicts complex human efforts. Murphy is real. And hs is out to get you. ;-)

tj3