According to the debian bug at $URL and the atop man page, atop creates temporary files insecurely. From $URL there is partial information:
"I've just noticed that atop keeps the runtime data in /tmp/atop* directories
or files (mentioned on man page too). I think it was established from a
discussion on email@example.com that this is potentially a security
vulnerability. Probably it should keep its temporary runtime data in its own
directory under /var/run (or /run for next release)."
Adding CVE found at https://bugzilla.redhat.com/show_bug.cgi?id=745479
+*atop-1.26-r1 (09 Jan 2012)
+ 09 Jan 2012; Sebastian Pipping <firstname.lastname@example.org> +atop-1.26-r1.ebuild,
+ Integrate custom patch for CVE-2011-3618 (bug #363887)
1) Stabilize 1.26-r1 ?
2) Review wanted: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-process/atop/files/atop-1.26-cve-2011-3618.patch?view=markup
FYI I have notified upstream (Gerlof Langeveld) of the patch and issue.
this should be respecting $TMPDIR instead of hardcoding /tmp
alternatively, you could create a pipe, fork and exec gzip, and then return the read pipe side. then you avoid the tempfile issue altogether.
FIY Upstream has released 1.27-3 yesterday which includes the patch from comment #2.
+*atop-1.27_p3 (23 Jul 2012)
+ 23 Jul 2012; Sebastian Pipping <email@example.com> +atop-1.27_p3.ebuild:
+ Bump to 1.27-3
Arches, please test and mark stable:
Target KEYWORDS="~alpha amd64 hppa ppc x86"
Archtested on x86: Everything fine
amd64: ok (builds, runs)
repoman complains about "RDEPEND is not explicitly assigned"
atop seems to require zlib and ncurses to run
Stable for HPPA.
x86 stable, thanks dlan.
Probably best to address any QA issues after-the-fact since this is a security bug.
I also keyworded ~arm. I will probably also keyword ~ppc64 and ~mips. This package is useful on all arches.
(In reply to comment #12)
> Stable ppc64
Bah! I mean stable ppc.
GLSA vote: no.
Thanks, folks. GLSA Vote: no too. Closing noglsa.