INFO-VAX	Mon, 01 Sep 2008	Volume 2008 : Issue 478

   Contents:
Re: Advanced Server 7.3B & VISTA
Re: Advanced Server 7.3B & VISTA
Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS)
Re: OT: SYSMAN Equiv. on AIX?
Re: Remote access vulnerability in VMS
Re: Remote access vulnerability in VMS
Re: Remote access vulnerability in VMS
VT100 terminals - free
Re: VT100 terminals - free
Re: [RBL] Current status?
Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user?
Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user? user?

----------------------------------------------------------------------

Date: Sun, 31 Aug 2008 21:46:24 -0500
From: David J Dachtera <djesys.no@spam.comcast.net>
Subject: Re: Advanced Server 7.3B & VISTA
Message-ID: <48BB5780.47BE8F5D@spam.comcast.net>

Bobby wrote:
> 
> Well, I finally made progress, just in time to forget about it over
> the upcoming holiday weekend.  It turns out that if the password is
> typed on the Vista side in "all caps", then connection to
> AdvancedServer is successful.  Entering the password in "small caps"
> fails with a "logon_not_valid" SMB message.

What are "small caps"?

D.J.D.

------------------------------

Date: Mon, 01 Sep 2008 00:05:41 -0400
From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>
Subject: Re: Advanced Server 7.3B & VISTA
Message-ID: <48bb6a12$0$90269$14726298@news.sunsite.dk>

David J Dachtera wrote:
> Bobby wrote:
>> Well, I finally made progress, just in time to forget about it over
>> the upcoming holiday weekend.  It turns out that if the password is
>> typed on the Vista side in "all caps", then connection to
>> AdvancedServer is successful.  Entering the password in "small caps"
>> fails with a "logon_not_valid" SMB message.
> 
> What are "small caps"?

I read it as:

all caps = mixed case

small caps = lower case

Arne

------------------------------

Date: Sun, 31 Aug 2008 15:01:45 -0400
From: JF Mezei <jfmezei.spamnot@vaxination.ca>
Subject: Re: Loose Cannon-dian (was: Re: DEFCON 16 and Hacking OpenVMS)
Message-ID: <48baeacd$0$12389$c3e8da3@news.astraweb.com>

Main, Kerry wrote:

> No - all vendors (not just VMS) are only responding to what Cust's say
> they want.


Oh come on now. This is like supermarkets. Supermarkets don't carry what
customers say they want. They carry what manufacturers tell them to
carry (and pay them to carry).

HP doesn't respond to customers, they identify potential additional
profit sources and then make pretty speeches and powerpoints to try to
set new trends that will get the clueless CIOs to say "we need to do
that too".

Carly was especially good at that, with lots of pretty speeches that
trying to convince CIOs it was necessary to adopt her new philosophy to
survice. (I use "philosophy" here because  stuff like "Adaptive
enterprise" were more a question of a marketing than tangible products.

------------------------------

Date: Sun, 31 Aug 2008 21:32:26 -0500
From: David J Dachtera <djesys.no@spam.comcast.net>
Subject: Re: OT: SYSMAN Equiv. on AIX?
Message-ID: <48BB543A.7E0A1737@spam.comcast.net>

Bob Koehler wrote:
> 
> From: David J Dachtera <djesys.no@spam.comcast.net>
> 
> > Is anyone aware of a SYSMAN-like utility for AIX? I need to be able to
> > execute the same command on multiple LPARs, HACMP not withstanding.
> 
>    Someone with a similar problem on HP-UX used rsync.  I think they
>    had cron jobs to look for scripts.

Rsync was suggested as an approach to the "central repository" question.
Has its issues, but also has considerable merit from what I've ssen so
far.

Not sure how Rsync would help execute the same command on every LPAR in
a group.

D.J.D.

------------------------------

Date: 31 Aug 2008 22:44:18 +0200
From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER)
Subject: Re: Remote access vulnerability in VMS
Message-ID: <48bb1ec2$1@news.langstoeger.at>

In article <slrngbhckd.8a.BRAD@rabbit.turquoisewitch.com>, BRAD@rabbit.turquoisewitch.com (Brad Hamilton) writes:
>You know, the SMGSHR MUP came out in a pretty timely fashion,

That is too easy to say.
It seems this vulnerability is/was there in VMS since decades.
How do you know that it only was found recently?

The presenter at DEFCON16 told, it was found months before...

It was fixed in a 'timely' fashion after DEFCON16, but this could have been
decades after the real first exploit...

So, please, don't take it the easy way (as you obviously did)...

-- 
Peter "EPLAN" LANGSTÖGER
Network and OpenVMS system specialist
E-mail  Peter@LANGSTOeGER.at
A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist

------------------------------

Date: Sun, 31 Aug 2008 17:01:33 -0500
From: BRAD@rabbit.turquoisewitch.com (Brad Hamilton)
Subject: Re: Remote access vulnerability in VMS
Message-ID: <slrngbm55i.dm.BRAD@rabbit.turquoisewitch.com>

In article <48bb1ec2$1@news.langstoeger.at>, Peter 'EPLAN' LANGSTOeGER wrote:
>In article <slrngbhckd.8a.BRAD@rabbit.turquoisewitch.com>, 
>BRAD@rabbit.turquoisewitch.com (Brad Hamilton) writes:
>>You know, the SMGSHR MUP came out in a pretty timely fashion,
>
>That is too easy to say.
>It seems this vulnerability is/was there in VMS since decades.
>How do you know that it only was found recently?
>
>The presenter at DEFCON16 told, it was found months before...
>
>It was fixed in a 'timely' fashion after DEFCON16, but this could have been
>decades after the real first exploit...
>
>So, please, don't take it the easy way (as you obviously did)...

My only "proof" for the timeliness of the fix is the "fact" that although the
vuln existed for "decades", it was only demonstrated recently.  If in fact
someone had "exploited" it decaeds ago, surely we would have heard about it by
now.

If a bank could be easily and safely robbed, why would the robbers wait for
decades?
:-)

To my friends at DEFCON16 - please don't take the above example to construe in
any way that I think you are the "bad guys" - your work with c.o.v. proves
otherwise.
[...]

------------------------------

Date: Sun, 31 Aug 2008 22:25:06 -0400
From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>
Subject: Re: Remote access vulnerability in VMS
Message-ID: <48bb5280$0$90262$14726298@news.sunsite.dk>

Brad Hamilton wrote:
> In article <48bb1ec2$1@news.langstoeger.at>, Peter 'EPLAN' LANGSTOeGER wrote:
>> In article <slrngbhckd.8a.BRAD@rabbit.turquoisewitch.com>, 
>> BRAD@rabbit.turquoisewitch.com (Brad Hamilton) writes:
>>> You know, the SMGSHR MUP came out in a pretty timely fashion,
>> That is too easy to say.
>> It seems this vulnerability is/was there in VMS since decades.
>> How do you know that it only was found recently?
>>
>> The presenter at DEFCON16 told, it was found months before...
>>
>> It was fixed in a 'timely' fashion after DEFCON16, but this could have been
>> decades after the real first exploit...
>>
>> So, please, don't take it the easy way (as you obviously did)...
> 
> My only "proof" for the timeliness of the fix is the "fact" that although the
> vuln existed for "decades", it was only demonstrated recently.  If in fact
> someone had "exploited" it decaeds ago, surely we would have heard about it by
> now.
> 
> If a bank could be easily and safely robbed, why would the robbers wait for
> decades?

The fact that no use of an exploit has been publicized does not
guarantee that it has not been used.

Maybe the incident was never discovered, maybe the incident was
discovered but the method was not.

I don't think it is likely, but we really don't know for sure.

There is an old saying that a perfect crime is a crime not even
discovered.

Arne

------------------------------

Date: Sun, 31 Aug 2008 16:55:37 -0500
From: "Lee K. Gleason" <lee.gleason@comcast.net>
Subject: VT100 terminals - free
Message-ID: <L92dnYuWEaDEjibVnZ2dnUVZ_szinZ2d@comcast.com>

  I'm once again thinning my collection - I have two VT100 terminals with
keyboards,  in good working order and good cosmetic condition, that I don;t
need any longer.. Before I endure the annoyance that listing them on Ebay
entails  (and the consequent further annoyance of packing bulky terminals
for shipping), I'm offering them free for pickup in Houston Texas, USA, near
the North Loop and Highway 290. Please email for details.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason@comcast.net

------------------------------

Date: Sun, 31 Aug 2008 21:52:11 -0500
From: David J Dachtera <djesys.no@spam.comcast.net>
Subject: Re: VT100 terminals - free
Message-ID: <48BB58DB.73C818CC@spam.comcast.net>

"Lee K. Gleason" wrote:
> 
>   I'm once again thinning my collection - I have two VT100 terminals with
> keyboards,  in good working order and good cosmetic condition, that I don;t
> need any longer.. Before I endure the annoyance that listing them on Ebay
> entails  (and the consequent further annoyance of packing bulky terminals
> for shipping), I'm offering them free for pickup in Houston Texas, USA, near
> the North Loop and Highway 290. Please email for details.
> --
> Lee K. Gleason N5ZMR
> Control-G Consultants
> lee.gleason@comcast.net

Reply-ing to add the comp.terminals ng...

D.J.D.

------------------------------

Date: Sun, 31 Aug 2008 21:38:01 -0500
From: David J Dachtera <djesys.no@spam.comcast.net>
Subject: Re: [RBL] Current status?
Message-ID: <48BB5589.405762E9@spam.comcast.net>

Phillip Helbig---remove CLOTHES to reply wrote:
> 
> In article <48b43770@news.langstoeger.at>, peter@langstoeger.at (Peter
> 'EPLAN' LANGSTOeGER) writes:
> 
> > What is the current status of RBLs?
> > Which one do you use?
> 
> I've been using Spamhaus as my only RBL for a while now.  Seems to work
> fine.  I get a few thousand SMTP connection attempts per day.  Perhaps 5
> spam emails per day get through.  Although something like this is
> difficult to detect, I don't think false positives are a problem. 

Actually, false positives are a *BIG* problem! Fortunately, on the VMS
systems we just de-implemented, all of the important pages were sent by
HTTP using WGET (Thanx, SMS, for a very useful solution!)

*ALL* of the AIX pages are sent via SMTP, and our paging provider uses
spamhaus, also. SO, when we get a lone PC inside the firewall that gets
infected due to unsafe surfing and starts blasting spam all over he
known universe, our physician and other caregivers as well as our
technical people stop getting important message by pager.

So yes, false positives are all too common and immediately become a
*HUGE* problem!

D.J.D.

------------------------------

Date: 31 Aug 2008 22:54:15 +0200
From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER)
Subject: Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user?
Message-ID: <48bb2117$1@news.langstoeger.at>

In article <48B7617D.CFDC1D33@spam.comcast.net>, David J Dachtera <djesys.no@spam.comcast.net> writes:
>Also, have you tried filtering ANAL/AUDIT using /IGNORE=USERNAME=BACKUP?

Out of scope as well (as written)

So, I take it as I haven't overseen something obvious...
-- 
Peter "EPLAN" LANGSTÖGER
Network and OpenVMS system specialist
E-mail  Peter@LANGSTOeGER.at
A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist

------------------------------

Date: Sun, 31 Aug 2008 21:44:04 -0500
From: David J Dachtera <djesys.no@spam.comcast.net>
Subject: Re: [VMS V7/8] How to avoid filling sec audit with entries of BACKUP user? user?
Message-ID: <48BB56F4.881E4A23@spam.comcast.net>

Peter 'EPLAN' LANGSTOeGER wrote:
> 
> In article <48B7617D.CFDC1D33@spam.comcast.net>, David J Dachtera <djesys.no@spam.comcast.net> writes:
> >Also, have you tried filtering ANAL/AUDIT using /IGNORE=USERNAME=BACKUP?
> 
> Out of scope as well (as written)

Can you explain?

> So, I take it as I haven't overseen something obvious...

It depends. I think I know what you're trying to accomplish. However, so
far, all of the solutions that are synergistically compatible with the
design of the AUDIT facility have been flagged as "out of scope", what
ever that might mean. A solution to a stated problem is, by definition,
"in scope". 

So, I'm stymied at this point. It almost sounds like you're looking for
a re-write of the AUDIT facility to allow users to side-step security
selectively (*BIG* security hole!), beyond BYPASS privilege.

D.J.D.

------------------------------

End of INFO-VAX 2008.478
************************