[Libevent-users] Re: [Libevent-users] Re: [Libevent-users] Security question [was: Asynchronous writes…]

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Jan 20, 2012 at 4:27 AM, Frank Schoep <frank@xxxxxxx> wrote:
> On 19 jan 2012, at 22:00, MigueL DíaZ wrote:
>> …
>> I'd second that idea. Unless you intend to use the same code/protocol you use for you inter-thread communication in a network environment, using evbuffer might be just an overkill.
>
> Thanks for the tips, Nick and Miguel – they made me rethink my application's architecture. I will be implementing the application over the course of the next few weeks and I think everything will work out just fine.
>
> There's an additional question I would like to ask. Sorry for the slightly OT, but I didn't want to start a new thread just for this one.
>
> Could libevent potentially have security problems that would enable remote code execution or denial-of-service attacks due to its event and buffer handling? Although I'm not a fan of security-by-obscurity, would hiding the server's libevent version number and/or backend (poll etc.) improve security?

As far as I know, there hasn't been a remotely exploitable security
hole in Libevent for a very long time.  That said, I can't possibly
guarantee that there would never be a security hole; that big all-caps
warning in the license is there for a reason.

It's not ordinarily easy to remotely probe which version of Libevent
somebody's running, so I assume that by "hide the version" you mean
"don't advertise the version."  Generally, I think it's better to just
assume that any exploit which can hurt some version of your program
will be tried against all versions of your program; and that early in
any development cycle, debuggability is more important than
speculative hardening that hurts debugging; but other people disagree
with me there.

As a defense-in-depth mechanism, I'd say "sure, go ahead", but IMO
you'd get more benefit against as-yet-unknown vulnerabilities with the
usual techniques, like non-executable heap/stack, randomized address
spaces, etc.

best wishes,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.