#229 thrown errors do denial of service

local elib (53)

This is probably not worth fixing. But I include it
for completeness from the security review. Markm is
encouraged to close this without modifying code, unless
there is an easy obvious fix.

However, if an error is thrown during processing of
some task, this is not caught by the E run-queue
servicing routine (errors cannot be caught by E code),
and hence the error will terminate the Vat. This means
that malicious code might be able to kill the
containing Vat, perhaps by calling some Java code and
tricking it into throwing an error. This is a
denial-of-service attack. Of course, in E
denial-of-service attacks are out of scope, but we
thought we would mention this unexpected property
anyway for completeness.


Comment Date By
The problematic state is 'TraceMessage.object'. This is
only stringified in
'TraceMessageStringifier.toString(TraceMessage)', so we
only needed to fix it in one place. The fix is as
previously described: a guarding try/catch which prints
something whose success at printing isn't dependent on
user code:

buffer.append("*** nested exception " + nest.getClass() +
" tracing a " + message.object.getClass());
2002-Jun-23 19:21 markm
Actually, this danger is more subtle than it appears at
first. (During the review, if I recall, we didn't dive
as deep into this part of the implementation as I just
have.) The two subclasses of Runner are BERunner and
FERunner. BERunner's run method protects the
"todo.run();" with a try/catch which prints out the
exception object by invoking the trace system. When
using the FERunner, the FERunnerEvent guard the
"todo.run();" in the same manner.

The TraceMessageStringifier#toString(TraceMessage)
method is where the throwable actually gets
stringified, and where a resulting thrown exception
could both halt the run loop and prevent the logging of
why. This method should be enhanced with a guarding
try/catch, as should all places in the trace package
where a bad stringification could prevent tracing. So
with this new understanding of the problem, I'm upping
the priority of this bug and reclassifying it.
2002-Mar-16 21:35 markm


  • Steve Jenson

    Steve Jenson - 2005-07-18
    • status: open --> open-fixed
  • Steve Jenson

    Steve Jenson - 2005-07-18
    • status: open-fixed --> closed-fixed
  • Mark Samuel Miller

    • assigned_to: nobody --> caplet

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks