monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: [Monotone-devel] encrypted monotone (and digression on


From: Nuno Lucas
Subject: Fwd: [Monotone-devel] encrypted monotone (and digression on
Date: Mon, 10 Jul 2006 22:10:04 +0100

Wrong reply button...

---------- Forwarded message ----------
From: Nuno Lucas <address@hidden>
Date: Jul 10, 2006 10:08 PM
Subject: Re: [Monotone-devel] encrypted monotone (and digression on
To: Rob Schoening <address@hidden>


On 7/10/06, Rob Schoening <address@hidden> wrote:
I have a somewhat unrelated question that touches on a more fundamental
security issue:

what is the relative security risk of running netsync on a public port
assuming it's running as a non privileged user?  how much of a vulnerability
is it for the host that's serving it?

Any network server, even running as an unpreviledged user has it's
risks, because as soon as someone can run code on the server (by means
of program bugs) the chance of breaking it gets higher astronomically
(there can always be other programs running local on the server with
it's own bugs or even kernel bugs that allow a previledge escalation).

So, the risks are the same as any other server program, except the
fact you can (in theory) trust more other more stable programs than
the in-developing-phase monotone binaries.

it is, of course, relatively simple today to deploy mtn on a private port
and use SSH port forwarding to access it which all but eliminates this
problem. Or, eventually, one could use "mtn dumb" over SSH.

I believe that is the right answer if your data is of great value for
you, but I'll let others confirm this.

but my question is really: how vulnerable is "mtn serve" today to DoS and
buffer overrun type exploits?

The only defense against DoS attacks is you having more bandwidth than
your attacker so monotone can't do nothing against this. It's true,
though, that monotone heavy CPU usage makes it a bit more vulnerable
on this field.

Buffer overruns are program errors, so the only answer is either build
monotone with the gcc hardened options to avoid this (not 100% full
proof against all errrors, but can help a *lot*)  or peruse the source
code until you are certain there aren't any.

RS

Best regards,
~Nuno Lucas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]