From $URL: The GTK version of ettercap uses a global settings file at /tmp/.ettercap_gtk and does not verify ownership of this file. When parsing this file for settings in gtkui_conf_read() (src/interfaces/gtk/ec_gtk_conf.c), an unchecked sscanf() call allows a maliciously placed settings file to overflow a statically-sized buffer on the stack. Stack-smashing protection catches it, but it still should be fixed. Verify with: $ perl -e 'print "A"x500' > /tmp/.ettercap_gtk && ettercap -G Firstly, the settings file should not be globally accessible without checking ownership, which still gets hairy because an attacker could create a symlink or hard link to a victim-controlled file (unless you're using YAMA :p). The best thing would probably be to keep this file in the user's home directory instead. Secondly, parsing configuration files should be robust against malformed input and not susceptible to trivial buffer overflows. And CVE assignment from oss-security: CVE-2010-3843 ettercap GTK insecure temporary file use CVE-2010-3844 ettercap GTK format string flaw (note:Not sure why the CVE-2010-3844 is described as a format string vuln, when it's a stack overflow.)
ettercap 0.7.4.1 is in the tree and functional, want to stabilize it as part of this security issue or should we close this as ancient and do a normal stabilization?
Thanks for the notification. However, I don't see any indication of these issues being fixed in 0.7.4.1. $URL has a patch which apparently didn't get applied upstream. I can't seem to find a changelog for 0.7.4.1 either. Do you have more information on this? In contrast though, the changelog for 0.7.4 claims to have fixed "buffer access out-of-bounds issues", "multiple buffer overflows" and "multiple memory leaks". Could you find out if this are the same issues?
(In reply to comment #2) > Thanks for the notification. > > However, I don't see any indication of these issues being fixed in 0.7.4.1. > $URL has a patch which apparently didn't get applied upstream. I can't seem > to find a changelog for 0.7.4.1 either. Do you have more information on this? > > In contrast though, the changelog for 0.7.4 claims to have fixed "buffer > access out-of-bounds issues", "multiple buffer overflows" and "multiple > memory leaks". Could you find out if this are the same issues? Upstream claims these were fixed in 0.7.4 (although please don't stabilize that version as it has other issues). If upstream's say-so isn't good enough I'm happy to take anything you have and beat them over the head with it. Thanks!
This is now really fixed in 0.7.5. Arches, please test and mark stable: =net-analyzer/ettercap-0.7.5 Target keywords : "alpha amd64 arm hppa ppc ppc64 sparc x86"
x86 done
amd64 stable
stable ppc ppc64
>11 Oct 2012; Agostino Sarubbo (ago) ettercap-0.7.5.ebuild: >Stable for AMD64, wrt bug #430897 Please fix the typo in the bug number
Stable for HPPA.
(In reply to comment #8) > >11 Oct 2012; Agostino Sarubbo (ago) ettercap-0.7.5.ebuild: > >Stable for AMD64, wrt bug #430897 > > Please fix the typo in the bug number fixed
alpha/arm/sparc stable
(In reply to comment #11) > alpha/arm/sparc stable Forgot to un-cc those arches :)
Thanks, everyone. New GLSA request filed.
This issue was resolved and addressed in GLSA 201405-12 at http://security.gentoo.org/glsa/glsa-201405-12.xml by GLSA coordinator Sean Amoss (ackle).