oss-security - Re: CVE Request -- openvas-scanner -- Insecure temporary file use by generation of an OVAL system characteristics document, when ovaldi support enabled

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 9 Sep 2011 13:45:03 -0400 (EDT)
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Jan Lieskovsky <jlieskov@...hat.com>,
        "Steven M. Christey" <coley@...us.mitre.org>,
        Bugs NotHugs <bugsnothugs@...il.com>,
        Stjepan Gros <stjepan.gros@...il.com>,
        openvas-devel@...d.intevation.org
Subject: Re: CVE Request -- openvas-scanner -- Insecure
 temporary file use by generation of an OVAL system characteristics
 document, when ovaldi support enabled

Let's go with one ID. I don't see a reason to split these.

Use CVE-2011-3351

Thanks.

-- 
    JB


----- Original Message -----
> On Wednesday 07 Sep 2011 13:13:45 Jan Lieskovsky wrote:
> > Hello Josh, Steve, vendors,
> >
> >    it was reported that the scanner module for the Open
> >    Vulnerability
> > Assessment System (OpenVAS) used insecure way for creation of a
> > temporary file, when generating OVAL system characteristics document
> > from the knowledge base data available, with the ovaldi integrated
> > tool
> > enabled. A local attacker could use this flaw to conduct symlink
> > attacks to overwrite arbitrary files on the system, accessible with
> > the
> > privileges of the user running the SLAD daemon and / or the ovaldi
> > OVAL
> > interpreter.
> >
> 
> Whilst having a look at the code with regard to the recently reported
> f-d
> issue with OpenVAS, the handling of sc-out.xml in the very same
> function also
> looks insecure. It also doesn't appear to care about races either and
> I'm
> also curious as to whether you can control the contents at all (think
> attacks
> against the ovaldi XML parser). I would suggest that this code needs
> properly
> auditing or removing.
> 
> Unfortunately the interaction with sc-out.xml happens before
> privileges are
> dropped so the malicious activitity occurs as the openvas-scanner user
> (normally root) rather than nobody as in the case of results.xml - The
> call to
> unlink referenced in the f-d email is actually a misnomer as it will
> actually
> only delete the file from /tmp and not whatever it may or may not have
> pointed
> to and the actual writing to the newly race created symlink actually
> happens
> within the ovaldi binary which is spawned as nobody AFAIK.
> 
> Josh/oss-security folk, can I get a CVE for both bugs please. Will we
> need to
> split out the two race conditions as separate CVE? The OpenVAS
> advisory will
> cover both the originally reported nobody case as well as the root
> case
> referenced above.
> 
> Tim
> --
> Tim Brown
> <mailto:timb@...nvas.org>
> <http://www.openvas.org/>

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.