Re: Thou shalt have no other gods before the ANSI C standard

From: David Wagner (daw_at_taverner.cs.berkeley.edu)
Date: 02/24/05 

Date: Thu, 24 Feb 2005 22:46:59 +0000 (UTC)

Trevor L. Jackson, III wrote:
>We need to distinguish reads from writes. I'm assuming you are
>interested in errant writes rather than errant reads. Are you aware of
>any exploits based upon errant buffer reads?

Nothing really significant. I know of a few examples of exploits based
upon errant reads, but they were were "information disclosure" or "crash
the machine" vulnerabilities, rather than something that immediately
leads to the ability to take control of the machine. However, if your
application isn't handling any important secrets, errant reads seem like
a pretty low-priority item, I would think -- it seems to be pretty rare
to encounter a buffer overrun that leads to some kind of serious information
disclosure vulnerability but does not allow attackers to take control of
the application.

>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.

I take it this is another way of describing 2-version programming,
except done at a fine granularity, and with more detailed checking of the
results of the computation? I think I understand what you are suggesting.
Thanks.

>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.

That makes sense. I believe it.

>The real reason for my confidence is that there was a very dramatic
>errant write problem several years after the initial release. [...]
>[...] as part of that effort I had to inventory every single
>write that was indirect or indexed.

Wow, that sounds like a major effort. Ok, now I think I understand
why you are pretty confident there were no buffer overruns. Sounds like
this could do the trick, indeed.

>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?

I'm not sure we know what would be "good enough". How could we tell?
The only way I know to tell is to do a controlled experiment and measure.
Until we can articulate some process, try that process out, and measure
its effectiveness, I don't think we will be able to tell for sure
whether that process will be adequate -- i.e., whether we will be able to
(justifiably) count on that process to eliminate all buffer overruns.
I have yet to see such evidence provided for any process currently known.

>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?

It is necessary that there be no buffer overruns, if we want to know
that there are no security holes. How could software be shipped under
that constraint? One way is to use a memory-safe language.

Another way is to ship the software without knowing whether it is secure.
This latter method seems to be very widely used. :-(

>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.

That could well be. Sounds like a very credible hypothesis to me.

>> Any? No, not all buffer overruns can be exploited to take control of
>> the machine.
>
>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?

I don't trust myself to be able to reliably distinguish a non-exploitable
buffer overrun from an exploitable buffer overrun. Often I can make
a pretty good guess, but I've also been wrong too many times. I don't
like taking that kind of risk. Given that, I think we're pretty much
forced to say that any time you find a buffer overrun, you should treat
it as a defect and fix it, even if you can't immediately identify any
way to exploit it.

A buffer overrun is an example where the program is doing something wrong
and something that "violates the model". Putting an upper bound on exactly
how much harm can be caused by that wrong is often hard to do, particularly
since you cannot reason within the model (you can't assume, for instance,
that "int x = 0; f(); return x;" returns 0).

>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.

One of the characteristics that tends to make a buffer overrun exploitable
is the ability to overwrite key portions of the address space: data
structures that were only supposed to be maintained by the compiler
(e.g., the return address or frame pointer on the stack, vtables in C++)
or linker (e.g., the GOT) or libraries (e.g., private data structures
maintained by malloc, such as the free list), data that the program relies
upon for correct execution (e.g., function pointers, the place where
the OS stores your uid, data that will later be used as an argument to
a system call), and so on. It is hard to come up with an exhaustive list.

Also, you can see that determining the impact of a buffer overrun can
depend on how the compiler, linker, memory allocator, libraries, OS,
etc. lay out memory in your program, and that can depend heavily on
the platform, how the program is compiled, how it is used, etc.

> even with knowedge
>of the distinction the default assumption should be that any bug may
>_become_ exploitable as time passes and code rots.

Also true, and a very good point.

>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).

I think there were a few in the Linux kernel; several of the user/kernel
pointer bugs (based on insufficient input validation) had this flavor.
This is the first to come to mind.

Also, most format string vulnerabilities can be exploited by the attacker
to read any location in memory, so all you'd need to do is pick any program
that processes a secret and that had a format string vulnerability.
Of course, if your program has a format string vulnerability, you're in
bigger trouble, because that usually means that an attacker can take control
of your program, so maybe there is no point in focusing on information
disclosure in such a setting.

By the way, thank you for your very detailed and enlightening response.

Relevant Pages

  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >>interested in errant writes rather than errant reads. ... > leads to the ability to take control of the machine. ... >>problems in order to know that there are no security holes? ... > buffer overrun from an exploitable buffer overrun. ...
    (sci.crypt)
  • Re: Language Features Id Like To See
    ... > '\0' to control the while loop. ... prior to the end of the buffer*. ... Can you say "buffer overrun"? ...
    (borland.public.delphi.non-technical)
  • Re: VFP8 Intellisense issue
    ... I would suspect that VFP crashes when evaluating the properties and methods ... and this list is control specific. ... > noticed a problem when testing this ActiveX control in Visual FoxPro 8 and ... > A buffer overrun has been detected which has corrupted the programs' ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Baud Rate In Serial Comm, Buffer overrun
    ... We are having software flow control in our protocol. ... > cause buffer overrun? ... No. That's the whole point of flow control - to prevent overruns. ...
    (microsoft.public.dotnet.framework.compactframework)
Quantcast