Hi,
As already Jan pointed out, the code in oval_plugins.c is more or less a
proof of concept and it does require at least some effort to set up your
installation and your system in a way that makes you vulnerable to this
issue.
It should also be noted that OpenVAS Scanner will make a considerable
effort to drop its privileges before calling ovaldi. So in reality the
attacker would only gain the privileges of "nobody" (if OpenVAS Scanner
was executed as root) or the privileges of the user which started
OpenVAS Scanner (if it was not executed as root). Neither of those users
should have enough privileges to damage the system itself.
The privilege dropping has been in place since before the release of
OpenVAS 2.0. In the most likely case (OpenVAS Scanner running as root),
this means you have to go to considerable lengths to set up your
installation for OVAL definitions, install ovaldi, configure OpenVAS
Scanner to execute untrusted plugins and so on (or hope somebody else
already has done this). Then you use a non-privileged user to create a
symlink to gain the privileges of ... "nobody".
This seems pretty pointless to me unless I am missing something major.
IMHO this only shows that the folks reporting this issue were good at
finding a few lines matching their pattern, but did not actually try to
read or understand the whole function or try to exploit the issue.
There may be rare situations in which oval_plugins.c is unable to drop
privileges. I think oval_plugins.c should use the drop_privileges
function which is now provided by openvas-libraries to better handle
situations like this, but we should take care to take a consistent
approach here.
Nevertheless, I agree that the code in question is ugly and inefficient
at best and could use an improvement.
If I understand the attack vector correctly, the main problem is the
predefined name of the temporary file. Would it be enough to generate a
random unique filename and use this as results_filename?
Is there an established best practice for situations like this? Note
that we only need a filename and do not need the file to be created,
so mkstemp() and tmpfile() do not seem helpful and would still carry a
(reduced) risk if I understand things correctly.
Any suggestions? Or am I missing something important?
Regards,
Michael
* Tim Brown [ 6. Sep 2011]:
> This was publicly reported yesterday.
>
> Tim
>
> ---------- Forwarded Message ----------
>
> Subject: openvas 2.x race condition
> Date: Sunday 04 Sep 2011, 23:56:48
> From: Bugs NotHugs <bugsnoth...@gmail.com>
> To: fd <full-disclos...@lists.grok.org.uk>, bugtraq
> <bugt...@securityfocus.com>, vu...@securityfocus.com, v...@secunia.com,
> submissi...@packetstormsecurity.org, xfo...@iss.net, v...@frsirt.com,
> t...@openvas.org
>
> > openvas-server/openvas/oval_plugins.c
> > [...]
> > results_filename = "/tmp/results.xml";
> > if (g_file_test (results_filename, G_FILE_TEST_EXISTS))
> > {
> > log_write ("Found existing results file in %s, deleting it to
> > avoid conflicts.", results_filename);
>
> it unlink /tmp/results.xml avoid symlink attack then spawn process
> that write stuff to /tmp/results.xml
>
> chinese apt can make symlink point to any system file during race and win
> race!
>
> --
>
> BugsNotHugs
> Shared Vulnerability Disclosure Account
>
> -----------------------------------------
> --
> Tim Brown
> <mailto:t...@openvas.org>
> <http://www.openvas.org/>
> _______________________________________________
> Openvas-devel mailing list
> Openvas-devel@wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
--
Michael Wiegand | Greenbone Networks GmbH | http://www.greenbone.net/
Neuer Graben 17, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
Executive Directors: Lukas Grunwald, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
