dyndnsupdate-0.6.15 has a remote vulnerability which appears to be exploitable. In src/dyndnsupdate.c, the ipcheck function fails to validate data read from a socket before copying it into 'ipaddress', a stack allocated buffer, using sprintf.
I guess that wont be the only problem... Most of this code is very naive.
1. I have been unable to contact upstream author; registrations of domains for contact email addresses have lapsed.
2. Googling suggests that no other distributions are including this package.
3. There is already a viable alternative to this package in portage; net-dns/ddclient
I suggest adding this package to package.mask, and removing it from portage.
Re-assigning to security.
Upstream is dead, package has no Gentoo maintainer...
Auditors, could you please confirm the package is a mess ?
I have nfc how this works... Does the attacker need to setup a malicious server ? Or is dyndnsupdate a listening daemon ? In the latter we'll have to issue a GLSA about this if we dump it.
It doesnt listen - exploiting this requires dns cache poisoning, tcp session hijacking, or control over an http proxy. There is no ssl here (unlike most other dyndns clients), so these attacks are not too demanding.
The ebuild doesnt run this program automatically, but I guess many users will be running this as root. *I* would want to receive a GLSA for this.
Access to the local filesystem looks safe; I dont see any local exploits.
Confirmed, it does look exploitable via multiple vectors. dns poisoning would be required though, so not a high priority.
I think it should be dropped in favour of the maintained package.
the problems start in the argument parsing and get worse from there. bin it.
nemo dyndnsupdate-0.6.15 # ./dyndnsupdate -a 127.0.0.1 \
-u $(perl -e 'print "x" x 1024') \
-h bleh -s $(perl -e 'print "x" x 1024')
OK. Upstream is dead, package is a mess, it has no maintainer and alternatives exist. Should be masked prior to removal, and a Masking GLSA should be issued to warn our users to switch to better alternatives.
Security please review the masking GLSa draft
Masking GLSA 200503-27
Keeping open as enhancement to remember to remove it sometime
Probably safe to remove this from the tree now.