So, there are a few general kinds of things that one would like to address: integer overflows, integer underflows, and the various type conversion related gotchas: signed/unsigned value changing conversions, sign-extension related flaws, and truncation. I might come up with a quick set of examples of integral vulnerabilities to help frame the discussion. One thing we observed when writing the book is that many integer-related vulnerabilities can be analyzed in terms of three components, which we denoted ACC: allocation, check, and copy (or more generally, write access). Generally, when arithmetic expressions can be manipulated such that any of these processes get subverted, or desynchronized from each other, then you end up with a situation where you can write outside of the intended memory boundaries. Naturally, not all integer related vulnerabilities can be conceptualized in this way, but it works pretty well for the mainstream case. Anyway, it would probably be helpful to sketch out a handful of insecure idioms in order to help think about how language modifications could address them. I’ll try to do this later on.

Thinking out loud, there are probably four goals that modifications to the language could aspire to:

1. Make it easy for someone concerned with integral flaws to write bulletproof code. e.g. ok, I need to take a size from a packet, do some math on it, allocated some memory, and then parse and populate my data structures. If there are some simple features or code idioms that will prevent me from shooting myself in the foot, I’ll definitely employ them.

2. Make it easy for someone to modify existing code so that it can be made safe with a minimum of effort. e.g. I have some complicated code here to read in several bitmaps and font definitions from a file, and I can tell it’s going to be vulnerable at least fifteen ways to Sunday with all the multiplications and allocations going on. Can I make a couple of changes to variable types or something equally minor that will just make it safe?

3. Make existing code safe without modification to that code. Can I set some compiler flag or pragma, or can we change C/C++ so that vulnerable code can be recompiled so that it is safe?

4. Change the language and/or make simple idioms possible that would herd developers in general towards writing secure code just by using natural constructs. In other words, make changes that non-security aware developers would want to use. Maybe something like bounds-checked arrays?

Right off the bat, I think #3 would probably be impossible, and even if it was, such changes wouldn’t ever be approved because they’d destroy more code than they would be fix. I think the set of developers that actually understand integral behavior in C is arguably vastly smaller than the set of developers that *think* they understand integral behavior in C. So, I’d argue that #1 and #2 are currently hard in C, for a coder that hasn’t written a compiler or sat down with the standards (or a good book ;>). If the modifications to the language for #1 and #2 were well-done, they might ultimately become idiomatic, realizing #4.

Anyway, enough rambling. The idea of applying saturation semantics is IMHO quite insightful, as I think it would address many types of integer vulnerabilities. Here are some thoughts:

The idea of encoding range into type is interesting, but, I do see your point about it ballooning the number of definable types in the C language very quickly. The inability to write a general purpose function sort of reminds me of that one classic article on why Pascal sucks - array sizes are part of the type, thus you can’t write a general purpose function that takes an array and a number of elements.

The way that current loop idioms would fail with ranged integers is an interesting observation. It almost seems like the use of ranged integers in this context is really shadow-implementing bounds-checked arrays. I obviously haven’t thought this through very much, but if you did have bounds checked pointers, you could use the old idioms. E.g. instead of turning a[b] into (*((a)+(b))), the compiler could apply saturation semantics to b as an offset of a. This would very much change how things probably work, but it’s another possible idea. Not sure how much it would demolish existing compilers or how much of it would be optimizable with static analysis.

Globally applying saturation semantics applied to signed integers might break existing code. Obviously existing code shouldn’t rely on implementation-defined code, but one thing that springs to mind is the TCP sequence number code. It uses an idiom like:
#define SEQ_LT(a,b) ((int)((a)-(b)) < 0)
Haven’t thought it through, but that would probably be messed up.

Having support for a _Sat keyword would probably kill a lot of exploitable issues, even if it was just bounded to the normal integral boundaries. I kinda like this, but I need to think through it more.

Liudy’s point is well taken - modifications would likely introduce new subtle semantics and gotchas. I guess it comes down to what you’re hoping to accomplish, but if the newer semantics are more deterministic and straightforward than the older ones, it might be worth doing.

Unsigned arithmetic is closed under modulus, but maybe it would be useful to have the ability to have overflow and underflow cause an implementation-defined result, including an exception. The machine support would probably be sketchy (or maybe not, most arithmetic isn’t sign-sensitive so it might just require duplicating flags checking code in the compiler). The problem with exceptions is that they are necessarily run-time and not compile-time, and the issues with intermediate results that Liudy mentioned. Definitely an interesting idea, though.

Anyway, lots to think about. I usually think about how to break things, not fix them. :>

Exception on overflow would be painful but perhaps might be justified as a way to force coders to really understand what code does under any circumstance. It’s painful because there are a number of common expressions where “the right thing” happens despite overflows in internediate results, and it would take a while for people to understand what’s OK in an exception on overflow world.