Speech Dispatcher 0.7 Beta -- Please help with testing

[Bill Cox]

I admit to being an idiot, at least about speech-dispatcher.  For one
thing, I find I'm unable to telnet from a remote machine to port 6560.
 It looks like it's restricted to the loopback interface by default.
I have to be logged into your machine to start talking to you through
speech-dispatcher.  Honestly, I feel a lot better knowing that.  I
find that protections from other users who are already logged into
your machine are a bit like locks on doors.  They help honest people
stay honest, but wont keep out serious bad guys.  So, I also consider
it a bug to have a local TCP port that all users can manipulate with
no permission checking, and I agree it's not critical.

Bil

On Tue, Apr 27, 2010 at 9:12 PM,  <trev.saunders at gmail.com> wrote:
>> I like the socket approach,
>
> I don't have a problem with using sockets, the problem is the location of the 
> socket.
>
>> ?but I guess your concern may be why Luke
>> was thinking of using dbus. ?Still, a denial of service that requires
>> users already be logged into the machine is a far smaller security
>> hole. ?Right now, a clever hacker could most likely find a way to
>> cause one of the less well maintained speech-dispatcher subsystems to
>> execute arbitrary code, remotely though a wide-open TCP port. ?I think
>> a switch to file sockets is a sensible short-term fix. ?One of my
>> favorite tricks to play on blind guys I'm supporting in Vinux is to
>> start talking to them through the speech-dispatcher TCP port. ?If you
>> ever let me into a machine on your network, don't be surprised when
>> your machines running Orca start saying the strangest things!
>
> you are aware of the only listen on loopback option for speechd, and iptables 
> right?
>
> If we assume that the user isn't an idiot, and either has speechd only listen 
> on loopback, or applies iptables well, then the tcp port is only available on 
> trusted machines. ?Further it is possible to have iptables do even more 
> filtering than just what host a packet originated at.
>
> So here is the difference with a bit of work a local user can deny the tcp 
> port for use by sending huge numbers of requests, in wich case speechd will 
> slow down, possibly drop ?packets etc, but this will all make the kernel very 
> unhappy, because of how many packets we're sending. ?On the other hand the 
> same local user can very quickly make it so thatadminastrative action must be 
> taken to allow for use of speechd again, this is mostly because of the 
> location of the socket. ?You will note that ssh-agent, gpg-agent etc attach a 
> random string to the end of there socket names for this reason (its hard to 
> generate all the files needed to make a file with 6 random chars appended to 
> the name unavailable).
>
> note that while I believe this to be a bug, I *don't* consider it absolutely 
> critical because it requires a shell on the machine.
>
> Hope that clears up what I was saying :-)
> Trev
>