Package: festival Version: 1.96~beta-6 Severity: grave Tags: security Most users of festival have no reason to use its server mode, so the server should not be started by default. Putting an annoying password prompt in place is not a good way to get secure systems for users who have festival installed so it can be used by something like kismet.
Problems with this approach as implemented include:
1. Festival's server doesn't take any countermeasures against dictionary
attacks, allowing 300 or more passwords to be tried per second on not very
fast hardware.
2. There's absolutely no incentive to provide a good password, since the
prompt for it doesn't scream in big letters that this password is all
that's standing between remote attackers and a shell on your system,
and since the typical user will never use the server and has no idea
why it needs a password, or that it runs, in the first place.
3. The password that I entered ("foo") was not actually written into
/etc/festival.scm at all (!) ; after upgrade to this version
I could still log in w/o password. I assume this is because you
set the password to "" in the config script; the config script can be
run twice during an upgrade so it prompts for a password the first
time, which is then thrown away, and it doesn't prompt a second time
since the question is still marked as seen. (Suggest remedial reading
of the debconf documentation...)
4. The postinst script puts the password into /etc/festival.scm before
the "extra safety check" that sets the permissions so that others
cannot read it, thus exposing the password to local users.
5. Of course, it's also exposed briefly by your use of sed to write it to
the file. (Never write shell script that exposes passwords in the arguments
of programs where they can be seen by ps(1).)
Since festival's server mode is inherently terribly insecure, there's
little reason to make it an option at all, not even a non-default
option. This was clear to me when I maintained the package, and I used
methods like the one implemented in the attached daemon when I needed
secure access to a festival daemon. (Of course, this was in the 90's,
when festival started up slowly, not on modern hardware.)
And as the original maintainer of this package, I have to say that I
found the recent security bug about this issue astounding. It's always
been clear to me that festival's server mode is an unsecure
research-project level proof-of-concept that was never intended to be
used in production.
IMHO it should not even have an init script in the package; the init
script should certianly not default to starting it by default, nor should
installing festival as a depdendency of something like kismet cause
a gratuitous prompt for a password that noone except for an attacker will
ever want to use.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages festival depends on:
ii adduser 3.105 add and remove users and groups
ii libaudiofile0 0.2.6-7 Open-source version of SGI's audio
ii libc6 2.7-8 GNU C Library: Shared libraries
ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared
ii libestools1.2 1:1.2.96~beta-2 Edinburgh Speech Tools Library
ii libgcc1 1:4.3-20080202-1 GCC support library
ii libncurses5 5.6+20080203-1 Shared libraries for terminal hand
ii libstdc++6 4.3-20080202-1 The GNU Standard C++ Library v3
ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip
ii sgml-base 1.26 SGML infrastructure and SGML catal
ii sysv-rc 2.86.ds1-53 System-V-like runlevel change mech
Versions of packages festival recommends:
ii festvox-kallpc16k [festival-v 1.4.0-5 American English male speaker for
-- no debconf information
--
see shy jo
signature.asc
Description: Digital signature
