Hello! On Fri, Nov 25, 2005 at 01:56:39PM -0700, Theo de Raadt wrote: >> One utility I'm used to using for monitoring is Ethereal. I've seen all >> of the comments from the OpenBSD user community and understand why it's >> no longer available through ports. Does anyone know of a similar tool >> that will work well with OpenBSD and is also secure? I need more >> information in human readably form that I can get from tcpdump or >> sniffit.
>It is super dangerous. It went through a period of I think about 30 >remote code running bugs in a few months, but bugs are always being >found. > >It is very difficult to write 100% correct packet parsing code. Errors >will be made. And exactly where you cannot afford them. >For this reason, we audited tcpdump. Then we realized that errors would >still be made, and we then privilege seperated it, so that the nasty >code runs in a jail. >The same approach could be taken by other projects towards their code, >but yes, it is a fairly difficult chunk of code to write. >In general we supply our user community with any tool they might want. >But ethereal was becoming something so often used, so often used poorly, >and so often used without any awareness as to how great the risk was. >We felt we had to do something, and thus we deleted it. >You can compile it up yourself. >Right now, though, it is amongst the most dangerous pieces of software >people are running. >It is your choice.. I don't appreciate code with so many holes either. But... If one runs ethereal off-line, as non-privileged user, I guess exploiting that will be more difficult on OpenBSD than on other platforms, because on OpenBSD one will at least have the benefits of the generic exploit mitigation techniques in OpenBSD - memory randomization (malloc, shared library loading), propolice, etc. The user could add systrace into the mix, and chroot. But... One has to be knowledgeable to do the latter well. So if *I* really needed it, I'd do it that way: compiling it myself, knowing that I'm on my own, but trying to do the best I know to reduce the risk, including making a restrictive systrace policy, probably using the interactive policy creation tools, especially giving the process no permission to write files and no permission to do anything on the network. But... You're on your own, and chances are still that you get things wrong, so don't blame anyone else for taking that risk. Kind regards, Hannah.
