[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Sep 2011 13:57:05 +0100
From: Tim Brown <timb@...nvas.org>
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
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/>
Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)
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.
