Just for the sake of clarity, I will redundantly highlight some parts of
Christopher's
recent message :
Christopher Schultz wrote:
...
* If you are on 1.1.24-1.1.29, then you have been vulnerable. *
...
I can't stress enough that once you update to a fixed version, *you
must re-key your server* and obtain a replacement certificate from
your CA.
You must also consider any communication that traversed your system
while vulnerable to be compromised. That means that every password
that went through your system during the period of vulnerability ought
to be changed.
As I understand it, the real bitch about this bug, is that *during the whole period in
which your server was vulnerable* , a knowledgeable attacker would have been able to
connect to your server and grab the contents of arbitrary 64 K chunks of memory. This
could have contained *anything*, including SSL keys, certificates, decrypted passwords,
user-id's, whatever was in such a 64K chunk at that time. And he could do that as often
as he wanted, without ever being detected or leaving any trace to allow an analysis later.
And he could record this information, for leasurely inspection and analysis at
any later time.
There are at least 3 consequences :
1) if you do not change your keys and/or passwords now, then in the future that
attacker
(and whoever he gives or sells the information to) will be able to access your
server with
the stolen credentials, and do whatever these credentials allow him to do.
2) if these stolen credentials apply to other systems too, even ones that are not
vulnerable and have never been, he can use them there too.
(people use the same keys and passwords for multiple services, that's just a
fact of life)
3) if he has recorded past encrypted traffic to/from your server, and saved
this recording, then he can at any time go back and decrypt this past traffic,
and pick up
anything interesting from there, even without having the new keys. Such a recording could
contain, for example, any number of submits
from HTML login pages, which were theoretically protected by being made on an
encrypted
channel. That could probably also contain any communications which your server did with
other servers over encrypted channels.
This is all fairly complex, and would require a knowledgeable attacker, one
that knew
about this bug before "the good guys", one who had the technical means to do this kind of
thing, and some serious dedication and planning on top.
That would not be your everyday script-kiddie.
But there are people like that out there, and it may explain a-posteriori a number of
high-profile data theft incidents that happened over the last 2 years, and any number of
low-profile ones that you never heard about. The point is, nobody knows really.
So I guess that the amount of damage that this can cause is very much dependent
on what
you have been running on your server, and for whom, and how attractive your
site may have
been for such a would-be serious attacker.
I would definitely not like to be in the position of having run a HTTPS-based
electronic-payment system over the last 2 years.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
