[e-lang] Fwd: @RISK: Sun Java Floating-Point Value Denial of Service

[Thomas Leonard]

On 5 February 2011 13:07, Kevin Reid <kpreid at switchb.org> wrote:
> On Feb 5, 2011, at 7:22, Thomas Leonard wrote:
>
>> Even when it is fixed, there are some other similar DoS problems. For
>> example, given a remote object e.g.
>>
>>  def service {}
>>
>> a client can DoS it easily with e.g.
>>
>>  service<-__getAllegedType()<-getFQName()<-size()<-pow(2147483647)
>>
>> What can I do about this?
>
>
> DoS is out of scope for E, in general.

There are different levels of DoS, though. It seems reasonable that
code running within a vat can stop it from responding. Also, handling
a very large number of requests from clients might make it slow. But,
if the clients stop sending messages then the vat should recover, I
think.

> The best you can do in theory is arrange so that every client is
> served by a separate vat, and kill hung vats.

That doesn't sound very useful. Each client vat would need to add a
membrane between the client and the underlying vat, which would
prevent pipelining.

> In practice, we don't have the ability to kill vats yet. I was at one
> point looking into fixing this for EoJ, by allowing vats to be
> transparently started in new processes; the first step for that was
> making MetaRune.main(["--spawn"]) start a new process as it's supposed
> to. If I remember correctly. The trivial amount of work I did so far
> is available at <git://switchb.org/e-on-java>, branch rune-spawn.

I suspect that starting a new JVM for each client will introduce some
DoS issues of its own.

Can we somehow block highly expensive operations on common data types?
After all, there are already some limits (e.g. maximum CapTP message
size). I guess we'd need to ban PassByConstruction by default too.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA