Re: [Lit.] Buffer overruns

From: David Wagner (daw_at_taverner.cs.berkeley.edu)
Date: 01/18/05

  • Next message: Nick Maclaren: "Re: [Lit.] Buffer overruns"
    Date: Tue, 18 Jan 2005 18:32:24 +0000 (UTC)
    
    

    D. J. Bernstein wrote:
    >Unfortunately, in most cases, the necessary access is also enough access
    >that the program can do quite a lot of damage.

    I don't know about "most". Certainly there are cases like this.
    They are not uncommon. But, I also contend they are rarer than when
    you do nothing.

    >A classic example is the Janus confinement of Netscape's ``DNS
    >helper''; it turned out that there was a buffer overflow in libresolv,
    >and therefore a security hole in the DNS helper, _despite_ the sandbox.

    I'm not familiar with this example. Can you say just a bit more?
    How do you confine Netscape's DNS helper? (I don't think I remember
    trying to confine Netscape's DNS helper process, though I do remember
    thinking about applying a DNS proxy taken a application firewall.)
    What was the impact of the vulnerability?

    >A much better approach is what one might flippantly call ``the principle
    >of _no_ privilege.''

    Certainly. "No privilege" is even safer than "a few privileges",
    when it is applicable. But this is just a special instance of least
    privilege; we have an application that doesn't require any privileges,
    and so we don't give it any. Granted, it is an important special
    instance.

    >What about a complicated program with many input sources that aren't
    >authorized to have complete control over the output---for example, a web
    >browser? This program doesn't fit into an extreme sandbox. Should we be
    >satisfied with ``least privilege''? No! The program should be split into
    >separate programs so that as many lines of code as possible can be put
    >into extreme sandboxes, leaving only a small kernel of privileged code.
    >For example, the browser should create an extreme sandbox for each JPEG
    >to be decompressed. The benefit is that further JPEG decompression bugs
    >no longer have any impact on security.

    Absolutely. I agree 100%. Decomposition for security, where you
    decompose the system into components whose privilege is minimized and
    where the size of the TCB is minimized -- plus some mechanism for
    enforcing least privilege and isolation constraints on every component.
    A much better approach to software design than "it runs with all the
    privileges of the user who executes it".

    You said "split into separate programs". That is one way to split
    it into components and enforce isolation and least privilege. But
    it is not the only way. Another way is to use a language with support
    for least privilege.

    A key point here is that the application is designed from the start
    with security in mind. If you can choose the structure your system
    in a way that maximizes security, you can do a heckuva lot better than
    if you're stuck with the structure of some legacy application. If you
    can change how developers build systems, you can get a lot more leverage
    than if you're trying to clean up their messes after the fact.

    Out of curiousity, have you looked at the E language?
     http://www.hpl.hp.com/techreports/2003/HPL-2003-222.html
     http://www.skyhunter.com/marcs/ewalnut.html


  • Next message: Nick Maclaren: "Re: [Lit.] Buffer overruns"

    Relevant Pages

    • Re: [Lit.] Buffer overruns
      ... >Unfortunately, in most cases, the necessary access is also enough access ... privilege; we have an application that doesn't require any privileges, ... The benefit is that further JPEG decompression bugs ... >no longer have any impact on security. ...
      (sci.crypt)
    • Re: ASP.NET Impersonation / delegation
      ... If your security guys will not even allow delegation, ... Bruce - I think this is a major right to grant to the ASPNet account. ... I have included a description on SE_TCB_NAME privilege from one of the MS ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: Event ID 577 & Failed Install of Microsoft Firewall Client
      ... NT Local Security Authority / Authentication Service ... Primary Domain: <domain or workgroup name> ... Client Domain: ... privilege to perform a privileged system service. ...
      (microsoft.public.security)
    • Re: Event ID 577 & Failed Install of Microsoft Firewall Client
      ... NT Local Security Authority / Authentication Service ... Primary Domain: <domain or workgroup name> ... Client Domain: ... privilege to perform a privileged system service. ...
      (microsoft.public.win2000.security)
    • RE: Desktop Support Access
      ... Level 1 is the default user EXEC privilege, ... Subject: Desktop Support Access ... Better Management for Network Security ...
      (Security-Basics)