Re: GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)

[endrazine <endrazine () gmail com>]

Dear list,

In case you were trying to work based on the public information :
There is an obvious stack overflow in Qualys' GHOST.c poc : the name buffer
is 10 bytes long and 900+ bytes of data are copied to it. This is
independant of the gethostbyname() overflow and isn't glibc's fault...
Totally epic PR quality information ;(

Best regards,

j-

On Tue, Jan 27, 2015 at 9:45 AM, Solar Designer <solar () openwall com> wrote:

> On Tue, Jan 27, 2015 at 09:21:32AM -0800, Michal Zalewski wrote:
> > I find it... profoundly disappointing... that we get to learn about
> > 0-days via PR agency leaks (or that external PR agencies get to know
> > about 0-days before the rest of the world - hey, sounds like a juicy
> > target).
> >
> > That said, the advisory makes up for it...
>
> I agree.  I am more concerned that PR agencies appear to have had early
> access to this information than that the information leaked to the
> public a few hours early.  When it did become public, everyone could
> proceed with their advisories, updates, etc.  But before it did, who
> knows what bad bugs with access to a PR agency's database or e-mail
> could have been doing and for how long (I hope also just another few
> hours, but I really don't know).
>
> We use PGP on the linux-distros list (the issue was first brought to
> there on January 18), but I doubt that communication between Qualys and
> their PR agency, nor within the PR agency, was similarly encrypted.
> Perhaps they were using some Word "documents" and stuff.  And even if it
> were encrypted, notifying a PR agency early goes beyond need-to-know
> from everyone else's security perspective.
>
> Unfortunately, that's how PR agencies work, they want some "warm up"
> time.  I think the only solution for companies like Qualys is to not try
> to reap the usual PR benefits from this type of findings.  Have their
> technical folks disclose to the proper technical channels instead, and
> do not issue a formal press release - well, or do it a few days later,
> referring not so much to the actual findings, but to how well the
> company worked with the infosec community.  This would be better PR,
> too, at least within the smaller but highly relevant infosec community.
>
> Of course, personally I would not care about some company's PR, but I
> realize that many companies do care and this affects the resources they
> put into analyzing vulnerabilities (as you say, "the advisory makes up
> for it").  Hence my thinking of a workaround above.
>
> Alexander