You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Sim IJskes - QCG <si...@qcg.nl> on 2010/09/29 10:50:24 UTC
Re: Towards Internet Jini Services (dos attacks)
On 29-09-10 10:26, Zoltan Juhasz wrote:
> and
> unmarshalling and object movements may help DoS attacks to happen, etc, etc.
Could you explain the basic difference between RPC and messaging within
the context of DOS attacks?
The only difference i see right now, is that RPC mandates an ordered
relation between the request- and reply messages. Does this theorically
create an extra opportunity for DOS attacks?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Towards Internet Jini Services (dos attacks)
Posted by Peter Firmstone <ji...@zeus.net.au>.
However memory exhaustion is a problem.
Even trusted code might create many objects and not null out their
references.
If Services and clients have identity, namely Public Key Certificates
and we had some kind of trust reporting service, then badly behaving
smart proxy's can be identified. The first person to report the problem
to, would be the service provider, then in case that doesn't work we
could set up a feedback service to encourage people to improve or
remove. Failing that the final case might be to black ban a service,
based on the message digest of it's proxy. This could be implemented as
a Service. Internet facing Service Registrar's could simply not allow
bad services to register. If the service provider fixes it's proxy, it
will have a different message digest and be given the opportunity to
work again with a new proxy codebase.
People will stop using a badly behaving service, because the app & jvm
will crash every time they try to use it.
What we really want to do is prevent access to information that
shouldn't be accessed and prevent mass DOS attacks, eg a big Jini botnet.
Individual DOS, not so bad, provided it is short lived and data is not
lost or corrupted.
We will need feedback services to report bad services to, so that
trusted Service Registrars don't deliver them to clients.
To deal with DOS, services will need to authenticate clients, and report
badly behaving clients (if those clients return an exported object).
Redundant services might also provide fail over protection. Badly
behaving clients must be denied access to Service Registrars. They will
need to obtain a new identity and start over, gaining trust.
In this case when I say authenticate, I mean with a Public Key
Certificate, perhaps we could use a PGP Provider?
7 Degrees of Separation, the web of trust?
Tim Blackman, was researching placing untrusted code into a Second JVM,
I believe because the isolates API was still-borne. I'm not sure how
the trusted and untrusted JVM's communicated.
Cheers,
Peter.
Peter Firmstone wrote:
> Yes, it certainly can.
>
> Regards,
>
> Peter.
>
> Christopher Dolan wrote:
>> private void readObject(ObjectInputStream in) {
>> new Runnable() {
>> public void run() {
>> while (true)
>> new Thread(this).start();
>> }
>> }.run();
>> }
>>
>> At 1MB of stack RAM per thread, this will thrash most machines in no
>> time. Can a SecurityManager block thread creation?
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au] Sent: Wednesday,
>> September 29, 2010 3:58 PM
>> To: river-dev@incubator.apache.org
>> Subject: Re: Towards Internet Jini Services (dos attacks)
>>
>> Zoltan Juhasz wrote:
>>
>>> Sim,
>>>
>>> I think the important danger in Jini is the use of objects. In simple
>>> messaging communication (especially if non-binary), you don't have to
>>>
>> worry
>>
>>> about objects. In Jini, any method can take and object as a parameter
>>>
>> that
>>
>>> results in serialisation and unmarshalling at the receiver end. When
>>>
>> an
>>
>>> object has something nasty executing during within the readObject()
>>>
>> method,
>>
>>> it's too late to do anything.
>>>
>>
>> This was a big problem in the days of single core, not as bad now.
>> Perhaps we need a software watchdog? Or an easy way to kill and
>> quarantine a misbehaving service? Or an unmarshalling executor
>> thread pool, which passes the object after it has been deserialized.
>>
>>
>
>
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/04/2010 03:38 PM, Peter Firmstone wrote:
> So let me get this clear, you don't want me to fix the deserialization
> attack because River isn't 100% provably secure?
No please, don't misunderstand, i like you to fix it, everybody does.
But shall we discuss it first? I would hate to see good work go to waste
because in the end it turns out no gains could be made.
Gr. Sim
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi Peter,
Sorry if my emails of late resemble an attack, they're not intended as such.
I'm just asking questions and trying to understand.
You're right, nothing is ever 100% provably secure - to my knowledge at
least. Internet banking is not 100% secure; however, all things being
equal, it is considered to be "secure enough".
There is no reason why you shouldn't implement those changes. As I
understand Apache, anyone who has the will and the way can do pretty much
whatever they want, while everyone else stands around talking about it. My
only point was, as soon as we start to programatically mitigate those kinds
of attack we have to maintain that approach; along with plugging the extra
holes as and when they are found. So the effort to do this kind of work is
actually ongoing and more than just addressing the attacks we currently have
identified.
The false sense of security I was talking about is linked to that. If we
protect against the three attacks you list, then great, but users will
expect us to also protect against some fourth kind of attack. If we miss
it, or ignore it, or decide "actually, we *can't* guard against this new
attack", we're left with an incomplete security model. As a service
provider, I would personally find it confusing trying to keep track of which
kind of attack my infrastructure (River) guards me against and which ones it
doesn't.
To me, in my opinion, that sounds like a bit of a mess that I (personally)
don't want to get involved in. What I am arguing is that we can avoid that
situation 'simply' by saying "Make sure you trust the person you get the
proxy from" and then assume that everything is okay from then on in. This
makes the code changes you refer to as "nice to have" rather than "critical"
just get River to be viewed as "secure enough".
Things like RSA and so on are demonstrably secure (so far, anyway). Can
anyone who is a Security Expert (i.e. not me) tell me/us if there is some
kind of way to demonstrate the security of the code. Or are code
reviews/tests/written papers/etc enough?
Cheers,
Tom
On Mon, Oct 4, 2010 at 2:38 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> So let me get this clear, you don't want me to fix the deserialization
> attack because River isn't 100% provably secure?
>
> Give me a break, I've only just started investigating it.
>
> Name me one product that is 100% secure?
>
> Can someone provide "a good reason" why I shouldn't attempt to fix the
> following deserialization attacks:
>
> 1. Infinite loop recursion.
> 2. Attempts to overflow memory by creating many objects.
> 3. Deliberate concurrency deadlock.
>
> All these I believe can be controlled by restricting the smart proxy to a
> single thread and passing all method invocations from a reflective proxy via
> a queue. The client interacts with the reflective proxy, to the client,
> this is the service and the client is protected from those attacks because
> the client thread never touches the smart proxy.
>
> 1. Infinite loops throw a StackOverflowError - terminate thread and
> smart proxy.
> 2. Attempts to overflow memory by creating many objects - only causes
> a StackOverflowError for the smart proxy, terminate, throw an
> IOException, go find another service.
> 3. Deliberate concurrency deadlock - ever tried this with only one
> thread?
>
> Once trust is determined, after deserialization, with the existing trust
> mechanisms, then we are free to grant Permission to the smart proxy, and
> improve performance by allowing many threads.
>
> Identifying a particular attack, then proving it doesn't work, will improve
> security. I need tangible goals and identifiable issues to address.
>
> N.B. Internet Banking isn't 100% secure, you take the following risks:
>
> Keystroke logger at your PC.
> A phishing attack.
> Identity theft.
> A DNS cache poisoning attack.
> A registered signed certificate for an identically appearing site, but
> owned by an untrusted third party, you think is the bank.
> An attacker breaking into the bank's webserver.
> A compromised certificate.
>
> I'm not creating a false sense of security, I'm investigating a security
> issue, why are you suddenly reading so much into it?
>
> Peter.
>
>
>
>
> Tom Hobbs wrote:
>
>> Because it's possible and will improve security, I think we should
>>> investigate it further, this could allow us to unmarshall the proxy and
>>> determine trust without changing the Jini Service model. There's still
>>> Service UI to consider too, but that happens after determining trust. We
>>> need to be immune to DOS attacks during the period we're trying to
>>> determine
>>> trust.
>>>
>>>
>>>
>>
>> I don't want to discourage anyone from doing anything, but I find this
>> concerning. To my mind, something should either be 100% secure; like
>> operating systems are (supposed to be), or there should be a clear
>> "download
>> and run at your own risk". Things we pay for (buying stuff off the
>> internet, online banking, hosted services etc) are supposed to be secure
>> and
>> there are clear SLAs describing what happens if it's not. Everything else
>> you download is very much "on your own head, be it".
>>
>> What I'm getting from these recent discussions is broadly this;
>>
>> - "We can protect against this kind of threat, but not that one."
>> - "We can't protect, at all, against this other kind of thread."
>> - "We can mitigate the consequences of this kind of thread."
>>
>> And that's only for the kinds of things we can think of. I agree with Sim
>> on this one, it feels like we're creating a false sense of security. The
>> danger I see in this is that people will either;
>>
>> 1) See our security designs, see that they're incomplete and announce that
>> "River is insecure".
>> 2) See our secuirty designs, miss what they do and do not provide, and
>> announce that "River is bullet-proof".
>>
>> Both of these statements are wrong and both are dangerous. I'm still of
>> the
>> opinion that we can provide secure services through trust (that's a
>> lower-case, none Computer Science "trust") and not through code. If,
>> typically, people get their proxies from some kind of "app store" that
>> they
>> trust, the community can make sure that only trusted services can get onto
>> the "app store". If you want to use a less-known and maybe less trust
>> worthy "app store" then that's up to you.
>>
>> I'm leaning towards programmatic security being an all-or-nothing affair.
>> Since it appears that we can't protect against everything; I'm reminded
>> that we can lock and bolt the door as much as we like, but if we leave our
>> Windows unsecure (ha ha) then the bad guys will still get in.
>>
>> Tom
>>
>>
>>
>
>
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Peter Firmstone <ji...@zeus.net.au>.
So let me get this clear, you don't want me to fix the deserialization
attack because River isn't 100% provably secure?
Give me a break, I've only just started investigating it.
Name me one product that is 100% secure?
Can someone provide "a good reason" why I shouldn't attempt to fix the
following deserialization attacks:
1. Infinite loop recursion.
2. Attempts to overflow memory by creating many objects.
3. Deliberate concurrency deadlock.
All these I believe can be controlled by restricting the smart proxy to
a single thread and passing all method invocations from a reflective
proxy via a queue. The client interacts with the reflective proxy, to
the client, this is the service and the client is protected from those
attacks because the client thread never touches the smart proxy.
1. Infinite loops throw a StackOverflowError - terminate thread and
smart proxy.
2. Attempts to overflow memory by creating many objects - only causes
a StackOverflowError for the smart proxy, terminate, throw an
IOException, go find another service.
3. Deliberate concurrency deadlock - ever tried this with only one
thread?
Once trust is determined, after deserialization, with the existing trust
mechanisms, then we are free to grant Permission to the smart proxy, and
improve performance by allowing many threads.
Identifying a particular attack, then proving it doesn't work, will
improve security. I need tangible goals and identifiable issues to address.
N.B. Internet Banking isn't 100% secure, you take the following risks:
Keystroke logger at your PC.
A phishing attack.
Identity theft.
A DNS cache poisoning attack.
A registered signed certificate for an identically appearing site, but
owned by an untrusted third party, you think is the bank.
An attacker breaking into the bank's webserver.
A compromised certificate.
I'm not creating a false sense of security, I'm investigating a security
issue, why are you suddenly reading so much into it?
Peter.
Tom Hobbs wrote:
>> Because it's possible and will improve security, I think we should
>> investigate it further, this could allow us to unmarshall the proxy and
>> determine trust without changing the Jini Service model. There's still
>> Service UI to consider too, but that happens after determining trust. We
>> need to be immune to DOS attacks during the period we're trying to determine
>> trust.
>>
>>
>
> I don't want to discourage anyone from doing anything, but I find this
> concerning. To my mind, something should either be 100% secure; like
> operating systems are (supposed to be), or there should be a clear "download
> and run at your own risk". Things we pay for (buying stuff off the
> internet, online banking, hosted services etc) are supposed to be secure and
> there are clear SLAs describing what happens if it's not. Everything else
> you download is very much "on your own head, be it".
>
> What I'm getting from these recent discussions is broadly this;
>
> - "We can protect against this kind of threat, but not that one."
> - "We can't protect, at all, against this other kind of thread."
> - "We can mitigate the consequences of this kind of thread."
>
> And that's only for the kinds of things we can think of. I agree with Sim
> on this one, it feels like we're creating a false sense of security. The
> danger I see in this is that people will either;
>
> 1) See our security designs, see that they're incomplete and announce that
> "River is insecure".
> 2) See our secuirty designs, miss what they do and do not provide, and
> announce that "River is bullet-proof".
>
> Both of these statements are wrong and both are dangerous. I'm still of the
> opinion that we can provide secure services through trust (that's a
> lower-case, none Computer Science "trust") and not through code. If,
> typically, people get their proxies from some kind of "app store" that they
> trust, the community can make sure that only trusted services can get onto
> the "app store". If you want to use a less-known and maybe less trust
> worthy "app store" then that's up to you.
>
> I'm leaning towards programmatic security being an all-or-nothing affair.
> Since it appears that we can't protect against everything; I'm reminded
> that we can lock and bolt the door as much as we like, but if we leave our
> Windows unsecure (ha ha) then the bad guys will still get in.
>
> Tom
>
>
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Tom Hobbs <tv...@googlemail.com>.
> Because it's possible and will improve security, I think we should
> investigate it further, this could allow us to unmarshall the proxy and
> determine trust without changing the Jini Service model. There's still
> Service UI to consider too, but that happens after determining trust. We
> need to be immune to DOS attacks during the period we're trying to determine
> trust.
>
I don't want to discourage anyone from doing anything, but I find this
concerning. To my mind, something should either be 100% secure; like
operating systems are (supposed to be), or there should be a clear "download
and run at your own risk". Things we pay for (buying stuff off the
internet, online banking, hosted services etc) are supposed to be secure and
there are clear SLAs describing what happens if it's not. Everything else
you download is very much "on your own head, be it".
What I'm getting from these recent discussions is broadly this;
- "We can protect against this kind of threat, but not that one."
- "We can't protect, at all, against this other kind of thread."
- "We can mitigate the consequences of this kind of thread."
And that's only for the kinds of things we can think of. I agree with Sim
on this one, it feels like we're creating a false sense of security. The
danger I see in this is that people will either;
1) See our security designs, see that they're incomplete and announce that
"River is insecure".
2) See our secuirty designs, miss what they do and do not provide, and
announce that "River is bullet-proof".
Both of these statements are wrong and both are dangerous. I'm still of the
opinion that we can provide secure services through trust (that's a
lower-case, none Computer Science "trust") and not through code. If,
typically, people get their proxies from some kind of "app store" that they
trust, the community can make sure that only trusted services can get onto
the "app store". If you want to use a less-known and maybe less trust
worthy "app store" then that's up to you.
I'm leaning towards programmatic security being an all-or-nothing affair.
Since it appears that we can't protect against everything; I'm reminded
that we can lock and bolt the door as much as we like, but if we leave our
Windows unsecure (ha ha) then the bad guys will still get in.
Tom
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 10/03/2010 11:00 AM, Peter Firmstone wrote:
>> I've got some thoughts about how to isolate a smart proxy, please tell
>> me yours:
>
> Are you sure you want to go the technical way, almost adding a
> function, missing from the VM and runtime libraries, just because you
> want to download anything you want, and execute it immediately?
Because it's possible and will improve security, I think we should
investigate it further, this could allow us to unmarshall the proxy and
determine trust without changing the Jini Service model. There's still
Service UI to consider too, but that happens after determining trust.
We need to be immune to DOS attacks during the period we're trying to
determine trust.
>
> Isn't the general advice we give to people, think before you download,
> and can't we extend this to jini?
This should still be the advice, for full functionality, some level of
trust will be required. If you were client of a service, the trust
you'd have for NASA or a University, would be different to the trust
you'd give a large corporation connected with advertising, or a poor
history of leaking personal details.
I think we need some new feedback based services to assist with trust
decisions.
>
> I see many similarities to having a jini code clearinghouse and mobile
> application appstores. I just don't want to limit peoples choices to 1
> single appstore, and don't want to expose them to the naive keystore
> model used for https, where 1 faulty certificate authority can
> deteriorate the whole system.
I agree, I think we need pgp's web of trust, the infrastructure is
available now, public key servers etc, the technology's proven. The
Bouncy Castle has a pgp provider we can plug in.
Cheers,
Peter.
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/03/2010 11:00 AM, Peter Firmstone wrote:
> I've got some thoughts about how to isolate a smart proxy, please tell
> me yours:
Are you sure you want to go the technical way, almost adding a function,
missing from the VM and runtime libraries, just because you want to
download anything you want, and execute it immediately?
Isn't the general advice we give to people, think before you download,
and can't we extend this to jini?
I see many similarities to having a jini code clearinghouse and mobile
application appstores. I just don't want to limit peoples choices to 1
single appstore, and don't want to expose them to the naive keystore
model used for https, where 1 faulty certificate authority can
deteriorate the whole system.
Gr. Sim
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/03/2010 11:00 AM, Peter Firmstone wrote:
> cause an OutOfMemoryError, unless the JVM is configured incorrectly. By
> giving the thread a lower priority, it couldn't freeze a single core
> client either.
I think this will create a false sense of security. To take it into the
absurd, how do you want to communicate this function? "We have hardened
the system, it will still drain your battery, but at a much lower priority"?
Gr. Sim
Re: Towards Internet Jini Services (dos attacks) Smart Proxy Isolation
Posted by Peter Firmstone <ji...@zeus.net.au>.
I've got some thoughts about how to isolate a smart proxy, please tell
me yours:
1. Implement an InvocationHandler for java.lang.reflect.Proxy,
perhaps called SmartProxyIsolate
2. SmartProxyIsolate has it's own Thread with a custom
UncaughtExceptionHandler, it deals with any Errors the thread
might have, such as StackOverflowError. In the event of a
StackOverflowError, the smart proxy reference and thread reference
and method call queue, would be set to null immediately, leaving
the SmartProxyIsolate in a known state, all method in the isolate
would then return an IOException.
3. All method invocations are passed to the smart proxy contained by
the SmartProxyIsolate, only the SmartProxyIsolate holds a strong
reference to the smart proxy. The SmartProxyIsolate would expect
a MarshalledInstance of the proxy in it's constructor.
4. All methods on the smart proxy are only called from the
SmartProxyIsolate thread, trapping and handling any errors.
5. A java.lang.reflect.Proxy ( created with the SmartProxyIsolate
InvocationHandler ) is referenced by the client.
6. SmartProxyIsolate needs a method to return the ProtectionDomain,
to enable dynamic grants be granted to the smart proxy's PD by the
DynamicPolicy, rather than the PD of the SmartProxyIsolate.
7. To be completely sure, the Service API method returns shouldn't be
subclasses, unless the smart proxy is trusted, we could create a
new Permission class for this purpose. (lest a subclass be
returned containing a reference to the smart proxy).
This structure could be used to isolate any proxy that requires a
downloaded codebase, we would also need to place a limit on the size of
the downloaded codebase, to prevent DOS that way too (I'll explain later).
We might also provide a method that allows the calling class to set an
event handler, all method calls would return null immediately, and an
Event later generated containing the result of the method call. This
means the client thread isn't delayed in a wait state, but the default
behaviour would be for client threads to wait.
Note that this requires JAVA 5, since each thread must have it's own
UncaughtExceptionHandler that knows the specific SmartProxyIsolate.
The smart proxy would be isolated in it's own thread, any objects it
creates will be in a thread local stack, it would unlikely be able to
cause an OutOfMemoryError, unless the JVM is configured incorrectly.
By giving the thread a lower priority, it couldn't freeze a single core
client either.
Cheers,
Peter.
Peter Firmstone wrote:
> I'm wondering, what can be done about DOS recursion with threads and
> memory?
>
> A Thread has it's own private memory stack, the downloaded proxy will
> only have thread local objects, until they're passed to another thread.
>
> What if we use a new thread to unmarshall and interact with the proxy?
>
> A deliberate infinitely recursive loop in a Thread will throw a
> StackOverflowError, it may also cause problems with the available
> memory for all threads, so it needs to be tuned correctly with JVM
> memory options.
>
> >From java.lang.Thread (the discussion is interesting, not the
> stackSize constructor), also note the UncaughtExceptionHandler method
> that follows.
>
> /**
> * Allocates a new <code>Thread</code> object so that it has
> * <code>target</code> as its run object, has the specified
> * <code>name</code> as its name, belongs to the thread group
> referred to
> * by <code>group</code>, and has the specified <i>stack size</i>.
> *
> * <p>This constructor is identical to {@link
> * #Thread(ThreadGroup,Runnable,String)} with the exception of the
> fact
> * that it allows the thread stack size to be specified. The stack
> size
> * is the approximate number of bytes of address space that the
> virtual
> * machine is to allocate for this thread's stack. <b>The effect
> of the
> * <tt>stackSize</tt> parameter, if any, is highly platform
> dependent.</b>
> *
> * <p>On some platforms, specifying a higher value for the
> * <tt>stackSize</tt> parameter may allow a thread to achieve greater
> * recursion depth before throwing a {@link StackOverflowError}.
> * Similarly, specifying a lower value may allow a greater number of
> * threads to exist concurrently without throwing an {@link
> * OutOfMemoryError} (or other internal error). The details of
> * the relationship between the value of the <tt>stackSize</tt>
> parameter
> * and the maximum recursion depth and concurrency level are
> * platform-dependent. <b>On some platforms, the value of the
> * <tt>stackSize</tt> parameter may have no effect whatsoever.</b>
> *
> * <p>The virtual machine is free to treat the <tt>stackSize</tt>
> * parameter as a suggestion. If the specified value is
> unreasonably low
> * for the platform, the virtual machine may instead use some
> * platform-specific minimum value; if the specified value is
> unreasonably
> * high, the virtual machine may instead use some platform-specific
> * maximum. Likewise, the virtual machine is free to round the
> specified
> * value up or down as it sees fit (or to ignore it completely).
> *
> * <p>Specifying a value of zero for the <tt>stackSize</tt>
> parameter will
> * cause this constructor to behave exactly like the
> * <tt>Thread(ThreadGroup, Runnable, String)</tt> constructor.
> *
> * <p><i>Due to the platform-dependent nature of the behavior of this
> * constructor, extreme care should be exercised in its use.
> * The thread stack size necessary to perform a given computation will
> * likely vary from one JRE implementation to another. In light of
> this
> * variation, careful tuning of the stack size parameter may be
> required,
> * and the tuning may need to be repeated for each JRE
> implementation on
> * which an application is to run.</i>
> *
> * <p>Implementation note: Java platform implementers are
> encouraged to
> * document their implementation's behavior with respect to the
> * <tt>stackSize parameter</tt>.
> *
> * @param group the thread group.
> * @param target the object whose <code>run</code> method is
> called.
> * @param name the name of the new thread.
> * @param stackSize the desired stack size for the new thread, or
> * zero to indicate that this parameter is to be ignored.
> * @exception SecurityException if the current thread cannot
> create a
> * thread in the specified thread group.
> * @since 1.4
> */
> public Thread(ThreadGroup group, Runnable target, String name,
> long stackSize)
>
> /**
> * Set the handler invoked when this thread abruptly terminates
> * due to an uncaught exception.
> * <p>A thread can take full control of how it responds to uncaught
> * exceptions by having its uncaught exception handler explicitly set.
> * If no such handler is set then the thread's <tt>ThreadGroup</tt>
> * object acts as its handler.
> * @param eh the object to use as this thread's uncaught exception
> * handler. If <tt>null</tt> then this thread has no explicit handler.
> * @throws SecurityException if the current thread is not allowed to
> * modify this thread.
> * @see #setDefaultUncaughtExceptionHandler
> * @see ThreadGroup#uncaughtException
> * @since 1.5
> */
> public void setUncaughtExceptionHandler(UncaughtExceptionHandler eh)
>
> If we catch the StackOverflowError, null out all references to the
> proxy and terminate the thread, we free the memory, the trick is not
> creating any new objects during recovery and making sure that the
> Thread running out of local memory doesn't threaten the memory the
> other threads have.
>
> We can also set the proxy's unmarshalling thread with a low priority
> on Single processor machines, so other higher priority threads get
> some cpu time slices.
>
> Once proxy unmarshalling is complete, it's still not safe to return
> the proxy to the calling thread, the trouble is, the proxy's methods
> could still contain infinitely recursive loops.
>
> Any ideas for how to best invoke methods on the proxy, via the proxy
> thread, originating from the application thread?
>
> Cheers,
>
> Peter.
>
> Peter Firmstone wrote:
>> Perhaps Oracle might have the money to complete the MVM Isolates API
>> for Java SE and EE.
>>
>> Isolates present the opportunity to restrict resources, which could
>> fix the issues with excess resource consumption as DOS.
>>
>> Until then the remaining ways to combat the memory consumption problem.
>>
>> Reboot, report and be careful who you trust.
>>
>> N.B. They can't do this with a reflective proxy, so don't grant their
>> Principal DownloadPermission if you don't trust them.
>>
>> Cheers,
>>
>> Peter.
>>
>> Christopher Dolan wrote:
>>> Just for the record, Peter is right. I just looked at the JDK 1.5
>>> source
>>> code for java.lang.Thread. The security permission you need to create a
>>> thread or a thread group is
>>> SecurityConstants.MODIFY_THREADGROUP_PERMISSION, aka
>>> java.lang.RuntimePermission("modifyThreadGroup"). I hadn't known about
>>> that. The "modifyThread" permission does not affect one's ability to
>>> create and start threads.
>>>
>>> So, that would argue for a tightened security context during
>>> deserialization. That would at least revert us to Peter's original
>>> statement that only one core could be smacked with 100% load. The RAM
>>> usage would not be controllable, though.
>>>
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Peter Firmstone [mailto:jini@zeus.net.au] Sent: Thursday,
>>> September 30, 2010 2:41 AM
>>> To: river-dev@incubator.apache.org
>>> Subject: Re: Towards Internet Jini Services (dos attacks)
>>>
>>> Yes, it certainly can.
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>> Christopher Dolan wrote:
>>>
>>>> private void readObject(ObjectInputStream in) {
>>>> new Runnable() {
>>>> public void run() {
>>>> while (true)
>>>> new Thread(this).start();
>>>> }
>>>> }.run();
>>>> }
>>>>
>>>> At 1MB of stack RAM per thread, this will thrash most machines in no
>>>> time. Can a SecurityManager block thread creation?
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: Peter Firmstone [mailto:jini@zeus.net.au] Sent: Wednesday,
>>>> September 29, 2010 3:58 PM
>>>> To: river-dev@incubator.apache.org
>>>> Subject: Re: Towards Internet Jini Services (dos attacks)
>>>>
>>>> Zoltan Juhasz wrote:
>>>>
>>>>> Sim,
>>>>>
>>>>> I think the important danger in Jini is the use of objects. In simple
>>>>> messaging communication (especially if non-binary), you don't have to
>>>>>
>>>> worry
>>>>
>>>>> about objects. In Jini, any method can take and object as a parameter
>>>>>
>>>> that
>>>>
>>>>> results in serialisation and unmarshalling at the receiver end. When
>>>>>
>>>> an
>>>>
>>>>> object has something nasty executing during within the readObject()
>>>>>
>>>> method,
>>>>
>>>>> it's too late to do anything.
>>>>>
>>>> This was a big problem in the days of single core, not as bad now.
>>>> Perhaps we need a software watchdog? Or an easy way to kill and
>>>> quarantine a misbehaving service? Or an unmarshalling executor thread
>>>>
>>>
>>>
>>>> pool, which passes the object after it has been deserialized.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Towards Internet Jini Services (dos attacks) perhaps solvable
Posted by Peter Firmstone <ji...@zeus.net.au>.
I'm wondering, what can be done about DOS recursion with threads and memory?
A Thread has it's own private memory stack, the downloaded proxy will
only have thread local objects, until they're passed to another thread.
What if we use a new thread to unmarshall and interact with the proxy?
A deliberate infinitely recursive loop in a Thread will throw a
StackOverflowError, it may also cause problems with the available memory
for all threads, so it needs to be tuned correctly with JVM memory options.
From java.lang.Thread (the discussion is interesting, not the stackSize
constructor), also note the UncaughtExceptionHandler method that follows.
/**
* Allocates a new <code>Thread</code> object so that it has
* <code>target</code> as its run object, has the specified
* <code>name</code> as its name, belongs to the thread group
referred to
* by <code>group</code>, and has the specified <i>stack size</i>.
*
* <p>This constructor is identical to {@link
* #Thread(ThreadGroup,Runnable,String)} with the exception of the fact
* that it allows the thread stack size to be specified. The stack size
* is the approximate number of bytes of address space that the virtual
* machine is to allocate for this thread's stack. <b>The effect of the
* <tt>stackSize</tt> parameter, if any, is highly platform
dependent.</b>
*
* <p>On some platforms, specifying a higher value for the
* <tt>stackSize</tt> parameter may allow a thread to achieve greater
* recursion depth before throwing a {@link StackOverflowError}.
* Similarly, specifying a lower value may allow a greater number of
* threads to exist concurrently without throwing an {@link
* OutOfMemoryError} (or other internal error). The details of
* the relationship between the value of the <tt>stackSize</tt>
parameter
* and the maximum recursion depth and concurrency level are
* platform-dependent. <b>On some platforms, the value of the
* <tt>stackSize</tt> parameter may have no effect whatsoever.</b>
*
* <p>The virtual machine is free to treat the <tt>stackSize</tt>
* parameter as a suggestion. If the specified value is
unreasonably low
* for the platform, the virtual machine may instead use some
* platform-specific minimum value; if the specified value is
unreasonably
* high, the virtual machine may instead use some platform-specific
* maximum. Likewise, the virtual machine is free to round the
specified
* value up or down as it sees fit (or to ignore it completely).
*
* <p>Specifying a value of zero for the <tt>stackSize</tt>
parameter will
* cause this constructor to behave exactly like the
* <tt>Thread(ThreadGroup, Runnable, String)</tt> constructor.
*
* <p><i>Due to the platform-dependent nature of the behavior of this
* constructor, extreme care should be exercised in its use.
* The thread stack size necessary to perform a given computation will
* likely vary from one JRE implementation to another. In light of this
* variation, careful tuning of the stack size parameter may be
required,
* and the tuning may need to be repeated for each JRE implementation on
* which an application is to run.</i>
*
* <p>Implementation note: Java platform implementers are encouraged to
* document their implementation's behavior with respect to the
* <tt>stackSize parameter</tt>.
*
* @param group the thread group.
* @param target the object whose <code>run</code> method is
called.
* @param name the name of the new thread.
* @param stackSize the desired stack size for the new thread, or
* zero to indicate that this parameter is to be ignored.
* @exception SecurityException if the current thread cannot create a
* thread in the specified thread group.
* @since 1.4
*/
public Thread(ThreadGroup group, Runnable target, String name,
long stackSize)
/**
* Set the handler invoked when this thread abruptly terminates
* due to an uncaught exception.
* <p>A thread can take full control of how it responds to uncaught
* exceptions by having its uncaught exception handler explicitly set.
* If no such handler is set then the thread's <tt>ThreadGroup</tt>
* object acts as its handler.
* @param eh the object to use as this thread's uncaught exception
* handler. If <tt>null</tt> then this thread has no explicit handler.
* @throws SecurityException if the current thread is not allowed to
* modify this thread.
* @see #setDefaultUncaughtExceptionHandler
* @see ThreadGroup#uncaughtException
* @since 1.5
*/
public void setUncaughtExceptionHandler(UncaughtExceptionHandler eh)
If we catch the StackOverflowError, null out all references to the proxy
and terminate the thread, we free the memory, the trick is not creating
any new objects during recovery and making sure that the Thread running
out of local memory doesn't threaten the memory the other threads have.
We can also set the proxy's unmarshalling thread with a low priority on
Single processor machines, so other higher priority threads get some cpu
time slices.
Once proxy unmarshalling is complete, it's still not safe to return the
proxy to the calling thread, the trouble is, the proxy's methods could
still contain infinitely recursive loops.
Any ideas for how to best invoke methods on the proxy, via the proxy
thread, originating from the application thread?
Cheers,
Peter.
Peter Firmstone wrote:
> Perhaps Oracle might have the money to complete the MVM Isolates API
> for Java SE and EE.
>
> Isolates present the opportunity to restrict resources, which could
> fix the issues with excess resource consumption as DOS.
>
> Until then the remaining ways to combat the memory consumption problem.
>
> Reboot, report and be careful who you trust.
>
> N.B. They can't do this with a reflective proxy, so don't grant their
> Principal DownloadPermission if you don't trust them.
>
> Cheers,
>
> Peter.
>
> Christopher Dolan wrote:
>> Just for the record, Peter is right. I just looked at the JDK 1.5 source
>> code for java.lang.Thread. The security permission you need to create a
>> thread or a thread group is
>> SecurityConstants.MODIFY_THREADGROUP_PERMISSION, aka
>> java.lang.RuntimePermission("modifyThreadGroup"). I hadn't known about
>> that. The "modifyThread" permission does not affect one's ability to
>> create and start threads.
>>
>> So, that would argue for a tightened security context during
>> deserialization. That would at least revert us to Peter's original
>> statement that only one core could be smacked with 100% load. The RAM
>> usage would not be controllable, though.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au] Sent: Thursday,
>> September 30, 2010 2:41 AM
>> To: river-dev@incubator.apache.org
>> Subject: Re: Towards Internet Jini Services (dos attacks)
>>
>> Yes, it certainly can.
>>
>> Regards,
>>
>> Peter.
>>
>> Christopher Dolan wrote:
>>
>>> private void readObject(ObjectInputStream in) {
>>> new Runnable() {
>>> public void run() {
>>> while (true)
>>> new Thread(this).start();
>>> }
>>> }.run();
>>> }
>>>
>>> At 1MB of stack RAM per thread, this will thrash most machines in no
>>> time. Can a SecurityManager block thread creation?
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Peter Firmstone [mailto:jini@zeus.net.au] Sent: Wednesday,
>>> September 29, 2010 3:58 PM
>>> To: river-dev@incubator.apache.org
>>> Subject: Re: Towards Internet Jini Services (dos attacks)
>>>
>>> Zoltan Juhasz wrote:
>>>
>>>> Sim,
>>>>
>>>> I think the important danger in Jini is the use of objects. In simple
>>>> messaging communication (especially if non-binary), you don't have to
>>>>
>>> worry
>>>
>>>> about objects. In Jini, any method can take and object as a parameter
>>>>
>>> that
>>>
>>>> results in serialisation and unmarshalling at the receiver end. When
>>>>
>>> an
>>>
>>>> object has something nasty executing during within the readObject()
>>>>
>>> method,
>>>
>>>> it's too late to do anything.
>>>>
>>> This was a big problem in the days of single core, not as bad now.
>>> Perhaps we need a software watchdog? Or an easy way to kill and
>>> quarantine a misbehaving service? Or an unmarshalling executor thread
>>>
>>
>>
>>> pool, which passes the object after it has been deserialized.
>>>
>>>
>>
>>
>>
>
>
Re: Towards Internet Jini Services (dos attacks)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Perhaps Oracle might have the money to complete the MVM Isolates API for
Java SE and EE.
Isolates present the opportunity to restrict resources, which could fix
the issues with excess resource consumption as DOS.
Until then the remaining ways to combat the memory consumption problem.
Reboot, report and be careful who you trust.
N.B. They can't do this with a reflective proxy, so don't grant their
Principal DownloadPermission if you don't trust them.
Cheers,
Peter.
Christopher Dolan wrote:
> Just for the record, Peter is right. I just looked at the JDK 1.5 source
> code for java.lang.Thread. The security permission you need to create a
> thread or a thread group is
> SecurityConstants.MODIFY_THREADGROUP_PERMISSION, aka
> java.lang.RuntimePermission("modifyThreadGroup"). I hadn't known about
> that. The "modifyThread" permission does not affect one's ability to
> create and start threads.
>
> So, that would argue for a tightened security context during
> deserialization. That would at least revert us to Peter's original
> statement that only one core could be smacked with 100% load. The RAM
> usage would not be controllable, though.
>
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Thursday, September 30, 2010 2:41 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Towards Internet Jini Services (dos attacks)
>
> Yes, it certainly can.
>
> Regards,
>
> Peter.
>
> Christopher Dolan wrote:
>
>> private void readObject(ObjectInputStream in) {
>> new Runnable() {
>> public void run() {
>> while (true)
>> new Thread(this).start();
>> }
>> }.run();
>> }
>>
>> At 1MB of stack RAM per thread, this will thrash most machines in no
>> time. Can a SecurityManager block thread creation?
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au]
>> Sent: Wednesday, September 29, 2010 3:58 PM
>> To: river-dev@incubator.apache.org
>> Subject: Re: Towards Internet Jini Services (dos attacks)
>>
>> Zoltan Juhasz wrote:
>>
>>
>>> Sim,
>>>
>>> I think the important danger in Jini is the use of objects. In simple
>>> messaging communication (especially if non-binary), you don't have to
>>>
>>>
>> worry
>>
>>
>>> about objects. In Jini, any method can take and object as a parameter
>>>
>>>
>> that
>>
>>
>>> results in serialisation and unmarshalling at the receiver end. When
>>>
>>>
>> an
>>
>>
>>> object has something nasty executing during within the readObject()
>>>
>>>
>> method,
>>
>>
>>> it's too late to do anything.
>>>
>>>
>> This was a big problem in the days of single core, not as bad now.
>> Perhaps we need a software watchdog? Or an easy way to kill and
>> quarantine a misbehaving service? Or an unmarshalling executor thread
>>
>
>
>> pool, which passes the object after it has been deserialized.
>>
>>
>>
>
>
>
Re: Towards Internet Jini Services (dos attacks)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/30/2010 05:59 PM, Christopher Dolan wrote:
> So, that would argue for a tightened security context during
> deserialization. That would at least revert us to Peter's original
> statement that only one core could be smacked with 100% load.
Yes, and with a mobile device with limited battery power, this would
definitely constitute a DOS attack.
Gr. Sim
RE: Towards Internet Jini Services (dos attacks)
Posted by Christopher Dolan <ch...@avid.com>.
Just for the record, Peter is right. I just looked at the JDK 1.5 source
code for java.lang.Thread. The security permission you need to create a
thread or a thread group is
SecurityConstants.MODIFY_THREADGROUP_PERMISSION, aka
java.lang.RuntimePermission("modifyThreadGroup"). I hadn't known about
that. The "modifyThread" permission does not affect one's ability to
create and start threads.
So, that would argue for a tightened security context during
deserialization. That would at least revert us to Peter's original
statement that only one core could be smacked with 100% load. The RAM
usage would not be controllable, though.
Chris
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: Thursday, September 30, 2010 2:41 AM
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (dos attacks)
Yes, it certainly can.
Regards,
Peter.
Christopher Dolan wrote:
> private void readObject(ObjectInputStream in) {
> new Runnable() {
> public void run() {
> while (true)
> new Thread(this).start();
> }
> }.run();
> }
>
> At 1MB of stack RAM per thread, this will thrash most machines in no
> time. Can a SecurityManager block thread creation?
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Wednesday, September 29, 2010 3:58 PM
> To: river-dev@incubator.apache.org
> Subject: Re: Towards Internet Jini Services (dos attacks)
>
> Zoltan Juhasz wrote:
>
>> Sim,
>>
>> I think the important danger in Jini is the use of objects. In simple
>> messaging communication (especially if non-binary), you don't have to
>>
> worry
>
>> about objects. In Jini, any method can take and object as a parameter
>>
> that
>
>> results in serialisation and unmarshalling at the receiver end. When
>>
> an
>
>> object has something nasty executing during within the readObject()
>>
> method,
>
>> it's too late to do anything.
>>
>
> This was a big problem in the days of single core, not as bad now.
> Perhaps we need a software watchdog? Or an easy way to kill and
> quarantine a misbehaving service? Or an unmarshalling executor thread
> pool, which passes the object after it has been deserialized.
>
>
Re: Towards Internet Jini Services (dos attacks)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Yes, it certainly can.
Regards,
Peter.
Christopher Dolan wrote:
> private void readObject(ObjectInputStream in) {
> new Runnable() {
> public void run() {
> while (true)
> new Thread(this).start();
> }
> }.run();
> }
>
> At 1MB of stack RAM per thread, this will thrash most machines in no
> time. Can a SecurityManager block thread creation?
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Wednesday, September 29, 2010 3:58 PM
> To: river-dev@incubator.apache.org
> Subject: Re: Towards Internet Jini Services (dos attacks)
>
> Zoltan Juhasz wrote:
>
>> Sim,
>>
>> I think the important danger in Jini is the use of objects. In simple
>> messaging communication (especially if non-binary), you don't have to
>>
> worry
>
>> about objects. In Jini, any method can take and object as a parameter
>>
> that
>
>> results in serialisation and unmarshalling at the receiver end. When
>>
> an
>
>> object has something nasty executing during within the readObject()
>>
> method,
>
>> it's too late to do anything.
>>
>
> This was a big problem in the days of single core, not as bad now.
> Perhaps we need a software watchdog? Or an easy way to kill and
> quarantine a misbehaving service? Or an unmarshalling executor thread
> pool, which passes the object after it has been deserialized.
>
>
RE: Towards Internet Jini Services (dos attacks)
Posted by Christopher Dolan <ch...@avid.com>.
private void readObject(ObjectInputStream in) {
new Runnable() {
public void run() {
while (true)
new Thread(this).start();
}
}.run();
}
At 1MB of stack RAM per thread, this will thrash most machines in no
time. Can a SecurityManager block thread creation?
Chris
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: Wednesday, September 29, 2010 3:58 PM
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (dos attacks)
Zoltan Juhasz wrote:
> Sim,
>
> I think the important danger in Jini is the use of objects. In simple
> messaging communication (especially if non-binary), you don't have to
worry
> about objects. In Jini, any method can take and object as a parameter
that
> results in serialisation and unmarshalling at the receiver end. When
an
> object has something nasty executing during within the readObject()
method,
> it's too late to do anything.
This was a big problem in the days of single core, not as bad now.
Perhaps we need a software watchdog? Or an easy way to kill and
quarantine a misbehaving service? Or an unmarshalling executor thread
pool, which passes the object after it has been deserialized.
Re: Towards Internet Jini Services (dos attacks)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Zoltan Juhasz wrote:
> Sim,
>
> I think the important danger in Jini is the use of objects. In simple
> messaging communication (especially if non-binary), you don't have to worry
> about objects. In Jini, any method can take and object as a parameter that
> results in serialisation and unmarshalling at the receiver end. When an
> object has something nasty executing during within the readObject() method,
> it's too late to do anything.
This was a big problem in the days of single core, not as bad now.
Perhaps we need a software watchdog? Or an easy way to kill and
quarantine a misbehaving service? Or an unmarshalling executor thread
pool, which passes the object after it has been deserialized.
> We had made experiments putting an infinite
> loop into an object's default constructor (I think) and you got a 100% CPU
> load at the service side before even knowing what the object was. We had the
> solution to use certificates and only accept service invocations from
> trusted parties but this is very difficult to enforce over the Internet.
I have given this some thought too, perhaps what we need is a web of trust.
Identifying the problems is very important for solutions.
Peter.
> (or
> you have to contrain the system to a specific task that is only used by a
> closed group via the Internet).
>
> Zoltan
>
> =================================
> Dr Zoltan Juhasz
> Dept of Electrical Engineering and Information Systems
> Pannon University (formerly University of Veszprem)
> Veszprem, Hungary
>
>
>
>
>> -----Original Message-----
>> From: Sim IJskes - QCG [mailto:sim@qcg.nl]
>> Sent: 29 September 2010 10:50
>> To: river-dev@incubator.apache.org
>> Subject: Re: Towards Internet Jini Services (dos attacks)
>>
>> On 29-09-10 10:26, Zoltan Juhasz wrote:
>>
>> > and
>>
>>> unmarshalling and object movements may help DoS attacks to
>>>
>> happen, etc, etc.
>>
>> Could you explain the basic difference between RPC and
>> messaging within the context of DOS attacks?
>>
>> The only difference i see right now, is that RPC mandates an
>> ordered relation between the request- and reply messages.
>> Does this theorically create an extra opportunity for DOS attacks?
>>
>> Gr. Sim
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>>
>> _____________ NOD32 5487 (20100928) Információ _____________
>>
>> Az üzenetet a NOD32 antivirus system megvizsgálta.
>> http://www.nod32.hu
>>
>>
>>
>
>
>
Re: Towards Internet Jini Services (dos attacks)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/29/2010 03:05 PM, Zoltan Juhasz wrote:
> object has something nasty executing during within the readObject() method,
> it's too late to do anything. We had made experiments putting an infinite
> loop into an object's default constructor (I think) and you got a 100% CPU
> load at the service side before even knowing what the object was.
Zoltan, this is exactly the problem with downloading code. Downloading
code is only feasable for parties with strong trust relations.
When you execute code from another party you become responsible for the
actions of that code. You can limit the freedom of this code through the
use of policies.
Your example of the loop, is one example of where we are missing a
policy option. The amount of CPU a thread can use and the amount of
memory a thread can allocate is unlimited.
So basically you can only execute code from sources you trust. Sandbox
or no sandbox.
> We had the
> solution to use certificates and only accept service invocations from
> trusted parties but this is very difficult to enforce over the Internet. (or
> you have to contrain the system to a specific task that is only used by a
> closed group via the Internet).
Exactly. A closed user group is a group with a collective trust structure.
I'm not convinced the esthablisment of trust is impossible over the
internet. PGP is succesfull, HTTPS is successfull, although very
fragile. So lets define our new trust structure.
Gr. Sim
RE: Towards Internet Jini Services (dos attacks)
Posted by Zoltan Juhasz <ju...@irt.vein.hu>.
Sim,
I think the important danger in Jini is the use of objects. In simple
messaging communication (especially if non-binary), you don't have to worry
about objects. In Jini, any method can take and object as a parameter that
results in serialisation and unmarshalling at the receiver end. When an
object has something nasty executing during within the readObject() method,
it's too late to do anything. We had made experiments putting an infinite
loop into an object's default constructor (I think) and you got a 100% CPU
load at the service side before even knowing what the object was. We had the
solution to use certificates and only accept service invocations from
trusted parties but this is very difficult to enforce over the Internet. (or
you have to contrain the system to a specific task that is only used by a
closed group via the Internet).
Zoltan
=================================
Dr Zoltan Juhasz
Dept of Electrical Engineering and Information Systems
Pannon University (formerly University of Veszprem)
Veszprem, Hungary
> -----Original Message-----
> From: Sim IJskes - QCG [mailto:sim@qcg.nl]
> Sent: 29 September 2010 10:50
> To: river-dev@incubator.apache.org
> Subject: Re: Towards Internet Jini Services (dos attacks)
>
> On 29-09-10 10:26, Zoltan Juhasz wrote:
>
> > and
> > unmarshalling and object movements may help DoS attacks to
> happen, etc, etc.
>
> Could you explain the basic difference between RPC and
> messaging within the context of DOS attacks?
>
> The only difference i see right now, is that RPC mandates an
> ordered relation between the request- and reply messages.
> Does this theorically create an extra opportunity for DOS attacks?
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
> _____________ NOD32 5487 (20100928) Információ _____________
>
> Az üzenetet a NOD32 antivirus system megvizsgálta.
> http://www.nod32.hu
>
>