Henrique de Moraes Holschuh wrote:
> On Wed, 24 Nov 2004, Martin Schulze wrote:
> > CAN-2004-1015 missing. Not sure if the version in ubuntu or unstable is
> > vulnerable, though.
>
> I didn't know about that one. Any references? Google is useless for things
> like this, and the CVE database is totally useless for CAN references (which
> is quite aggravating).
Both Google and CVE are usually quite helpful with this, except for the
cases where the CAN is not yet published.
The text for it is:
"Proxyd.c contains a IMAPMAGICPLUS overflow in its proxyd_canon_user function fixed in 2.2.10."
> he noticed that the patch to 2.2.9 is incomplete. Proxyd.c contains
> the same IMAPMAGICPLUS overflow in its proxyd_canon_user function.
This is fixed in 2.2.10 now.
> On a related note, I will not pretend I even remotely understood how the
> flag[nflags++] code could be a security hole *on 2.1.16*, unless something
> is buggy enough to think nflags++ is the same as ++nflags... On 2.1.x,
> xstrdup doesn't appear to touch flag or nflags at all, and its args don't
> reference either. I'd appreciate if someone explained where the hole is to
> me.
The problem is in connection to xfzmalloc() and xstrfcpy() which can fail
and try to clean up the variable where the new memory was supposed to end
up.
> 2.1.17-1 fixes all problems reported by e-matters GmbH on 2004-11-22. As
> far as I understood things, so does 2.1.16-11. I have no idea about this
> CAN-2004-1015, though. And apparently, nor does Cyrus upstream, so please
> send us the references...
It came from Cyrus upstream and went into 2.2.10.
> Note that there was a SASL buffer overflow fix on upstream CVS, for which I
> had no CVE references. I have no idea if it was just a bad behaviour fix, or
> a security hole fix. Maybe this is CAN-2004-1015?
Henrique de Moraes Holschuh wrote:
> On Wed, 24 Nov 2004, Martin Schulze wrote:
> > CAN-2004-1015 missing. Not sure if the version in ubuntu or unstable is
> > vulnerable, though.
>
> I didn't know about that one. Any references? Google is useless for things
> like this, and the CVE database is totally useless for CAN references (which
> is quite aggravating).
Both Google and CVE are usually quite helpful with this, except for the
cases where the CAN is not yet published.
The text for it is:
"Proxyd.c contains a IMAPMAGICPLUS overflow in its
proxyd_ canon_user function fixed in 2.2.10."
> he noticed that the patch to 2.2.9 is incomplete. Proxyd.c contains
> the same IMAPMAGICPLUS overflow in its proxyd_canon_user function.
This is fixed in 2.2.10 now.
> On a related note, I will not pretend I even remotely understood how the
> flag[nflags++] code could be a security hole *on 2.1.16*, unless something
> is buggy enough to think nflags++ is the same as ++nflags... On 2.1.x,
> xstrdup doesn't appear to touch flag or nflags at all, and its args don't
> reference either. I'd appreciate if someone explained where the hole is to
> me.
The problem is in connection to xfzmalloc() and xstrfcpy() which can fail
and try to clean up the variable where the new memory was supposed to end
up.
> 2.1.17-1 fixes all problems reported by e-matters GmbH on 2004-11-22. As
> far as I understood things, so does 2.1.16-11. I have no idea about this
> CAN-2004-1015, though. And apparently, nor does Cyrus upstream, so please
> send us the references...
It came from Cyrus upstream and went into 2.2.10.
> Note that there was a SASL buffer overflow fix on upstream CVS, for which I
> had no CVE references. I have no idea if it was just a bad behaviour fix, or
> a security hole fix. Maybe this is CAN-2004-1015?
Could that be DSA 563 alias CAN-2004-0884?
Regards,
Joey
-- www.elug. de/projekte/ patent- party/patente/ DE10108564
WARNING: Do not execute! This call violates patent DE10108564.
http://
wget -O patinfo-`date +"%Y%m%d"`.html http:// patinfo. ffii.org/