[Bug network/18665] In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer (CVE-2015-7547)

["fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18665

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #8 from Frank Ch. Eigler <fche at redhat dot com> ---
At some sites, a systemtap-based band-aid for this bug may be suitable as a
temporary workaround.  The following script interposes at an interior point in
the stub resolver, redirecting T_UNSPEC to T_A queries.  This corresponds to
the "do not use AF_UNSPEC" mitigating factor from Carlos' email posting, which
Florian and Carlos confirmed should also work for TCP.

It requires systemtap of course, and debuginfo for the version(s) of glibc's
libresolv.so.  So on a Fedora machine, run "# debuginfo-install glibc", and
repeat for the secondary architecture glibc if installed.  (e.g.,
glibc-debuginfo*.i686 and glibc-debuginfo*.x86_64).

Then, adjusting /lib*/ to the path or wildcard-path where libresolv may be
found:

# stap -g -e '
global T_UNSPEC = 62321
global T_A = 1
probe process("/lib*/libresolv.so.*").function("__libc_res_nquery")
{ 
  if ($type == T_UNSPEC ) { $type = T_A }
}
'

will instantly, system-wide, quietly perform this single mitigation, as long as
the systemtap script remains running.  For example, but bug18665 test program
runs to completion instead of suffering the SEGV.  (Add stap -v or -t and/or
printf() statements to trace the mitigation's operation.)

Please test it carefully before deploying it seriously, and remember, it's
meant only as a temporary band-aid, until a glibc update is fully deployed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.