As a caching DNS server, posadis might be affected by the issue too. Does it use port randomization? Using this bug to collect information, so we won't forget about it.
net-dialup/pdnsd is very well designed. It uses a random port - more exactly the port is picked up randomly from a configurable port range - and the transaction ID is also selected randomly. This is based on my personal analysis of the source code. If it were my bug I would have close it as INVALID, but since it isn't, I let security team deal with it. ;)
my understanding is, that only dns caches/resolvers are affected by this vulnerability. AFAIK net-dns/pdnsd is a authoritative nameserver only and thus not affected. net-dns/pdns-recursor (the resolver from the people behind pdns) might be affected, however.
Nope, net-dialup/pdnsd is not an authoritative nameserver. This quote is taken from the home page: pdnsd is a proxy DNS server with permanent caching (the cache contents are written to hard disk on exit) that is designed to cope with unreachable or down DNS servers (for example in dial-in networking). But since it uses random port numbers as well as random transaction IDs, this piece of software is not affected by the VU#800113 issue.
quoting homepage: "Version 1.2.7-par has been released: Foremost, this release fixes some security problems. It contains a fix for a "dangling pointer" bug that could cause pdnsd to crash when it received a long reply. It also addresses some of the issues raised in the CERT vulnerability note VU#800113 by making the default of query_port_start equal to 1024, thereby ensuring that source ports are randomly selected by the pdnsd resolver in the range 1024-65535 [...]" net-dialup, please bump as necessary.
Fixed in cvs. Arch teams, please stabilize net-dns/pdnsd-1.2.7.
amd64/x86 stable
On sparc: I have 1.2.6-r1 running and it's working fine. After upgrading to 1.2.7(same use-flags, same config) I get "Could not bind to socket: Permission denied" but /var/cache/pdnsd/pdnsd.status is read- and writeable by pdnsd. If I run it as root I get "Out of ports in the range 1024-65535, dropping query!" and it's unable to resolve any domains at all. # emerge --info Portage 2.1.4.4 (default-linux/sparc/sparc64/2008.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r7 sparc64) ================================================================= System uname: 2.6.25-gentoo-r7 sparc64 sun4u Timestamp of tree: Sun, 07 Sep 2008 11:36:01 +0000 app-shells/bash: 3.2_p33 dev-lang/python: 2.5.2-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="sparc" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-mcpu=ultrasparc -O2 -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-mcpu=ultrasparc -O2 -pipe" DISTDIR="/tmp/distfiles" FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox strict test unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE.UTF-8" LINGUAS="en de" MAKEOPTS="-j17" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="apache2 caps cli cracklib cups dri extensions fortran gdbm gpm hpn iconv ipv6 isdnlog logrotate mailwrapper midi mudflap ncurses nls nptl nptlonly openmp pcre ppds pppd qos reflection server session snmp sparc spl ssl symlink tftp threads truetype unicode userlocales vim xml xorg" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias proxy proxy_balancer proxy_connect proxy_ftp proxy_http" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LINGUAS="en de" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
alpha stable
(In reply to comment #7) > On sparc: I have 1.2.6-r1 running and it's working fine. After upgrading to > 1.2.7(same use-flags, same config) I get "Could not bind to socket: Permission > denied" but /var/cache/pdnsd/pdnsd.status is read- and writeable by pdnsd. If I > run it as root I get "Out of ports in the range 1024-65535, dropping query!" > and it's unable to resolve any domains at all. Which query port range do you use? Attach here a basic config file that doesn't work for you.
Created attachment 165323 [details] pdnsd.conf It's almost the pdnsd.conf.sample file, all I change is the myisp ip. if run_as is set to pdnsd: pdnsd[8053]: Could not bind to socket: Permission denied if run_as is set to root: Out of ports in the range 1024-65535, dropping query! However, if I start "pdnsd --debug" without a config file it works but since it's almost the default config...
The problem lies in -a command line option. When IPv6 support is enabled in your kernel, it will set run_ipv4 to 0, which disables IPv4 support. It is not a bug, only a default network protocol in case both of them are enabled. Just replace -a option with -4 or switch off ipv6 USE flag for this package.
Ah, so it's just me beeing stupid, well, sparc stable then :)
There's also a DoS issue fixed in 1.2.7 2) An error exists within the "p_exec_query()" function in src/dns_query.c when processing long replies with many answer sections. This can be exploited to e.g. crash the service by sending a specially crafted reply. The vulnerabilities are reported in versions prior to version 1.2.7-par.
ppc stable
Ready for vote, I vote YES.
CVE-2008-4194 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4194): The p_exec_query function in src/dns_query.c in pdnsd before 1.2.7-par allows remote attackers to cause a denial of service (daemon crash) via a long DNS reply with many entries in the answer section, related to a "dangling pointer bug."
YES, filed
arm/s390 stable
GLSA 200901-03