First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 84659
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Security <security@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Toby Dickenson <toby@tarind.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:
Flags: Requestee:
 
 
  ()

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 84659 depends on: Show dependency tree
Bug 84659 blocks:

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2005-03-09 13:00 0000
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.

------- Comment #1 From Toby Dickenson 2005-03-13 05:02:09 0000 -------
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.

------- Comment #2 From Luke Macken (RETIRED) 2005-03-16 10:44:01 0000 -------
Re-assigning to security.

------- Comment #3 From Thierry Carrez (RETIRED) 2005-03-16 11:35:22 0000 -------
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.

------- Comment #4 From Toby Dickenson 2005-03-16 12:26:34 0000 -------
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.

------- Comment #5 From Tavis Ormandy (RETIRED) 2005-03-17 02:36:24 0000 -------
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.

------- Comment #6 From rob holland (RETIRED) 2005-03-17 02:41:55 0000 -------
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')
Segmentation fault

------- Comment #7 From Thierry Carrez (RETIRED) 2005-03-17 03:15:14 0000 -------
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.

------- Comment #8 From Thierry Carrez (RETIRED) 2005-03-21 06:31:29 0000 -------
Security please review the masking GLSa draft

------- Comment #9 From Thierry Carrez (RETIRED) 2005-03-21 07:58:08 0000 -------
Masking GLSA 200503-27
Keeping open as enhancement to remember to remove it sometime

------- Comment #10 From Robert Paskowitz (RETIRED) 2005-05-17 15:54:05 0000 -------
Probably safe to remove this from the tree now.

------- Comment #11 From Thierry Carrez (RETIRED) 2005-06-15 05:31:30 0000 -------
Removed

First Last Prev Next    No search results available      Search page      Enter new bug