On Thu, 2005-06-23 at 19:39 +0200, Sebastien Raveau wrote:
> On Thursday 23 June 2005 18:58, Guy Harris wrote:
> > Sebastien Raveau wrote:
> > > That may help a bit, but buffer overflows are not the cause of most
> > > security flaws. Let me quote Theo de Raadt (maintainer of OpenBSD) on
> > > this:
> > >
> > > "Crispin Cowan has suggested that buffer overflows are the most common
> > > security causing programmer error. I disagree. I believe that we found
> > > more /tmp races in our source tree than buffer overflows."
> >
> > ...and we've found more buffer overflows than /tmp races in our code
> > (the only /tmp race we know of was "fixed" a long time ago by the
> > OpenBSD folks in a fashion that broke captures; we fixed it differently).
> >
> > I.e., whether /tmp races, buffer overflows, or other problems are the
> > main source of security flaws in a particular piece of code depends on
> > the code. If the code has lots of static buffers into which stuff is
> > read, and not a lot of manipulation of files in /tmp, buffer overflows
> > are likely to be a bigger problem.
>
> Yeah, I know what a buffer overflow is ;)
>
> But nowadays too many people think all security flaws are buffer overflows...
> My point wasn't to discard Radek's suggestion, it was just to say that it
> won't miraculously solve _all_ Ethereal's security problems :)
I'm not saying that PIE will magically solve all security flaws. But I
can imagine an exploit for Ethereal that works on Linux because it
manages (fluke) to get around exec-shield segmentation limit and uses
shellcode stored in a global (and Mark J. Cox from our Security Response
Team has got one) If Ethereal was PIE this exploit would have not worked
without brute-force.
> > In any case, we agree that, as not all systems are as nice as BSD in
> > this regard, the rest of the code shouldn't run with root privileges if
> > the code that opens the capture device does need to run with root
> > privileges. This is a work in progress; see
> >
> > http://wiki.ethereal.com/Development_2fPrivilegeSeparation
>
> Yeah, that's what I am talking about :)
>
> Don't be angry at me for criticizing a lot ;) I know that the Ethereal project
> has started before security became a real issue, and that it is difficult to
> remodel that big a project now. I am just suggesting ideas to the
> mailing-list, and if I had time - believe me - I would be more than happy to
> implement them myself in Ethereal.
>
This sounds good and would make Ethereal more secure in users and also
developers view. Lately there was a discussion on Red Hat side about
dropping ethereal from Enteprise due to its security flaws. Forcing
customer to update ethereal almost every month doesn't look very good. I
didn't agree about dropping it cos it's handy having this tool available
for debugging network issues. There are others, but none quite so
easy to use to interpret the network traffic.
br
Radek
--
Radek Vokál <rvokal@xxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
