Re: nmap segfault fix
> You mean to tell us that nmap is currently segfaulting for an industry No, it is not segfaulting, and it is not exploitable. Our libc contains a feature to detect backwards memcpy, in that case it logs and KILLS THE PROCESS dead. There is no way to consider this a risk. The problem here is that nmap had a bug like this, in this decade. The other problem is that dynamic checks, and static checks, didn't find a problem which is so visible before it shipped.
Re: nmap segfault fix
This is very funny... You mean to tell us that nmap is currently segfaulting for an industry, based on the fact that there's a license disagreement in the forums? I'm just realizing the extent of this convenient glitch for ATP groups. Lots of security products depend on nmap out there. Myself, I can't even get it to successfully ping a host, even though ping works just fine from the same environment. "nmap: backwards memcpy" when doing the simplest scans. We need this patched asap guys. Please accept the commit. Everybody at nmap agrees that Kernel inclusion is all good, it is part of their intentions to maintain this working relationship. Their license disagreement has to do with blocking miscreants from repackaging nmap with exploits and trojans. Let's not get into punctuation fights over legaleeze? Pretty please? Nmap not working as advertised in the base packages is a problem for society. Lots of noobs can't manually patch software as part of their full-time jobs. -Original Message- From: owner-po...@openbsd.org On Behalf Of Theo Buehler Sent: Tuesday, October 12, 2021 9:54 AM To: JR Aquino ; g...@theobuehler.org Cc: Stuart Henderson ; Niklas Hallqvist ; OpenBSD ports Subject: Re: nmap segfault fix On Tue, Oct 12, 2021 at 07:50:51AM -0700, JR Aquino wrote: > Hello again Theo, just validating to see if the commit is pending any > further actions, or if it's just in the queue. I committed this about a week ago to both 7.0-stable and to -current: https://marc.info/?l=openbsd-ports-cvs=163341124813856=2 https://marc.info/?l=openbsd-ports-cvs=163341147513940=2
Re: nmap segfault fix
The mail you replied to explicitly said that the changes discussed in this thread were committed... > Myself, I can't even get it to successfully ping a host, even though > ping works just fine from the same environment. I don't have this problem. > "nmap: backwards memcpy" when doing the simplest scans. Please provide some examples and leave out all the useless noise.
Re: nmap segfault fix
On Tue, Oct 12, 2021 at 07:50:51AM -0700, JR Aquino wrote: > Hello again Theo, just validating to see if the commit is pending any > further actions, or if it's just in the queue. I committed this about a week ago to both 7.0-stable and to -current: https://marc.info/?l=openbsd-ports-cvs=163341124813856=2 https://marc.info/?l=openbsd-ports-cvs=163341147513940=2
Re: nmap segfault fix
Hello again Theo, just validating to see if the commit is pending any further actions, or if it's just in the queue. Thanks! -JR On Fri, Oct 1, 2021 at 8:12 AM JR Aquino wrote: > Thanks Theo, I hadn't caught the update to extend the prior license to > include 7.92. > > I'll separately work on getting 7.92 functional later next week. > > > On Wed, Sep 29, 2021 at 10:30 AM Theo Buehler wrote: > >> On Wed, Sep 29, 2021 at 05:45:06PM +0100, Stuart Henderson wrote: >> > The version of nmap in ports is the last one under the old licence. I'd >> like >> > if someone who knows about such things could review the new nmap licence >> > before we start taking diffs from anything newer (we might want to stop >> > distributing packages). >> >> After some Linux distributions pushed back and even rolled back to >> 7.80, the 7.92 release (which includes this fix) is also released under >> the nmap-v7.80 license. >> >> https://nmap.org/npsl/ states >> >> To ease the transition to the NPSL, the first three Nmap releases made >> under that license (Nmap 7.90, 7.91, and 7.92) may also be used under >> the previous Nmap license terms by anyone who prefers those. >> >> I'll bump the comment in the Makefile to 7.92 >> >> See also https://github.com/nmap/nmap/issues/2199#issuecomment-894812634 >> >
Re: nmap segfault fix
Thanks Theo, I hadn't caught the update to extend the prior license to include 7.92. I'll separately work on getting 7.92 functional later next week. On Wed, Sep 29, 2021 at 10:30 AM Theo Buehler wrote: > On Wed, Sep 29, 2021 at 05:45:06PM +0100, Stuart Henderson wrote: > > The version of nmap in ports is the last one under the old licence. I'd > like > > if someone who knows about such things could review the new nmap licence > > before we start taking diffs from anything newer (we might want to stop > > distributing packages). > > After some Linux distributions pushed back and even rolled back to > 7.80, the 7.92 release (which includes this fix) is also released under > the nmap-v7.80 license. > > https://nmap.org/npsl/ states > > To ease the transition to the NPSL, the first three Nmap releases made > under that license (Nmap 7.90, 7.91, and 7.92) may also be used under > the previous Nmap license terms by anyone who prefers those. > > I'll bump the comment in the Makefile to 7.92 > > See also https://github.com/nmap/nmap/issues/2199#issuecomment-894812634 >
nmap segfault fix
Hi!
While testing 7.0 packages I got an nmap segfault. It has been fixed
upstream in their github, but I don't know if it's part of any release yet.
However their fix may be incomplete as there are other opportunities for
a negative buffer overflow in nmap_dns.cc, at least without knowing all
callers of the ptrToIp method.
I attach a patch that works for me (tm) as well as a patch to add a
debug package for nmap, which was needed for me to debug this issue.
Even if its too late for 7.0, at least the segfault fix might make
7.0-stable package, I reckon.
The fault is indeterministic, and triggered by a PTR name being aligned
at the beginning of a page immediately preceded by an unmapped page.
The case which triggers it fairly often for me was just a nmap of a
single TCP port over some seven or so /24-networks.
/Niklas
commit 550c8a099e5eb1189e26f8868927c7b5cba950f2
Author: niklas
Date: Tue Sep 28 14:49:55 2021 +0200
Avoid careless dereferences outside the domain name buffer
diff --git a/net/nmap/patches/patch-nmap_dns_cc b/net/nmap/patches/patch-nmap_dns_cc
new file mode 100644
index 000..45e74a3e735
--- /dev/null
+++ b/net/nmap/patches/patch-nmap_dns_cc
@@ -0,0 +1,42 @@
+$OpenBSD$
+
+Avoid careless dereferences outside the domain name buffer.
+
+Index: nmap_dns.cc
+--- nmap_dns.cc.orig
nmap_dns.cc
+@@ -1352,7 +1352,7 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ memset(, 0, sizeof(sockaddr_storage));
+
+ // Check whether the name ends with the IPv4 PTR domain
+- if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
++ if (ptr.length() >= sizeof(C_IPV4_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
+ {
+ struct sockaddr_in *ip4 = (struct sockaddr_in *)
+ u8 place_value[] = {1, 10, 100};
+@@ -1361,7 +1361,7 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ size_t i = 0;
+
+ p--;
+-while (i < sizeof(ip4->sin_addr.s_addr))
++while (p >= cptr && i < sizeof(ip4->sin_addr.s_addr))
+ {
+ if (*p == '.')
+ {
+@@ -1387,14 +1387,14 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ ip.ss_family = AF_INET;
+ }
+ // If not, check IPv6
+- else if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
++ else if (ptr.length() >= sizeof(C_IPV6_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
+ {
+ struct sockaddr_in6 *ip6 = (struct sockaddr_in6 *)
+ u8 alt = 0;
+ size_t i=0;
+
+ p--;
+-while (i < sizeof(ip6->sin6_addr.s6_addr))
++while (p >= cptr && i < sizeof(ip6->sin6_addr.s6_addr))
+ {
+ if (*p == '.')
+ {
commit f2aafb4430c0150d70926e3277d0d816805111cb
Author: niklas
Date: Tue Sep 28 14:49:06 2021 +0200
Make debug packages
diff --git a/net/nmap/Makefile b/net/nmap/Makefile
index ff8db3d7594..c1752ffef46 100644
--- a/net/nmap/Makefile
+++ b/net/nmap/Makefile
@@ -33,6 +33,7 @@ MODULES= lang/python \
lang/lua
MODPY_VERSION= ${MODPY_DEFAULT_VERSION_2}
+DEBUG_PACKAGES= ${BUILD_PACKAGES}
CONFIGURE_STYLE=autoconf
AUTOCONF_VERSION=2.69
Re: nmap segfault fix
On Wed, Sep 29, 2021 at 05:45:06PM +0100, Stuart Henderson wrote: > The version of nmap in ports is the last one under the old licence. I'd like > if someone who knows about such things could review the new nmap licence > before we start taking diffs from anything newer (we might want to stop > distributing packages). After some Linux distributions pushed back and even rolled back to 7.80, the 7.92 release (which includes this fix) is also released under the nmap-v7.80 license. https://nmap.org/npsl/ states To ease the transition to the NPSL, the first three Nmap releases made under that license (Nmap 7.90, 7.91, and 7.92) may also be used under the previous Nmap license terms by anyone who prefers those. I'll bump the comment in the Makefile to 7.92 See also https://github.com/nmap/nmap/issues/2199#issuecomment-894812634
Re: nmap segfault fix
The version of nmap in ports is the last one under the old licence. I'd like if someone who knows about such things could review the new nmap licence before we start taking diffs from anything newer (we might want to stop distributing packages). -- Sent from a phone, apologies for poor formatting. On 29 September 2021 16:50:22 JR Aquino wrote: Thanks Niklas! The patches apply, build, and run cleanly. The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but we should revisit it in the future with any new upstream releases in case there are subtle changes from what is in their github repo today. Unless anyone else has strong opinions, I'm good with the patches and would like to ask another port maintainer with CVS privileges to review and commit. -JR On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist wrote: Hi! While testing 7.0 packages I got an nmap segfault. It has been fixed upstream in their github, but I don't know if it's part of any release yet. However their fix may be incomplete as there are other opportunities for a negative buffer overflow in nmap_dns.cc, at least without knowing all callers of the ptrToIp method. I attach a patch that works for me (tm) as well as a patch to add a debug package for nmap, which was needed for me to debug this issue. Even if its too late for 7.0, at least the segfault fix might make 7.0-stable package, I reckon. The fault is indeterministic, and triggered by a PTR name being aligned at the beginning of a page immediately preceded by an unmapped page. The case which triggers it fairly often for me was just a nmap of a single TCP port over some seven or so /24-networks. /Niklas
Re: nmap segfault fix
On Wed, Sep 29, 2021 at 09:10:14AM -0700, JR Aquino wrote:
> How about now?
Thanks, that's better.
I think the part of the diff which is the upstream fix is simple enough
that we do not need to worry about the license.
I'll land this in -current once the tree unlocks and will also land it
in 7.0-stable.
Index: Makefile
===
RCS file: /cvs/ports/net/nmap/Makefile,v
retrieving revision 1.140
diff -u -p -r1.140 Makefile
--- Makefile20 Jul 2021 22:28:24 - 1.140
+++ Makefile29 Sep 2021 16:36:20 -
@@ -7,6 +7,7 @@ MODPY_EGG_VERSION= 7.91
DISTNAME= nmap-${MODPY_EGG_VERSION}
PKGNAME-main= ${DISTNAME}
PKGNAME-zenmap=nmap-zenmap-${MODPY_EGG_VERSION}
+REVISION= 0
CATEGORIES=net security
MASTER_SITES= ${HOMEPAGE}/dist/
@@ -33,6 +34,7 @@ MODULES= lang/python \
lang/lua
MODPY_VERSION= ${MODPY_DEFAULT_VERSION_2}
+DEBUG_PACKAGES=${BUILD_PACKAGES}
CONFIGURE_STYLE=autoconf
AUTOCONF_VERSION=2.69
Index: patches/patch-nmap_dns_cc
===
RCS file: patches/patch-nmap_dns_cc
diff -N patches/patch-nmap_dns_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-nmap_dns_cc 29 Sep 2021 16:35:25 -
@@ -0,0 +1,44 @@
+$OpenBSD$
+
+Avoid careless dereferences outside the domain name buffer.
+Part of this is
+https://github.com/nmap/nmap/commit/3adaa69cb211b00f9bfc66263a56cbd87cc9e521
+
+Index: nmap_dns.cc
+--- nmap_dns.cc.orig
nmap_dns.cc
+@@ -1352,7 +1352,7 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ memset(, 0, sizeof(sockaddr_storage));
+
+ // Check whether the name ends with the IPv4 PTR domain
+- if (NULL != (p = strcasestr(cptr + ptr.length() + 1 -
sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
++ if (ptr.length() >= sizeof(C_IPV4_PTR_DOMAIN) - 1 && NULL != (p =
strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN),
C_IPV4_PTR_DOMAIN)))
+ {
+ struct sockaddr_in *ip4 = (struct sockaddr_in *)
+ u8 place_value[] = {1, 10, 100};
+@@ -1361,7 +1361,7 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ size_t i = 0;
+
+ p--;
+-while (i < sizeof(ip4->sin_addr.s_addr))
++while (p >= cptr && i < sizeof(ip4->sin_addr.s_addr))
+ {
+ if (*p == '.')
+ {
+@@ -1387,14 +1387,14 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ ip.ss_family = AF_INET;
+ }
+ // If not, check IPv6
+- else if (NULL != (p = strcasestr(cptr + ptr.length() + 1 -
sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
++ else if (ptr.length() >= sizeof(C_IPV6_PTR_DOMAIN) - 1 && NULL != (p =
strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN),
C_IPV6_PTR_DOMAIN)))
+ {
+ struct sockaddr_in6 *ip6 = (struct sockaddr_in6 *)
+ u8 alt = 0;
+ size_t i=0;
+
+ p--;
+-while (i < sizeof(ip6->sin6_addr.s6_addr))
++while (p >= cptr && i < sizeof(ip6->sin6_addr.s6_addr))
+ {
+ if (*p == '.')
+ {
Re: nmap segfault fix
How about now? -JR On Wed, Sep 29, 2021 at 8:59 AM Theo Buehler wrote: > On Wed, Sep 29, 2021 at 08:49:06AM -0700, JR Aquino wrote: > > Thanks Niklas! > > > > The patches apply, build, and run cleanly. > > The patches did not make it to the list. > > > > > The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but > > we should revisit it in the future with any new upstream releases in case > > there are subtle changes from what is in their github repo today. > > > > Unless anyone else has strong opinions, I'm good with the patches and > would > > like to ask another port maintainer with CVS privileges to review and > > commit. > > > > -JR > > > > On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist > wrote: > > > > > Hi! > > > > > > While testing 7.0 packages I got an nmap segfault. It has been fixed > > > upstream in their github, but I don't know if it's part of any release > yet. > > > > > > However their fix may be incomplete as there are other opportunities > for > > > a negative buffer overflow in nmap_dns.cc, at least without knowing all > > > callers of the ptrToIp method. > > > > > > I attach a patch that works for me (tm) as well as a patch to add a > > > debug package for nmap, which was needed for me to debug this issue. > > > > > > Even if its too late for 7.0, at least the segfault fix might make > > > 7.0-stable package, I reckon. > > > > > > The fault is indeterministic, and triggered by a PTR name being aligned > > > at the beginning of a page immediately preceded by an unmapped page. > > > The case which triggers it fairly often for me was just a nmap of a > > > single TCP port over some seven or so /24-networks. > > > > > > /Niklas > > > > buf-oflow-fix.patch Description: Binary data nmap-debug.patch Description: Binary data
Re: nmap segfault fix
On Wed, Sep 29, 2021 at 08:49:06AM -0700, JR Aquino wrote: > Thanks Niklas! > > The patches apply, build, and run cleanly. The patches did not make it to the list. > > The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but > we should revisit it in the future with any new upstream releases in case > there are subtle changes from what is in their github repo today. > > Unless anyone else has strong opinions, I'm good with the patches and would > like to ask another port maintainer with CVS privileges to review and > commit. > > -JR > > On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist wrote: > > > Hi! > > > > While testing 7.0 packages I got an nmap segfault. It has been fixed > > upstream in their github, but I don't know if it's part of any release yet. > > > > However their fix may be incomplete as there are other opportunities for > > a negative buffer overflow in nmap_dns.cc, at least without knowing all > > callers of the ptrToIp method. > > > > I attach a patch that works for me (tm) as well as a patch to add a > > debug package for nmap, which was needed for me to debug this issue. > > > > Even if its too late for 7.0, at least the segfault fix might make > > 7.0-stable package, I reckon. > > > > The fault is indeterministic, and triggered by a PTR name being aligned > > at the beginning of a page immediately preceded by an unmapped page. > > The case which triggers it fairly often for me was just a nmap of a > > single TCP port over some seven or so /24-networks. > > > > /Niklas > >
Re: nmap segfault fix
Thanks Niklas! The patches apply, build, and run cleanly. The fix makes sense to incorporate in our OpenBSD port for nmap 7.91, but we should revisit it in the future with any new upstream releases in case there are subtle changes from what is in their github repo today. Unless anyone else has strong opinions, I'm good with the patches and would like to ask another port maintainer with CVS privileges to review and commit. -JR On Wed, Sep 29, 2021 at 8:37 AM Niklas Hallqvist wrote: > Hi! > > While testing 7.0 packages I got an nmap segfault. It has been fixed > upstream in their github, but I don't know if it's part of any release yet. > > However their fix may be incomplete as there are other opportunities for > a negative buffer overflow in nmap_dns.cc, at least without knowing all > callers of the ptrToIp method. > > I attach a patch that works for me (tm) as well as a patch to add a > debug package for nmap, which was needed for me to debug this issue. > > Even if its too late for 7.0, at least the segfault fix might make > 7.0-stable package, I reckon. > > The fault is indeterministic, and triggered by a PTR name being aligned > at the beginning of a page immediately preceded by an unmapped page. > The case which triggers it fairly often for me was just a nmap of a > single TCP port over some seven or so /24-networks. > > /Niklas >
