Hmmm, from what I vaguely recall from my software engineering days, was that memcpy() didn't ever handle overlapped memory buffers and that you should consider memmove() in such cases.
Doesn't really make sense that it should, though I think I first learned about this during a code review. Don't recall if I had lazily used it once or if it was something an intern had done, but it was a co-worker that had caught it. On 01/13/14 13:13, Michael McNally wrote: > Hello, Bind-Users Readers -- > > Since you are all subscribers to bind-announce as well [You are, > aren't you? It's where we make announcements about security > vulnerabilities and about new versions of BIND] you are probably > already aware that ISC has announced CVE-2014-0591, a vulnerability > which can cause BIND to crash while servicing certain queries against > an NSEC3-signed zone. > > The official announcements can be found in bind-announce or at: > https://kb.isc.org/article/AA-01078 and new versions of BIND which > patch the vulnerability can be found at http://www.isc.org/downloads > > But we'd like to point out a few additional facts about this advisory > which you might find relevant. > > 1) Security Patches Are Ending for the BIND 9.6-ESV Branch > > Back in 2012 we announced our intention to retire the > 9.6-ESV branch in 2013. We previously extended the > EOL ("End of Life") date for 9.6-ESV by six months but > those six months are almost over and the rescheduled > EOL date for 9.6-ESV is upon us. Unless there are > extraordinary circumstances justifying it, 9.6-ESV will > not receive future security patches and 9.6-ESV-R11 is > the last version planned in the 9.6-ESV sequence. > > BIND 9.9 was designated an ESV version of BIND in May 2013. > Users who require long-term support for their version of > BIND should migrate to BIND 9.9. > > 2) Vulnerability to CVE-2014-0591 is OS and libc Dependent > > We have issued a general warning for the bug that causes > CVE-2014-0591, because with security it is better to be > safe than sorry, but per our developer's analysis, the > bug (which causes an INSIST crash in name.c) can only be > triggered on servers using a memcpy call that behave in a > certain fashion. This bug went undiscovered until recently > because under most memcpy implementations the software > behaves safely. However, recent optimizations to glibc's > memcpy have exposed the underlying bug on systems using > newer versions of glibc. > > To date our reports of CVE-2014-0591 crashes have all > been from Linux users using glibc version 2.18, but because > of the multiplicity of Unix-like operating systems and > C library variants we cannot represent all others as safe. > The safest course of action is to patch the underlying bug > and ensure that your server is not vulnerable regardless of > memcpy optimizations, but we do believe that users are unlikely > to encounter this crash on older glibc versions or on > non-Linux operating systems that do not use glibc. > > Slightly more information about this is available in our > CVE-2014-0591 FAQ and Supplemental Information article in > the ISC Knowledge Base: https://kb.isc.org/article/AA-01085 > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
