[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F8C70C4.9010301@redhat.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
