[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On Fri, Jan 20, 2012 at 11:17 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> 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.

To be clear, even though you asked about issues with the event loop
and buffer stuff: there have been (and probably are some remaining)
DOS issues in evhttp.  In the longer term, I'm hoping it'll be
possible to migrate folks towards Mark Ellzey's libevhtp  for their
libevent+http needs.

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