Well, after more than a tad of thrashing and rework (mainly due to my own
paranoia - I'm trying to make Elvis reasonably secure against attacks and
hangs) Elvis is alive!
Aside from the rename (dropped the J, which got added in a moment of low
lemming resistance - thanks for the nudge Kevin!), Elvis is now able to
determine if he is or is not the only Elvis implementing a given program, and
if he is not, defer to the more senior Elvis.
I haven't gotten as far as having Elvis do actually anything yet, but it's
going to be a cool, damp weekend, with two Nascar races on the net broadcast,
so I suspect a good bit of work will get done.
At this point, I'm going to babble incoherently about some security related
details. If you have the inclination to read further, I'd appreciate
feedback on these points.
As I mentioned above, I've been a bit paranoid about the connection setup.
Elvis talks to himself in "one liners" - single line messages consisting of a
sequence of header tokens (three header tokens, identifying it as an Elvis
message, for a given program, and a key identifying the specific incarnation
of Elvis who is (supposedly) the Real Elvis at this time), an action token
indicating what it is we want Elvis to do, and an optional data token, which
can be any arbitrary plain text string (not including end-of-line). The
response is a similar "one liner", with a status token substituted for the
action token. In both cases all three header tokens must be correct for
Elvis to accept the communication. The whole point of this is to help
prevent spoofing attacks, where one user attempts to get another user's Elvis
to do something. At the moment, though, this whole effort is short circuited
because the key is stored in world readable plain text in a well known file
in a well known directory. Once that is secured (by making it readable only
be the proper user), the whole structure hardens up nicely.
For additional paranoia, the Elvis port is chosen semi-randomly, by adding a
random offset to a base port number supplied by the client.. This should
make port guessing by an attacker difficult, except that the port number is
stored in the same vulnerable directory mentioned above (and can be fixed in
the same way).
Right now, if Elvis receives a connection attempt from a machine other than
the local host, he decides that he's under attack and exits immediately.
This could be inconvenient in a production environment, and needs some more
thought. Since Java is inherently resistant to buffer overflow attacks, that
isn't a big concern. It might be more appropriate to simply have Elvis log
such attempts and discard the connections without further action.
The goal is to close any doors through which an attacker could get an Elvis
implementation to do something. For OpenJNLP, this could include worm
programs, trojans, or access to otherwise secure data.
Chris
|
