Date: Tue, 27 Jan 2015 14:03:10 -0800 From: endrazine <endrazine@...il.com> To: oss-security@...ts.openwall.com Cc: Qualys Security Advisory <qsa@...lys.com> Subject: Re: GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235) 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@...nwall.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 >
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.