>Date: Tue, 7 Aug 2001 14:40:27 -0500
>From: "Bill Layer" <blayer at qwest.net>
>To: tclug-list at mn-linux.org
>Subject: [TCLUG] Potential security issue in CBOS 2.4.2
>Reply-To: tclug-list at mn-linux.org
>
>I have come across what seems to be a security problem in CBOS 2.4.2
>(perhaps 2.4.1 also?), and I would like some verification before I get too
>excited about it. The problem relates to the serial port idle timeout, and
>may similarly affect the telnet timeout; this I haven't tested.
>
>Problem: When the serial port session timeout is set to 300 seconds (5
>minutes), which appears to have been the default on my 675 since CBOS
>2.0.X, the serial port session NEVER times out. If you count on serial
>timeout to re-secure the serial console, you have a secutiry issue. 
>
>
>Can a few of you with a 675 -AND- CBOS 2.4.2 please check the following:
>
>1) That your serial console timeout is set to 300 seconds by default
>(cbos# show serial)
>
>2) That when set for 300 seconds, the serial console never times out (or,
>at least doesn't time out in 300 seconds (5 minutes))
>
>3) That when set to 100 seconds or less, the serial console times out
>correctly.
>(cbos# set serial timeout 100)

>Date: Tue, 7 Aug 2001 14:51:02 -0400
>From: Dan Drake <drake at lemongecko.myip.org>
>To: tclug-list at mn-linux.org
>Subject: Re: [TCLUG] Potential security issue in CBOS 2.4.2
>Reply-To: tclug-list at mn-linux.org
>
>On Tue, Aug 07, 2001 at 02:40:27PM -0500, Bill Layer wrote:
>> How I discovered this: I logged onto my 675 serial console today, and was
>> not prompted for a password. It was still in 'enable' mode (#) from my
>> last session, the one which I began immediately after upgrading from CBOS
>> 2.4.1 to CBOS 2.4.2. I never noticed this behavior with any CBOS prior to
>> 2.4.2, but that doesn't mean it's not there. 
>
>I used to have a 678 and this seems very familiar. I remember connecting
>with minicom and not having to type in passwords. I can't verify that, but
>this seems very familiar.


My new (Dan's old) Cisco678 when  reprogrammed with cap2.4.1 also
failed to time out at default limit. Could this be an 8bit register
problem limiting the sec=256max?