Dear Joey,
On Wed, Feb 20, 2008 at 08:03:41PM -0500, Joey Hess wrote:
> 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...)I missed this out! Thanks for the pointer. > 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. Again, I missed this. > 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).) Thanks for pointing this out. > 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. I accept this. Therefore, would you advocate: 1. Disabling server mode by default (which users wanted enabled by default, but I see what you mean). 2. Removing the init script: Maybe leaving it with adequate warning of consequences of what are the side effects might help, or remove it altogether and allow users to start it on their own, knowing fully well the risks involved? Thanks, and apologies for the mistakes. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036
signature.asc
Description: Digital signature
