Bug#287601: vdradmin: Vdradmin.pl script vulnerable to symlink attacks

[Javier Fernández-Sanguino Peña]

--CUfgB8w4ZwR/yMy5
Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline


--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> I am aware of this issue, and i allready prepared a version of
> vdradmin with a small workaround - i moved the directory where the
> tmp-files are stored to /var/cache/vdradmin/. I will ask my sponsor to
> upload it soon.=20

What mode is /var/cache/vdradmin/? Is it 0777?

> Btw: I can not find your patch! ;-)

Sorry, attached.

> > I believe that the vdr sources should be reviewed to make sure that an =
vdr
> > daemon running as root cannot compromise the whole system (there are no
> > checks for symlink attacks in the fopen calls). It should be worthwhile
> > trying to make the daemon work as a non-root user. I will file this as =
a=20
> > separate bug referencing this one, however.
>=20
> Well, i was not aware of this issue (at least that vdr itself is
> affected), but in theory it is possible to run vdr as normal user, it
> only needs a small patch to make it possible that vdr can set the
> system-time. The only problem is that changing this would require a
> lot of code in the maintainer scripts - patches for this would be very
> wellcome.

It looks to me like the vdr program will take any files given as argument
to the command and overwrite them blissfully since no checks seem to be
done before they are fopened() at least in dvbdevice.c
(cDvbDevice::GrabImage), in recording.c (cRecording::WriteSummary) and in
some other functions, there also seem to be available commands to delete
files that make no checks whatsoever. From a cursory look it SVDRP=20
(implemented in svdrp.c) seems to have no authentication at all, which=20
means that a remote rogue user could issue commands to overwrite/delete=20
files using the dvr daemon.

I still need to check it further and do some tests before I open up the
bug...


Regards

Javier

--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="vdradmind.pl.diff"
Content-Transfer-Encoding: quoted-printable

--- vdradmind.pl.orig	2004-12-29 00:18:33.000000000 +0100
+++ vdradmind.pl	2004-12-29 00:22:30.000000000 +0100
@@ -38,6 +38,7 @@
 use Time::Local qw(timelocal);
 use POSIX ":sys_wait_h", qw(strftime mktime);
 use MIME::Base64();
+use File::Temp qw/tempdir/;
=20
 use strict;
 #use warnings;
@@ -659,7 +660,7 @@
=20
 sub GZip {
 	my $content =3D shift;
-  my $filename =3D "/tmp/vdradmin." . time();
+  my $filename =3D tempfile("vdradmin-XXXXX", UNLINK =3D> 1);
   open(PIPE, "| gzip -9 - > $filename") || die "cant open pipe to gzip ($!=
)";
   print PIPE $$content;
   close(PIPE);
@@ -3038,7 +3039,7 @@
 ##########################################################################=
###
 sub grab_picture {
 	my $size =3D $q->param("size");
-	my $file =3D "/tmp/vdr.jpg";
+	my $file =3D tempfile("vdr-XXXXX", UNLINK =3D> 1, SUFFIX =3D> ".jpg");
 	my $maxwidth =3D 768;
 	my $maxheight =3D 576;
 	my($width, $height);

--tThc/1wpZn/ma/RB--

--CUfgB8w4ZwR/yMy5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB0l7ui4sehJTrj0oRAhQFAJsE98Q599j/fd4Q4GDWju7tzQsmzACfZDCg
+USGsAC1PiJ2LheQ1+Zo79Y=
=CiJS
-----END PGP SIGNATURE-----

--CUfgB8w4ZwR/yMy5--