Yes, the pmvision/etc method is one I did not think about, because I
rarely use it for anything to begin with. My bad. And yes, there are
ways to get into a PM via serial connections to other devices. I fully
concede that there are other ways to get into the box that I did not
consider. The severity of the problem is probably not as great as what
I originally stated, since there are several options for recovery.
I admit that in my rush to get the information out there, I failed to
consider some of those options, and I don't think the problem is as
serious as I originally did. It is an annoyance, but not a major security
threat. Still, after taking it down a notch in severity, there -is-
still a problem in ComOS, and I think it deserves to be addressed at
some point.
> OR just do what you are SUPPOSED to do to guard against a D.O.S. attack
> and use filters. Have you tried setting a permit 23 from only 1 host, deny
> from all others, then tried to bomb the unit?
Of -course- that will stop it. I said as much in my initial message, that
a firewall or filter would offer protection. And of course you should have
any RAS/router protected in such a way. That was not my point.
The point is that there is a problem in the ComOS telnet/login code, and
the fact that you can throw filters up to minimize the risk does not mean
the problem should not be fixed. If you do the same thing against a
FreeBSD system, and presumably many/most other Unix systems, it does not
lockup the network connection. Why should we expect ComOS to be any
different? There are reasons to explain the different behaviour, but
they do not justify that behaviour, once the problem is pointed out.
I argue that it would be good to fix this. Filters and firewalls can
protect you, but ComOS should not rely on these being in place. There
are very likely a large number of ComOS devices that are not properly
protected, and to the extent that ComOS can be "hardened", it should be,
unless there is a significant penalty in code size or performance.
Should ComOS be expected to work as well in an unprotected environment
as in a protected environment? No. You provide the firewalls and
filters to protect yourself from any possible problems in the equipment
itself, to minimize your exposure. Conversely, you should also make
the protected system as secure and reliable as you reasonably can, to
protect against any deficiencies in the firewalls, filters, or "trusted"
systems.
The reality is that firewalls and filters do not exist in some cases, or
are improperly implemented. The reality is that trusted systems are
sometimes compromised. The more you work to make sure that -isn't- the
case, the better off you are. But you are also better off if you have
systems which can withstand as much unprotected exposure as possible.
But hey, as I said, the risks of this particular problem are not as
severe as I originally thought. I feel the above applies for any
security-related issue, and given infinite resources, any security-related
issue should be addressed. But in the real world, the priority for
changing a system because of any given problem depends on the severity
of the exposure.
Is the exposure of this one large enough to justify a code change? I
think so, although I don't think there's a need to rush out a fix
immediately. If it were my decision, I would try to fix it in the next
regular release, and issue a security advisory listing the ways to avoid
the problem and recover from it if it happens. But I don't work for
Lucent, so we'll just have to see how they choose to deal with this.
-- Michael Bryan michael@blueneptune.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>