R: [oss-security] GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)

[linkbc02 <linkbc02 () outlook com>]

Hi,
Dovecot: It seems that libdovecot-storage.so can be triggered and you can read the core dump

imap[29914]: segfault at 0 ip 00007f1e525263a0 sp 00007fffaeed7818
 error 4 in libdovecot-storage.so.0.0.0[7f1e5249e000+10f000]

|-----Messaggio originale-----
|Da: Florian Weimer [mailto:fweimer () redhat com]
|Inviato: venerdì 30 gennaio 2015 10:19
|A: oss-security () lists openwall com
|Oggetto: Re: [oss-security] GHOST gethostbyname() heap overflow in glibc
|(CVE-2015-0235)
|
|On 01/29/2015 05:00 PM, Paul Pluzhnikov wrote:
|> On Thu, Jan 29, 2015 at 4:09 AM, Hanno Böck <hanno () hboeck de> wrote:
|>
|>> And yes: I'd like people to cry alarm every time they see a buffer
|>> overflow in glibc or any other core lib.
|>
|> What is the appropriate forum to cry alarm on?
|
|It depends on whether you want to do it publicly.  For the public case,
|you can post either on libc-alpha or here, with an appropriate subject,
|and people will pick it up.
|
|As described here,
|
|  <https://sourceware.org/glibc/wiki/Security%20Process>
|
|glibc relies on downstreams for confidential security bug handling, so
|that's another option.
|
|The eventual goal is to flag all security bugs as security+ in the glibc
|Bugzilla, but we are not quite there yet.  Both historic bugs still
|await analysis, and there are some remaining tough calls.  The next step
|after that work is complete will be to track down already-assigned CVEs
|and deal with the remaining missing ones.  To my knowledge, there are no
|major issues among those, but it is always difficult to predict what
|applications do with such a low-level library.
|
|Apparently, we also have historic security-relevant commits without
|corresponding Bugzilla bugs.  This dates back to the time before glibc
|switched to a more collaborative/consensus-based development model.  The
|current policy is that all user-visible changes need Bugzilla bugs.  I
|don't know what to do about those stealth commits.
|
|--
|Florian Weimer / Red Hat Product Security