Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK+yWWKRxYh-EAQj9QTe8RbbsJTm_W4JCeizkXOgDgraZG15VA@mail.gmail.com>
Date: Fri, 27 Apr 2012 17:41:48 +0200
From: Steve Schnepp <steve.schnepp@...il.com>
To: Kurt Seifried <kseifried@...hat.com>, 668667@...s.debian.org
Cc: oss-security@...ts.openwall.com, Helmut Grohne <helmut@...divi.de>, 
	Jan Lieskovsky <jlieskov@...hat.com>, "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: Bug#668667: CVE Request (minor) -- Two Munin
 graphing framework flaws

On Wed, Apr 18, 2012 at 07:04, Kurt Seifried <kseifried@...hat.com> wrote:
>> In addition munin parses parts of the query string. You are allowed
>> to modify the size of the image. By choosing a path
>> "....png?size_x=20000&size_y=20000&uniquestuff" you can do the
>> same attack while simultaneously using a large image size. The raw
>> image would be 381M (assuming 8bits/pixel) in this case. A png
>> version will likely be smaller, say 4M? So now you have an
>> amplification of 4M/request. Note that this query can get a node
>> into swapping, because rrdtool needs to create the whole image in
>> main memory.

> Ouch.

I believe I fixed the bug in r4825, since :
- url with query string aren't stored permanently anymore.
- /tmp isn't used anymore per default (to fix #668536)

Could you confirm that ?

OTOH, the issue about very big imgs that gets the cgi into swapping
isn't the same bug to be.

As Helmut noticed, there is already a size cap in rrd, so do I still
need implement one in munin ? If yes, would you mind to file another
bugreport (for RAM exhaustion) ?

Thx !

r4825: http://munin-monitoring.org/changeset/4825

--
Steve Schnepp
http://blog.pwkf.org/

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.