Package: monopd
Version: 0.9.7-2
Severity: normal
Tags: upstream patch security
Control: clone -1 -2
Control: reassign -2 libcapsinetwork0c2a 0.3.0-7
Control: found -2 0.3.0-8
There's an off-by-one error in libcapsinetwork network handling code,
which was merged into monopd in version 0.9.4.
>From src/listener.cpp, Listener::checkActivity():
#define MAXLINE 1024
[...]
char *readBuf = new char[MAXLINE];
int n = read((*it)->fd(), readBuf, MAXLINE);
if (n <= 0) // socket was closed
{
(*it)->setStatus(Socket::Closed);
delete[] readBuf;
return; // notification is (still) in earlier iteration
}
readBuf[n] = 0;
With an input line longer than 1023, this will write zero at readBuf[1024]
which is out of bounds.
Florian Weimer from the security team says this isn't exploitable with
the glibc malloc (dlmalloc), but might theoretically be with other malloc
implementations like jemalloc. CVE-2015-0841 has been assigned to track
this potential vulnerability, but I'm leaving the severity at 'normal'
as this doesn't seem to be an issue for Debian.
I have informed the monopd upstream maintainer, Sylvain Rochet, about this.
His suggested patch was
- char *readBuf = new char[MAXLINE];
+ char *readBuf = new char[MAXLINE+1]; // MAXLINE + '\0'
The issue is present in at least
monopd_0.9.7-2 (jessie/sid, embeds the code)
libcapsinetwork_0.3.0-7 (wheezy, used by the wheezy monopd)
libcapsinetwork_0.3.0-8 (jessie/sid, no reverse dependencies)
The wheezy monopd doesn't contain the bug itself, only through
libcapsinetwork linkage.
I'm cloning a separate bug for libcapsinetwork. Please note that it's dead
upstream (according to debian/copyright), and monopd upstream says it
could be safely removed as no one should really want to use it anymore.
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
