daily CVS update output
Updating src tree: P src/distrib/notes/common/main P src/distrib/sets/makesrctars P src/distrib/sets/lists/comp/mi P src/distrib/sets/lists/tests/mi P src/etc/mtree/NetBSD.dist.tests cvs update: cannot open directory /cvsroot/src/external/bsd/bind/dist/libtool.m4: No such file or directory cvs update: skipping directory src/external/bsd/bind/dist/libtool.m4 P src/external/bsd/nvi/dist/common/conv.c P src/external/bsd/nvi/dist/regex/engine.c P src/external/bsd/nvi/dist/regex/regcomp.c P src/external/bsd/nvi/dist/regex/regerror.c P src/external/bsd/nvi/dist/regex/regexec.c P src/external/bsd/nvi/dist/regex/regfree.c P src/external/bsd/tmux/dist/log.c P src/include/stdlib.h P src/lib/libc/stdio/fparseln.3 P src/lib/libc/stdlib/Makefile.inc P src/lib/libc/stdlib/ptsname.3 P src/lib/libc/stdlib/pty.c P src/lib/librumpuser/rumpuser_port.h P src/lib/librumpuser/rumpuser_sp.c P src/lib/librumpuser/sp_common.c P src/sbin/ifconfig/ieee80211.c P src/sbin/ifconfig/ifconfig.8 P src/share/man/man3lua/gpio.3lua P src/share/man/man3lua/syslog.3lua P src/sys/arch/sparc64/include/cpu.h P src/sys/arch/sparc64/include/sparc64.h P src/sys/arch/sparc64/sparc64/cpu.c P src/sys/arch/sparc64/sparc64/genassym.cf P src/sys/arch/sparc64/sparc64/locore.s P src/sys/arch/sparc64/sparc64/ofw_machdep.c P src/sys/arch/sparc64/sparc64/pmap.c P src/sys/dev/pci/if_wm.c P src/sys/kern/core_netbsd.c P src/sys/uvm/uvm_coredump.c P src/tests/usr.bin/Makefile U src/tests/usr.bin/vmstat/Makefile U src/tests/usr.bin/vmstat/t_vmstat.sh P src/usr.bin/m4/m4.1 Updating xsrc tree: P xsrc/external/mit/libXfont/dist/src/bitmap/bdfread.c P xsrc/xfree/xc/lib/font/bitmap/bdfread.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Wed Jan 8 03:07:32 2014 SUP Scan for current completed at Wed Jan 8 03:07:54 2014 SUP Scan for mirror starting at Wed Jan 8 03:07:54 2014 SUP Scan for mirror completed at Wed Jan 8 03:11:24 2014 Updating release-5 src tree (netbsd-5): U dist/ntp/ntpd/ntp_request.c P distrib/ews4800mips/Makefile U doc/CHANGES-5.3 P etc/ntp.conf Updating release-5 xsrc tree (netbsd-5): P external/mit/libXfont/dist/src/bitmap/bdfread.c P xfree/xc/lib/font/bitmap/bdfread.c Running the SUP scanner: SUP Scan for release-5 starting at Wed Jan 8 03:22:30 2014 SUP Scan for release-5 completed at Wed Jan 8 03:22:39 2014 Updating release-6 src tree (netbsd-6): P distrib/ews4800mips/Makefile P distrib/sparc/ramdisk/Makefile U doc/CHANGES-6.2 P etc/ntp.conf P external/bsd/ntp/dist/ntpd/ntp_request.c Updating release-6 xsrc tree (netbsd-6): P external/mit/libXfont/dist/src/bitmap/bdfread.c P xfree/xc/lib/font/bitmap/bdfread.c Running the SUP scanner: SUP Scan for release-6 starting at Wed Jan 8 03:27:47 2014 SUP Scan for release-6 completed at Wed Jan 8 03:28:00 2014 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 34230642 Jan 8 03:36 ls-lRA.gz
NetBSD Security Advisory 2014-002: ntpd used as DDoS amplifier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NetBSD Security Advisory 2014-002 = Topic: ntpd used as DDoS amplifier Version:NetBSD-current: source prior to Dec 27th, 2013 NetBSD 6.1: affected NetBSD 6.0 - 6.0.2: affected NetBSD 5.1 - 5.1.2: affected NetBSD 5.2: affected Severity: DDoS participation Fixed: NetBSD-current: Dec 27th, 2013 NetBSD-6-0 branch: Jan 6th, 2014 NetBSD-6-1 branch: Jan 6th, 2014 NetBSD-6 branch:Jan 6th, 2014 NetBSD-5-2 branch: Jan 6th, 2014 NetBSD-5-1 branch: Jan 6th, 2014 NetBSD-5 branch:Jan 6th, 2014 Teeny versions released later than the fix date will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract An administrative query function is getting used by attackers to use ntp servers as traffic amplifiers. The new version no longer offers this query option. Technical Details = The monlist function, which is available in ntp prior to 4.2.7 to requestors who are allowed to 'query', yields potentially sizeable traffic in response to a small query packet, and can thus get used for amplification attacks. Solutions and Workarounds = Workaround: in ntp.conf, setting 'restrict default noquery' will prevent amplification to random targets (the remaining targets would be those allowed to query by their own restrict entries). Note that this setting does not disallow time synchronization, but instead querying for the list of peers and other administrative and informative data. See /usr/share/doc/html/ntp/accopt.html for information on ntpd access control configuration options. Solution: Updating the ntpd binary so it no longer offers the abused function, as well as updating ntp.conf so it offers less attack surface. ntpd source: update to HEADsrc/external/bsd/ntp/dist/ntpd/ntp_request.c netbsd-6src/external/bsd/ntp/dist/ntpd/ntp_request.c 1.7.2.1 netbsd-6-1 src/external/bsd/ntp/dist/ntpd/ntp_request.c 1.7.16.1 netbsd-6-0 src/external/bsd/ntp/dist/ntpd/ntp_request.c 1.7.8.1 netbsd-5src/dist/ntp/ntpd/ntp_request.c 1.8.4.2 netbsd-5-2 src/dist/ntp/ntpd/ntp_request.c 1.8.4.1.6.1 netbsd-5-1 src/dist/ntp/ntpd/ntp_request.c 1.8.4.1.2.1 default configuration file update: HEADsrc/etc/ntp.conf 1.18 netbsd-6src/etc/ntp.conf 1.14.2.1 netbsd-6-1 src/etc/ntp.conf 1.14.16.1 netbsd-6-0 src/etc/ntp.conf 1.14.8.1 netbsd-5src/etc/ntp.conf 1.9.20.1 netbsd-5-2 src/etc/ntp.conf 1.9.36.1 netbsd-5-1 src/etc/ntp.conf 1.9.28.1 Thanks To = Thanks to Erik Fair for bringing the issue to our attention and suggesting a fix. Revision History 2014-01-07 Initial release More Information Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2014-002.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2014, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2014-002.txt,v 1.2 2014/01/07 21:04:33 tonnerre Exp $ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (NetBSD) iQIcBAEBAgAGBQJSzGwhAAoJEAZJc6xMSnBuQX4P/j3dERFgvL95fxrHQViQlv9k G9G+IRFnvFdR1NvEY2j+qsLPW2zLIzBWdAODsHekgcnkQd3NXuwjo2pojC99SEkX kuGGyxo0RxuH98iQAco6rAqLsePkHYXxWwYPkLhKflPi4XUyb2ApWwh+O83ac/dg ochBbSIkjmKOX7w2isFP0NDiTi9AsgSWjsKj/MhRMhHpMHKqV6AaOmgwyZavntL3 73dnrfFLTdY54ZkyVRdS/6rgqPDACA9V1nLeGvdRovBWyyIcB/J+9g1xzWapnydm SNHN6mW0I1uFPx5equERwRkI1Vz68tfQwvf3VWEFkx1vTHJ+cF94P4RVz1WFwxKu tEwxpTuZCdUXEKCPmjd74Eo3Wgy2JHGgmpNvmwiOEfLHtHvwtZn05GxtLeGlb77k BNX8/MWmMNYqOARr3EXIgIxCdZgozhzXBXqqiUhM9gSCJykS9RdSbQYudrtHkXYM e3HcKsSTBDVwwBkca7UAncFcqCBKosd2dIrR9NaCe8aY+ZXt4RR3y4ipi686cvnC 9PSbp2PAIcb83CNKprglxceIZD93KZj37H8tW2IPmCrrjGXDqB4s4vXpEAwcxlNf RlMATwqz7ZmCIybg1/MI1E4/j/1EWHES/w9OAUvhCPk6WPIRpT5Zxv6MKE7XNleB NdDEOoZ4KpVo4ereausV =8eAi -END PGP SIGNATURE-
NetBSD Security Advisory 2014-001: Stack buffer overflow in libXfont
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NetBSD Security Advisory 2014-001 = Topic: Stack buffer overflow in libXfont Version:NetBSD-current: source prior to Tue 7th, 2014 NetBSD 6.1: affected NetBSD 6.0 - 6.0.2: affected NetBSD 5.1 - 5.1.2: affected NetBSD 5.2: affected Severity: privilege escalation Fixed: NetBSD-current: Tue 7th, 2014 NetBSD-6-0 branch: Tue 7th, 2014 NetBSD-6-1 branch: Tue 7th, 2014 NetBSD-6 branch:Tue 7th, 2014 NetBSD-5-2 branch: Tue 7th, 2014 NetBSD-5-1 branch: Tue 7th, 2014 NetBSD-5 branch:Tue 7th, 2014 Teeny versions released later than the fix date will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract A stack buffer overflow in parsing of BDF font files in libXfont was found that can easily be used to crash X programs using libXfont, and likely could be exploited to run code with the privileges of the X program (most nostably, the X server, commonly running as root). This vulnerability has been assigned CVE-2013-6462 Technical Details = - From the X.org advisory: Scanning of the libXfont sources with the cppcheck static analyzer included a report of: [lib/libXfont/src/bitmap/bdfread.c:341]: (warning) scanf without field width limits can crash with huge input data. Evaluation of this report by X.Org developers concluded that a BDF font file containing a longer than expected string could overflow the buffer on the stack. Testing in X servers built with Stack Protector resulted in an immediate crash when reading a user-provided specially crafted font. As libXfont is used to read user-specified font files in all X servers distributed by X.Org, including the Xorg server which is often run with root privileges or as setuid-root in order to access hardware, this bug may lead to an unprivileged user acquiring root privileges in some systems. This bug appears to have been introduced in the initial RCS version 1.1 checked in on 1991/05/10, and is thus believed to be present in every X11 release starting with X11R5 up to the current libXfont 1.4.6. (Manual inspection shows it is present in the sources from the X11R5 tarballs, but not in those from the X11R4 tarballs.) Solutions and Workarounds = Workaround: restrict access to the X server. Solutions: a fix is included in the following versions: xorg: xsrc/external/mit/libXfont/dist/src/bitmap/bdfread.c HEAD1.3 netbsd-61.1.1.2.2.1 netbsd-6-1 1.1.1.2.6.1 netbsd-6-0 1.1.1.2.4.1 netbsd-51.1.1.1.2.2 netbsd-5-2 1.1.1.1.2.1.4.1 netbsd-5-1 1.1.1.1.2.1.2.1 xfree: xsrc/xfree/xc/lib/font/bitmap/bdfread.c HEAD1.4 netbsd-61.2.8.1 netbsd-6-1 1.2.14.1 netbsd-6-0 1.2.10.1 netbsd-51.2.2.1 netbsd-5-2 1.2.12.1 netbsd-5-1 1.2.6.1 To obtain fixed binaries, fetch the appropriate xbase.tgz from a daily build later than the fix dates, i.e. http://nyftp.netbsd.org/pub/NetBSD-dailybinary/sets/xbase.tgz with a date 20140108* or larger, and your release version and architecture, and then extract the libXfont shared library files: for X.org environments, netbsd-6* and HEAD: cd / && tar xzpf /path/to/xbase.tgz ./usr/X11R7/lib/libXfont.so \ ./usr/X11R7/lib/libXfont.so.3 \ ./usr/X11R7/lib/libXfont.so.3.0 for X.org environments and netbsd-5*: cd / && tar xzpf /path/to/xbase.tgz ./usr/X11R7/lib/libXfont.so \ ./usr/X11R7/lib/libXfont.so.2 \ ./usr/X11R7/lib/libXfont.so.2.0 and for xfree environments: cd / && tar xzpf /path/to/xbase.tgz ./usr/X11R6/lib/libXfont.so \ ./usr/X11R6/lib/libXfont.so.1 \ ./usr/X11R6/lib/libXfont.so.1.5 To build from source, update bdfread.c to the appropriate version and then "./build.sh -x" from the top of the src tree. Thanks To = X.Org thanks the authors of the cppcheck tool for making their static analyzer available as an open source project we can all benefit from. http://cppcheck.sourceforge.net/ NetBSD would like to thank X.org for looking for and fixing this vulnerability. Revision History 2014-01-07 Initial release More Information Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advi
Re: Network attack?
On Tue, 7 Jan 2014, Manuel Bouyer wrote: So where the heck are all these random connections coming from? And why would they ever have been ESTABLISHED in the first place? Do you have some p2p tool running ? I'm seeing similar connections here, and my best guess is that they're from rtorrent Hmmm. I _do_ have "transmission" running - it's a bit-torrent thing, and I am "serving" a few files - various NetBSD distributions! :) I looked a couple of times, and all the torrents were idle. But definitely thanks for the info - if (when) it happens again, I will try disabling the "transmission" stuff and see if the situation gets better. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Network attack?
On Tue, Jan 07, 2014 at 10:44:45AM -0800, Paul Goyette wrote: > Still looking for why my machine has been crashing lately, at random > intervals. Earlier investigation shows that I might be having some > issues with mbuf allocation. > > After another recent episode, I took a look at netstat, and there > are a lot of "sessions" to/from random ports that are sitting in > TIMED_WAIT state. > > tcp0 0 50.193.51.18.54799 203.117.37.103.16881 ESTABLISHED > tcp0 0 50.193.51.18.54824 210.195.54.16.10756ESTABLISHED > tcp0 0 50.193.51.18.54847 177.0.114.79.16882 TIME_WAIT > tcp0 0 50.193.51.18.54868 78.243.79.149.24781TIME_WAIT > tcp0 0 50.193.51.18.54902 83.47.147.216.11682TIME_WAIT > tcp0 0 50.193.51.18.54912 115.176.3.138.27756TIME_WAIT > tcp0 0 50.193.51.18.54915 61.70.209.236.24138TIME_WAIT > tcp0 0 50.193.51.18.54934 119.175.222.99.22961 TIME_WAIT > tcp0 0 50.193.51.18.54957 182.169.96.14.26732TIME_WAIT > tcp0 0 50.193.51.18.54964 125.89.74.137.51413TIME_WAIT > tcp0 0 50.193.51.18.54965 218.251.60.136.8589TIME_WAIT > tcp0 0 50.193.51.18.55083 121.94.20.162.7227 TIME_WAIT > tcp0 0 50.193.51.18.55251 203.117.37.106.16884 TIME_WAIT > tcp0 0 50.193.51.18.55291 218.229.255.118.14143 TIME_WAIT > tcp0 0 50.193.51.18.55302 94.45.177.196.11866TIME_WAIT > tcp0 0 50.193.51.18.55310 124.8.223.90.16884 TIME_WAIT > tcp0 0 50.193.51.18.55324 203.140.186.130.7830 TIME_WAIT > tcp0 0 50.193.51.18.55390 210.201.124.126.9311 TIME_WAIT > tcp0 0 50.193.51.18.55479 190.17.176.48.25613TIME_WAIT > tcp0 0 50.193.51.18.55488 213.7.152.236.19578TIME_WAIT > tcp0 0 50.193.51.18.55510 174.97.159.182.13422 TIME_WAIT > tcp0 0 50.193.51.18.7 58.137.4.25.20784 TIME_WAIT > tcp0 0 50.193.51.18.55612 124.8.223.143.16882TIME_WAIT > tcp0 0 50.193.51.18.55625 200.233.97.23.16882TIME_WAIT > tcp0 0 50.193.51.18.55710 113.252.209.81.25529 TIME_WAIT > > My understanding of TIME_WAIT state is that a connection has > recently disconnected. Which implies that the connection was > previously in the ESTABLISHED state. > > So where the heck are all these random connections coming from? And > why would they ever have been ESTABLISHED in the first place? Do you have some p2p tool running ? I'm seeing similar connections here, and my best guess is that they're from rtorrent -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Network attack?
Still looking for why my machine has been crashing lately, at random intervals. Earlier investigation shows that I might be having some issues with mbuf allocation. After another recent episode, I took a look at netstat, and there are a lot of "sessions" to/from random ports that are sitting in TIMED_WAIT state. tcp0 0 50.193.51.18.54799 203.117.37.103.16881 ESTABLISHED tcp0 0 50.193.51.18.54824 210.195.54.16.10756ESTABLISHED tcp0 0 50.193.51.18.54847 177.0.114.79.16882 TIME_WAIT tcp0 0 50.193.51.18.54868 78.243.79.149.24781TIME_WAIT tcp0 0 50.193.51.18.54902 83.47.147.216.11682TIME_WAIT tcp0 0 50.193.51.18.54912 115.176.3.138.27756TIME_WAIT tcp0 0 50.193.51.18.54915 61.70.209.236.24138TIME_WAIT tcp0 0 50.193.51.18.54934 119.175.222.99.22961 TIME_WAIT tcp0 0 50.193.51.18.54957 182.169.96.14.26732TIME_WAIT tcp0 0 50.193.51.18.54964 125.89.74.137.51413TIME_WAIT tcp0 0 50.193.51.18.54965 218.251.60.136.8589TIME_WAIT tcp0 0 50.193.51.18.55083 121.94.20.162.7227 TIME_WAIT tcp0 0 50.193.51.18.55251 203.117.37.106.16884 TIME_WAIT tcp0 0 50.193.51.18.55291 218.229.255.118.14143 TIME_WAIT tcp0 0 50.193.51.18.55302 94.45.177.196.11866TIME_WAIT tcp0 0 50.193.51.18.55310 124.8.223.90.16884 TIME_WAIT tcp0 0 50.193.51.18.55324 203.140.186.130.7830 TIME_WAIT tcp0 0 50.193.51.18.55390 210.201.124.126.9311 TIME_WAIT tcp0 0 50.193.51.18.55479 190.17.176.48.25613TIME_WAIT tcp0 0 50.193.51.18.55488 213.7.152.236.19578TIME_WAIT tcp0 0 50.193.51.18.55510 174.97.159.182.13422 TIME_WAIT tcp0 0 50.193.51.18.7 58.137.4.25.20784 TIME_WAIT tcp0 0 50.193.51.18.55612 124.8.223.143.16882TIME_WAIT tcp0 0 50.193.51.18.55625 200.233.97.23.16882TIME_WAIT tcp0 0 50.193.51.18.55710 113.252.209.81.25529 TIME_WAIT My understanding of TIME_WAIT state is that a connection has recently disconnected. Which implies that the connection was previously in the ESTABLISHED state. So where the heck are all these random connections coming from? And why would they ever have been ESTABLISHED in the first place? :) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: build installs file it then removes
On Sat, Jan 04, 2014 at 07:41:16PM +0100, Thomas Klausner wrote: > I just saw this (not an update build) while building current-amd64 > with clang: > > Removed obsolete file > /archive/build/amd64.clang.20140104//usr/include/g++/complex.h > > So it seems to me the build installs a file that's marked as obsolete. I traced this back to this commit by christos: 1.1853 (christos 02-Nov-13): ./usr/include/g++/complex.h comp-obsolete gcc=45,obsolete 1.1853 (christos 02-Nov-13): ./usr/include/g++/complex.h comp-obsolete gcc=48,obsolete revision 1.1853 date: 2013-11-02 02:37:33 +0100; author: christos; state: Exp; lines: +3 -4; commitid: GLHchWdlCEi5TDbx; more sets fixes @@ -1204,8 +1204,8 @@ ./usr/include/g++/cmathcomp-cxx-include gcc,cxx,libstdcxx ./usr/include/g++/compare.hcomp-obsolete obsolete ./usr/include/g++/complex comp-cxx-include gcc,cxx,libstdcxx -./usr/include/g++/complex.hcomp-obsolete gcc=45,cxx,libstdcxx -./usr/include/g++/complex.hcomp-obsolete gcc=48,cxx,libstdcxx +./usr/include/g++/complex.hcomp-obsolete gcc=45,obsolete +./usr/include/g++/complex.hcomp-obsolete gcc=48,obsolete ./usr/include/g++/condition_variable comp-cxx-include gcc=45,cxx,libstdcxx ./usr/include/g++/condition_variable comp-cxx-include gcc=48,cxx,libstdcxx ./usr/include/g++/csetjmp comp-cxx-include gcc,cxx,libstdcxx Before that it was only: 1.1819 (joerg28-Apr-13): ./usr/include/g++/complex.h comp-obsolete gcc=45,cxx,libstdcxx until mrg added: 1.1852 (mrg 01-Nov-13): ./usr/include/g++/complex.h comp-obsolete gcc=48,cxx,libstdcxx for revision 1.1852 date: 2013-11-01 08:48:31 +0100; author: mrg; state: Exp; lines: +622 -10; commitid: wvfrE2n2ze1fYxbx; add support for GCC 4.8 sets. I have build logs from Oct 31 where this didn't happen; my next build was only on Nov 26. I don't know what the idea here is, but something's wrong, please fix it. Thomas
