speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Speech Dispatcher 0.7 Beta -- Please help with testing


From: trev . saunders
Subject: Speech Dispatcher 0.7 Beta -- Please help with testing
Date: Tue, 27 Apr 2010 21:12:23 -0400

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]