On Fri, Jan 20, 2012 at 4:27 AM, Frank Schoep <fr...@ffnn.nl> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
