[security] window of vulnerability

M

mei

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

Daniel Pitts

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

mei

Daniel Pitts a écrit :
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...
 
D

Daniel Pitts

Daniel Pitts a écrit :









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.
}
});
 
C

Chris Uppal

mei said:
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
 
M

mei

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
 
D

Daniel Pitts

Chris Uppal a écrit :

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

Chris Uppal

mei said:
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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top