Darren Reed wrote:
> On 11/25/09 10:45, Garrett D'Amore wrote:
>> ...
>>
>> This is totally different from nmap, btw. IIUC, nmap does scans to
>> passively identify potential weaknesses. I don't think it actually
>> has any *exploits* for them. (Put another way, I don't think "nmap"
>> used solely by itself can do serious harm. I think yersinia is quite
>> different. I think their choice of name is suitably apropos --
>> naming after the black plague.)
>>
>> I feel strongly enough about this that I'm going to derail.
>
> Let me summarise the differences that I see:
>
> * I can use nmap from my workstation at Sun to remotely probe and test
> a host connected to the Internet anywhere in the world for services
> that it provides and might be vulnerable, all the while looking like
> it is Sun doing that;
>
> * I can use yersinia to at most disrupt traffic on SWAN but more
> likely this would be restricted to the LAN segment I'm on at Sun.
>
> Whilst the primary raison d'etre for both might be different, so too
> is the scope of their aid to someone undertaking nefarious activity.
>
> yersnia isn't going to help you break into a remote host but it might
> help you become the man in the middle when you others wouldn't have.
> Even then it only threatens unencrypted traffic or encrypted traffic
> without peer authentication. It also a possible threat when the trust
> relationship between two hosts does not involve cryptography.
>
> I think that derailing this case is an over-reaction primarily because
> it has been seen as an "attack" tool without properly considering what
> the scope of its potential targets is.
Are you saying that the attacks that yersinia provides can't take down
router infrastructure?
To me it sure looks like they can. While its likely that these attacks
will be confined to just your enterprise (be it Sun, or elsewhere on
your corporate network), it still seems like they have an active
component that nmap lacks.
Picture an attach launched on a lan segment against a large corporate
router which just happens to have an interface on your segment. If this
brings down critical router infrastructure for a trading house, the cost
can amount to millions of dollars. While clearly the (ab)user of the
tool should bear the bulk of the blame and responsibility, I'm not
comfortable with the idea that our actions here might have been overly
facilitating for that user.
I actually think the fact that other distros have included this in there
Linux bits was a poor choice as well. This is an area where I believe
that other considerations probably trump "familiarity". (Further, I'd
sincerely hope that anyone using this kind of tool for non-nefarious
purposes would know enough to understand how to download and install it
from source!)
For the record, I'm not entirely convinced that including nmap was a
good idea either, but at least its probes are non-destructive in nature.
I stand by my decision; this case is derailed.
The project team now has three options:
a) present a full case to the ARC and get a vote on it
b) withdraw the case.
c) seek an appeal on the derailment. Although, I suspect that since
we have no established process for this, it would probably take more
effort than just going with option "a".
- Garrett
