[security] window of vulnerability

Discussion in 'Java' started by mei, Feb 27, 2007.

  1. mei

    mei Guest

    Hello,
    I heard several times people talking about a security issue known as
    window of vulnerability.
    I am not sure to be capable of explaining it correctly, but it is more
    or less about having a concurrent thread accessing a code normally
    protected, that would trigger within a window of vulnerability
    eventually opened by the thread running the protection mechanism.
    I would like to know if it is only a theoretical problem or if it can
    happen on real conditions? In my mind, I think that we should be able to
    enforce the executions in a particular order, and this depends on too
    many parameters to be controlled.
    Mei.
     
    mei, Feb 27, 2007
    #1
    1. Advertising

  2. mei

    Daniel Pitts Guest

    Re: window of vulnerability

    On Feb 27, 1:23 pm, mei <> wrote:
    > Hello,
    > I heard several times people talking about a security issue known as
    > window of vulnerability.
    > I am not sure to be capable of explaining it correctly, but it is more
    > or less about having a concurrent thread accessing a code normally
    > protected, that would trigger within a window of vulnerability
    > eventually opened by the thread running the protection mechanism.
    > I would like to know if it is only a theoretical problem or if it can
    > happen on real conditions? In my mind, I think that we should be able to
    > enforce the executions in a particular order, and this depends on too
    > many parameters to be controlled.
    > Mei.


    Thats just it, you *can* force order, but in a multi-threaded
    environment, you have to worry about the order to force.

    In a single threaded application, everything "seems" to happen in the
    order you expect, the implicit order you asked for, the compiler, JVM,
    and underlying CPU are designed to do this for you. However, they may
    "reorder" certain instructions that don't interact with each other.
    This gives them the ability to optimize pipelines, wait times, etc...
    The effect is unobservable to a single threaded application.

    However, there is no implicit order defined between two threads. You
    have to be explicit by using some sort of synchronization. In Java,
    that means using either synchronization and volatile variables, or
    using the new in java.util.concurrency classes. More than just using
    them, you have to use them correctly.

    I recently picked up a copy of "Java Concurrency in Practice" <http://
    jcip.net/> which discusses the pitfalls of using multi-threaded
    applications without understanding the underlying behavior.

    Hope this helps,
    Daniel.
     
    Daniel Pitts, Feb 27, 2007
    #2
    1. Advertising

  3. mei

    mei Guest

    Re: window of vulnerability

    Daniel Pitts a écrit :
    > On Feb 27, 1:23 pm, mei <> wrote:
    >> Hello,
    >> I heard several times people talking about a security issue known as
    >> window of vulnerability.
    >> I am not sure to be capable of explaining it correctly, but it is more
    >> or less about having a concurrent thread accessing a code normally
    >> protected, that would trigger within a window of vulnerability
    >> eventually opened by the thread running the protection mechanism.
    >> I would like to know if it is only a theoretical problem or if it can
    >> happen on real conditions? In my mind, I think that we should be able to
    >> enforce the executions in a particular order, and this depends on too
    >> many parameters to be controlled.
    >> Mei.

    >
    > Thats just it, you *can* force order, but in a multi-threaded
    > environment, you have to worry about the order to force.
    >
    > In a single threaded application, everything "seems" to happen in the
    > order you expect, the implicit order you asked for, the compiler, JVM,
    > and underlying CPU are designed to do this for you. However, they may
    > "reorder" certain instructions that don't interact with each other.
    > This gives them the ability to optimize pipelines, wait times, etc...
    > The effect is unobservable to a single threaded application.
    >
    > However, there is no implicit order defined between two threads. You
    > have to be explicit by using some sort of synchronization. In Java,
    > that means using either synchronization and volatile variables, or
    > using the new in java.util.concurrency classes. More than just using
    > them, you have to use them correctly.
    >
    > I recently picked up a copy of "Java Concurrency in Practice" <http://
    > jcip.net/> which discusses the pitfalls of using multi-threaded
    > applications without understanding the underlying behavior.
    >
    > Hope this helps,
    > Daniel.
    >


    Thank you Daniel for your answer. I know that execution order can be
    controlled using synchronization. However, my question is more oriented
    toward a security issue. Would it be possible to "attack" a third-party
    class (whose code wouldn't be modifiable) by running a concurrent thread
    that would exploit a window of vulnerability?
    More precisely, let's say we have a class for which we can't change its
    synchronization design, but for which we still make the assumption it
    exhibits a window of vulnerability. In this case, could someone give me
    a simple example (or a pointer to) of such a class and how a thread
    could attack it.
    I hope I'm clear enough...
     
    mei, Feb 27, 2007
    #3
  4. mei

    Daniel Pitts Guest

    Re: window of vulnerability

    On Feb 27, 2:11 pm, mei <> wrote:
    > Daniel Pitts a écrit :
    >
    >
    >
    > > On Feb 27, 1:23 pm, mei <> wrote:
    > >> Hello,
    > >> I heard several times people talking about a security issue known as
    > >> window of vulnerability.
    > >> I am not sure to be capable of explaining it correctly, but it is more
    > >> or less about having a concurrent thread accessing a code normally
    > >> protected, that would trigger within a window of vulnerability
    > >> eventually opened by the thread running the protection mechanism.
    > >> I would like to know if it is only a theoretical problem or if it can
    > >> happen on real conditions? In my mind, I think that we should be able to
    > >> enforce the executions in a particular order, and this depends on too
    > >> many parameters to be controlled.
    > >> Mei.

    >
    > > Thats just it, you *can* force order, but in a multi-threaded
    > > environment, you have to worry about the order to force.

    >
    > > In a single threaded application, everything "seems" to happen in the
    > > order you expect, the implicit order you asked for, the compiler, JVM,
    > > and underlying CPU are designed to do this for you. However, they may
    > > "reorder" certain instructions that don't interact with each other.
    > > This gives them the ability to optimize pipelines, wait times, etc...
    > > The effect is unobservable to a single threaded application.

    >
    > > However, there is no implicit order defined between two threads. You
    > > have to be explicit by using some sort of synchronization. In Java,
    > > that means using either synchronization and volatile variables, or
    > > using the new in java.util.concurrency classes. More than just using
    > > them, you have to use them correctly.

    >
    > > I recently picked up a copy of "Java Concurrency in Practice" <http://
    > > jcip.net/> which discusses the pitfalls of using multi-threaded
    > > applications without understanding the underlying behavior.

    >
    > > Hope this helps,
    > > Daniel.

    >
    > Thank you Daniel for your answer. I know that execution order can be
    > controlled using synchronization. However, my question is more oriented
    > toward a security issue. Would it be possible to "attack" a third-party
    > class (whose code wouldn't be modifiable) by running a concurrent thread
    > that would exploit a window of vulnerability?
    > More precisely, let's say we have a class for which we can't change its
    > synchronization design, but for which we still make the assumption it
    > exhibits a window of vulnerability. In this case, could someone give me
    > a simple example (or a pointer to) of such a class and how a thread
    > could attack it.
    > I hope I'm clear enough...


    I'm not sure, but I wonder if calling
    thread.stop(new Error() {
    public void printStackTrace() {
    // this code MIGHT be run in a privileged context.
    }
    });
     
    Daniel Pitts, Feb 28, 2007
    #4
  5. mei

    Chris Uppal Guest

    Re: window of vulnerability

    mei wrote:

    > Would it be possible to "attack" a third-party
    > class (whose code wouldn't be modifiable) by running a concurrent thread
    > that would exploit a window of vulnerability?


    If it was possible then that would be because of a bug in the third-party
    class. Java provides all the tools you need to ensure that you don't leave any
    thread-related holes (either for security or just for safety). But that
    doesn't mean that all classes /will/ be safe -- anyone can write buggy code,
    and multi-threaded code is notoriously difficult to get right.

    But there is also a wider sense in which malicious code could exploit a "window
    of opportunity", not specifically about threading issues (and not specific to
    Java either), if the application isn't carefully designed. There are all sorts
    of possibilities there, but each one is about finding some loophole in the
    application design. One large category of attacks focus on temporary files
    which some applications use to pass information between programs. If the
    designer isn't careful, then there may be a chance for someone else to
    substitute their own data. You can check Google for
    "temporary file vulnerability"
    Note that very few or none of the hits mention Java, although the same problems
    /could/ occur in Java.

    -- chris
     
    Chris Uppal, Feb 28, 2007
    #5
  6. mei

    mei Guest

    Re: window of vulnerability

    Chris Uppal a écrit :
    > If it was possible then that would be because of a bug in the third-party
    > class.


    That's why I wrote "we still make the assumption it exhibits a window of
    vulnerability" ;)
    Well, to make my question more concrete, I managed to find a reference
    about this kind of problem that was evoked recently on this forum.
    Let me quote Mark Thornton:
    "You can only pass String to security critical methods. If String was
    mutable or not final then untrusted code could breach security by
    passing a value that was permitted (and thus passed any check) and then,
    while the method was still in progress, modify the value (from another
    thread) to refer to a resource that should have restricted access.
    Obviously this approach depends on timing --- the change has to take
    place after the value has been checked but before it is used."

    So let's assume a class exhibits the design flaw to take a mutable
    string as a parameter. Thinking over it, I was wondering how we can make
    sure (reasonably) that the thread has a chance to be executed during the
    window of vulnerability? Is that a theoretical risk or not?
    Mei
     
    mei, Mar 1, 2007
    #6
  7. mei

    Daniel Pitts Guest

    Re: window of vulnerability

    On Mar 1, 12:34 pm, mei <> wrote:
    > Chris Uppal a écrit :
    > > If it was possible then that would be because of a bug in the third-party
    > > class.

    >
    > That's why I wrote "we still make the assumption it exhibits a window of
    > vulnerability" ;)
    > Well, to make my question more concrete, I managed to find a reference
    > about this kind of problem that was evoked recently on this forum.
    > Let me quote Mark Thornton:
    > "You can only pass String to security critical methods. If String was
    > mutable or not final then untrusted code could breach security by
    > passing a value that was permitted (and thus passed any check) and then,
    > while the method was still in progress, modify the value (from another
    > thread) to refer to a resource that should have restricted access.
    > Obviously this approach depends on timing --- the change has to take
    > place after the value has been checked but before it is used."
    >
    > So let's assume a class exhibits the design flaw to take a mutable
    > string as a parameter. Thinking over it, I was wondering how we can make
    > sure (reasonably) that the thread has a chance to be executed during the
    > window of vulnerability? Is that a theoretical risk or not?
    > Mei


    A thread might have to try repeatedly until successful at its
    malicious action.
     
    Daniel Pitts, Mar 2, 2007
    #7
  8. mei

    Chris Uppal Guest

    Re: window of vulnerability

    mei wrote:

    > So let's assume a class exhibits the design flaw to take a mutable
    > string as a parameter. Thinking over it, I was wondering how we can make
    > sure (reasonably) that the thread has a chance to be executed during the
    > window of vulnerability? Is that a theoretical risk or not?


    OK, so we assume that have a third-party class, Victim, which has a bug (any
    bug) which we can exploit /if/ we can make our code run during some interval
    while the other code is also running. The challenge is to make our own code
    run at exactly the right time relative to the execution of Victim's code.

    The bug in Victim /might/ give us some way to control its execution. For
    instance, imagine that it is passed some object which it uses as a key in some
    HashMap during the window of opportunity. If we can supply a malicious object
    with a very slow implementation of hash() or equals(), then we can wedge the
    window open for as long as we like. Another possibility is that the Victim
    code may use a method which is synchronised on some object which we also have
    access to; if so then by taking out a lock on that object ourselves, we can
    cause the target code to block. Again, that will only work if Victim uses the
    synchronised method during the window of opportunity. (As an example, note
    that many of the Stream implementations are synchronised internally, so if we
    can find a stream that Victim uses during the window then we may be able to
    attack). A third way of wedging the window open is if the Victim writes to
    some external file, network connection, or stdout stream. If we can take
    control of that stream (perhaps by substituting our own stream, or by
    interfering with the stream at the operating-system level) then we may be able
    to make Victim slow down or even block when it is writing. There are lots of
    possibilities if you use your imagination. Perhaps Victim inserts data into a
    database in a way that we can cause to block by taking out DB locks. Perhaps
    Victim uses some other class which we can replace with a malicious substitute
    (maybe using classloaders). Perhaps, if we /really/ want to get exotic, we can
    run the code on a custom JVM. Perhaps we can run Victim under a debugger, and
    control it that way...

    However, if the Victim does not do anything "blockable" during the window of
    opportunity, and if we are not allowed to cheat by using debuggers and so on,
    then it gets harder. The shorter the time window is open for, the harder it
    will be. All we can do is sit in a tight loop (in one thread) trying to attack
    the Victim as often as possible and hope that one of our attempts will happen
    to run while the window is open. We can make that a bit more likely by running
    our thread at the highest possible priority, and the Victim's thread at the
    lowest possible. Our loop might then look like:
    while (! tryToAttackOnce())
    {
    Thread.yield();
    }
    the call to is intended to try to allow the Victim thread a chance to make a
    small amount of progress (it has to make /some/ progress or it will never open
    the window in the first place) but not so much that it'll be able to open /and/
    close the window before our next attempted attack. Depending on the
    implementation of the JVM we are running on, we may need to replace
    Thread.yield() with Thread.sleep() for some very short interval. Note that all
    manipulations of thread priority and yield()/sleep() have
    implementation-dependent effects -- what works on one OS/JVM combination may
    act completely differently on another one.

    Basically, getting our code to run at the right instant is a matter of trusting
    to luck. I know of no really good, portable, reliable, way of increasing our
    own luck (it's not part of the standard Java libraries, unfortunately ;-) The
    only way of boosting our chances are to reduce the adversary's luck -- for
    instance we could trick the developers of class Victim into demonstrating their
    product to their own top management. If we can't get lucky enough for our own
    attack to work during that demo then we probably won't ever manage it at all...

    -- chris
     
    Chris Uppal, Mar 2, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve C. Orr [MVP, MCSD]

    ASP.NET Security Vulnerability Discovered. Install the patch!

    Steve C. Orr [MVP, MCSD], Oct 8, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    354
    =?Utf-8?B?U3RldmVS?=
    Nov 11, 2004
  2. Ken Cox [Microsoft MVP]

    ASP.NET Security Vulnerability Update

    Ken Cox [Microsoft MVP], Oct 8, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    340
    Ken Cox [Microsoft MVP]
    Oct 8, 2004
  3. Ken Cox [Microsoft MVP]

    ASP.NET Security Vulnerability Update

    Ken Cox [Microsoft MVP], Oct 8, 2004, in forum: ASP .Net Datagrid Control
    Replies:
    0
    Views:
    139
    Ken Cox [Microsoft MVP]
    Oct 8, 2004
  4. Dinis Cruz
    Replies:
    2
    Views:
    355
    Dinis Cruz
    Oct 20, 2003
  5. Dinis Cruz
    Replies:
    1
    Views:
    270
    Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
    Oct 17, 2003
Loading...

Share This Page