Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Apr 2012 13:19:32 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Jan Lieskovsky <jlieskov@...hat.com>,
        "Steven M. Christey" <coley@...us.mitre.org>, helmut@...divi.de
Subject: Re: CVE Request (minor) -- Two Munin graphing framework
 flaws

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/16/2012 07:54 AM, Jan Lieskovsky wrote:
> Hello Kurt, Steve, vendors,
> 
> the following three problems has been recently reported against
> Munin: [1] Insecure temp file use in the qmailscan plug-in:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=812889 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668778

Please use CVE-2012-2103 for this issue.

> [2] Possibility to inject escape sequences into Munin's log file:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=812885 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668666

Please use CVE-2012-2104 for this issue.

> [3] Remote users can fill /tmp filesystem: Red Hat would not
> consider this to be a security flaw => no RH BTS entry.
> 
> Original report: 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668667

I reread this one a few times, I'm not clear on what:

==========
printf 'GET
/cgi-bin/munin-cgi-graph/localdomain/localhost.localdomain/vmstat-day.png?foo
HTTP/1.0\r\nHost: localhost\r\nConnection: close\r\n\r\n' | nc
localhost 80

Provided that the filename actually exists, munin will render the image
==========

means exactly, does the file vmstat-day.png need to exist where? It
seems like if the image is of any size (say 20k or more) the
amplification (each get request = 20k of tmp space usage) and the
files have to be deleted manually it might qualify as a DoS.

helmut@...divi.de can you shed more light on this?

> For the first two -- though both of them having minor security
> impact, under suitable circumstances they could lead to trust
> boundary crossing => under our opinion they should get a
> (CVE-2012-*) identifiers.
> 
> For the third issue -- we wouldn't consider it to be a security 
> flaw. Just as something, which on improperly configured machine 
> could allow to fill in /tmp filesystem (just another way how to do
> it, when the particular service isn't properly configured).
> 
> Could you allocate CVE ids for the first two issues?
> 
> Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat
> Security Response Team


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPjHDEAAoJEBYNRVNeJnmTJUoP/RqxHJ4MeQcTA+iBu39MeD2y
1luFwUixuopRuF/QmY2x6CJSK6rqBtqD/PiPPGcP6Gy1JL/Ij3aFgWAvqwYQdD3o
ElHlvktZnqzMneRgdcaEi5TPMOBqlNJpyIB3AXHm+nlgmIX/wBl8tO1a8fbC3H3l
2dzGJwfj1tJeURl3szzRu242i+Agy2/nxCwNZpkXS7Bnp9j/a2Gk/ZtqN40lkPaL
e9eYPvw2Q19VznN6ZfzcxLbsFf3WYPjbYBKMYsP/84B56MzDYo6mf6+NslGos6zB
l+sN8MXoch2WRKkXduDYcVSxt1Kkdr5rn3IzqJOvVn8bY5aFTgOMSOHLJ7bymwps
TdIh6a2dDs1RoITOfvCOkyC0RTjWARQHhDahQNv+BGsFuUT6515ai6QdlzFnEkZO
QjQj7wy6QJLbWBwIN1OOruFkw1Sni7U18t130HwnnGjm1Jsimxgqf8UnAjru/rMf
gRYTr8FRBkdiePPEMhlo57dWL5MjrOHMyXN6yVfrEpFcMGI2Nk2CELsJDwDH/rzn
z8kPRJxYijcnl+dT50OpLZambqVrFEs4jYGGyijEkX1jgz9Xry1Oylnc5treED5x
VX8rNN0BaMXNYQrcdAuOAUgU2scGpt3qqVg1KXs3CfYEnNey2PToOXX9tAAQ6hif
JAg9ojcjKAdFUj4uRbS3
=OZ1d
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ