f



DEFCON 16 and Hacking OpenVMS

http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg

is due to be presented this Sunday, Aug 10th 2008

Does anyone know ...

o  whether there will be anyone from the VMS community at this event;

o  the content of this presentation;

o  whether the 'proceedings' will be published?

The abstract is protraying the potential exploits as novel and so would 
make an interesting read.

--
Ticking away the moments that make up a dull day
You fritter and waste the hours in an offhand way.
Kicking around on a piece of ground in your home town
Waiting for someone or something to show you the way.
[Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
0
mark.daniel2 (266)
8/6/2008 12:10:56 PM
comp.os.vms 21904 articles. 1 followers. Post Follow

395 Replies
3268 Views

Similar Articles

[PageSpeed] 46

Mark Daniel wrote:
> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
> 
> is due to be presented this Sunday, Aug 10th 2008
> 
> Does anyone know ...
> 
> o  whether there will be anyone from the VMS community at this event;
> 
> o  the content of this presentation;
> 
> o  whether the 'proceedings' will be published?
> 
> The abstract is protraying the potential exploits as novel and so would 
> make an interesting read.

You might want to ask the question over at the Deathrow cluster - there 
are likely to be some attendees from that group.

0
bradhamilton (257)
8/6/2008 10:20:54 PM
bradhamilton wrote:
> Mark Daniel wrote:
> 
>> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
>>
>> is due to be presented this Sunday, Aug 10th 2008
>>
>> Does anyone know ...
>>
>> o  whether there will be anyone from the VMS community at this event;
>>
>> o  the content of this presentation;
>>
>> o  whether the 'proceedings' will be published?
>>
>> The abstract is protraying the potential exploits as novel and so 
>> would make an interesting read.
> 
> 
> You might want to ask the question over at the Deathrow cluster - there 
> are likely to be some attendees from that group.

I could also post on the relevant ITRC forum but VMS vulnerabilities 
likely would be considered off-topic and it end up expunged!

--
Tired of lying in the sunshine staying home to watch the rain.
You are young and life is long and there is time to kill today.
And then one day you find ten years have got behind you.
No one told you when to run, you missed the starting gun.
[Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
0
mark.daniel2 (266)
8/7/2008 8:51:01 AM
There's apparently an overflow flat in Multinet's Fingerd as well:

http://seclists.org/bugtraq/2008/Aug/0056.html

0
sampsal (134)
8/7/2008 4:31:58 PM
sampsal@gmail.com wrote:
> There's apparently an overflow flat in Multinet's Fingerd as well:
> 
> http://seclists.org/bugtraq/2008/Aug/0056.html

This appears to behave as described on at least VAX VMS V7.3 MultiNet 
V5.1 Rev A-X but not on Alpha VMS V8.3 V5.2 Rev A-X or I64 VMS V8.3 V5.2 
Rev A-X (three platforms I have access to).

$ echo `perl -e 'print "a"x1000'` | nc -v host.name 79
Connection to host.name 79 port [tcp/finger] succeeded!

I guess we can assume the 'group of lads' would be keeping an occasional 
eye on c.o.v. :-)

--
So you run and you run to catch up with the sun but it's sinking
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
[Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
0
mark.daniel2 (266)
8/7/2008 6:15:19 PM
------=_Part_50369_12868342.1218154283494
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Aug 6, 2008 at 8:10 AM, Mark Daniel <mark.daniel@vsm.com.au> wrote:

> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
>
> is due to be presented this Sunday, Aug 10th 2008
>
> Does anyone know ...
>
> o  whether there will be anyone from the VMS community at this event;
>
> o  the content of this presentation;
>
> o  whether the 'proceedings' will be published?
>
> The abstract is protraying the potential exploits as novel and so would
> make an interesting read.
>
> --
> Ticking away the moments that make up a dull day
> You fritter and waste the hours in an offhand way.
> Kicking around on a piece of ground in your home town
> Waiting for someone or something to show you the way.
> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>


The last "black hat" stuff I read (and it was a while ago) was quite
outdated and went back to the days when SYSTEM, FIELD, etc had default
passwords set at installation time.

That's no longer the case, and has been for some time.

WWWebb

------=_Part_50369_12868342.1218154283494
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><br><br>
<div class="gmail_quote">On Wed, Aug 6, 2008 at 8:10 AM, Mark Daniel <span dir="ltr">&lt;<a href="mailto:mark.daniel@vsm.com.au">mark.daniel@vsm.com.au</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><a href="http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg" target="_blank">http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg</a><br>
<br>is due to be presented this Sunday, Aug 10th 2008<br><br>Does anyone know ...<br><br>o &nbsp;whether there will be anyone from the VMS community at this event;<br><br>o &nbsp;the content of this presentation;<br><br>o &nbsp;whether the &#39;proceedings&#39; will be published?<br>
<br>The abstract is protraying the potential exploits as novel and so would make an interesting read.<br><font color="#888888"><br>--<br>Ticking away the moments that make up a dull day<br>You fritter and waste the hours in an offhand way.<br>
Kicking around on a piece of ground in your home town<br>Waiting for someone or something to show you the way.<br>[Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]<br></font></blockquote></div>
<div><br>&nbsp;</div>
<div>The last &quot;black hat&quot; stuff I read (and it was a while ago) was quite outdated and went back to the days when SYSTEM, FIELD, etc had default passwords set at installation time.</div>
<div>&nbsp;</div>
<div>That&#39;s no longer the case, and has been for some time.</div>
<div><br>WWWebb</div></div>

------=_Part_50369_12868342.1218154283494--
0
8/8/2008 12:11:23 AM
Mark Daniel wrote:
> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
> 
> is due to be presented this Sunday, Aug 10th 2008
> 
> Does anyone know ...
> 
> o  whether there will be anyone from the VMS community at this event;
> 
> o  the content of this presentation;
> 
> o  whether the 'proceedings' will be published?
> 
> The abstract is protraying the potential exploits as novel and so would 
> make an interesting read.

I will wait for this weekend, like some of us, but in the meantime, I 
will note that one of the presenters claims to have an interest in 
"social engineering".  Of course, the abstract promises "0day 
vulnerabilities", but we will have to wait and see.
0
bradhamilton (257)
8/8/2008 12:37:17 AM
In article <8660a3a10808071711y49326bci2d6514c28357e72d@mail.gmail.com>, "William Webb" <william.w.webb@gmail.com> writes:
> 
> The last "black hat" stuff I read (and it was a while ago) was quite
> outdated and went back to the days when SYSTEM, FIELD, etc had default
> passwords set at installation time.
> 
> That's no longer the case, and has been for some time.

   There's a fairly easy to find (or it was last time I bothered
   looking) guide to hacking VMS that I think you're talking about.

   It was written to a default installation and bad system management
   prior to VMS 5.0.  It used the canned passwords to get access to
   a privileged account.  It told of all kinds of little things a
   privileged account could do.

   Unless the DEFCON sessions reports ways to access a system without
   authorization, or elevate your privileges to a higher class without 
   authorization, on a properly installed and managed system, it's just 
   smoke up your virtual skirt.

   We wait to see.

0
koehler2 (8314)
8/8/2008 12:49:44 PM
In article <00a990b4$0$20308$c3e8da3@news.astraweb.com>, Mark Daniel <mark.daniel@vsm.com.au> writes:
> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
> 
> is due to be presented this Sunday, Aug 10th 2008
> 

Does anyone know what happened with this ?

Thanks,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
8/11/2008 11:40:37 AM
I guess they are still "challenged" by the "rout of '01", delivered 
handily by OpenVMS on Alpha courtesy of The Wiz, Coremac, and Opcom; the 
legend of which is chronicled here:
http://www.bunkerofdoom.com/defcon/defcon9.html

-or maybe they forgot about it and this is completely new.
The rules of the 'game' were changed forever. But never mind;



By the time I saw it, it was too late to get in the truck and drive to 
the DEFCON by myself.

Patrick J.

Mark Daniel wrote:
> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
> 
> is due to be presented this Sunday, Aug 10th 2008
> 
0
eccm (54)
8/12/2008 2:47:38 AM
this also, of the past..
http://www.openvms.org/stories.php?story=07/05/18/5543122

just to pass some time till someone can report.
0
eccm (54)
8/12/2008 3:13:34 AM
------=_Part_93310_28637544.1218514004681
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Aug 11, 2008 at 10:47 PM, patrick jankowiak <eccm@swbell.net> wrote:

> I guess they are still "challenged" by the "rout of '01", delivered handily
> by OpenVMS on Alpha courtesy of The Wiz, Coremac, and Opcom; the legend of
> which is chronicled here:
> http://www.bunkerofdoom.com/defcon/defcon9.html
>
> -or maybe they forgot about it and this is completely new.
> The rules of the 'game' were changed forever. But never mind;
>
>
>
> By the time I saw it, it was too late to get in the truck and drive to the
> DEFCON by myself.
>
> Patrick J.
>
>
> Mark Daniel wrote:
>
>> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
>>
>> is due to be presented this Sunday, Aug 10th 2008
>>
>>
Hi, Pat-

Good to see you posting.  "What I Did On My Summer Vacation" is one of the
funniest VMS stories I've ever heard, and I've heard some Real Funny Ones at
"Magic Night" at the last two bootcamps.

WWWebb

------=_Part_93310_28637544.1218514004681
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><br><br>
<div class="gmail_quote">On Mon, Aug 11, 2008 at 10:47 PM, patrick jankowiak <span dir="ltr">&lt;<a href="mailto:eccm@swbell.net">eccm@swbell.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I guess they are still &quot;challenged&quot; by the &quot;rout of &#39;01&quot;, delivered handily by OpenVMS on Alpha courtesy of The Wiz, Coremac, and Opcom; the legend of which is chronicled here:<br>
<a href="http://www.bunkerofdoom.com/defcon/defcon9.html" target="_blank">http://www.bunkerofdoom.com/defcon/defcon9.html</a><br><br>-or maybe they forgot about it and this is completely new.<br>The rules of the &#39;game&#39; were changed forever. But never mind;<br>
<br><br><br>By the time I saw it, it was too late to get in the truck and drive to the DEFCON by myself.<br><br>Patrick J. 
<div>
<div></div>
<div class="Wj3C7c"><br><br>Mark Daniel wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><a href="http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg" target="_blank">http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg</a><br>
<br>is due to be presented this Sunday, Aug 10th 2008<br><br></blockquote></div></div></blockquote></div>
<div>&nbsp;</div>
<div>Hi, Pat-</div>
<div>&nbsp;</div>
<div>Good to see you posting.&nbsp; &quot;What I Did On My Summer Vacation&quot; is one of the funniest VMS stories I&#39;ve ever heard, and I&#39;ve heard some Real Funny Ones at &quot;Magic Night&quot; at the last two bootcamps.</div>

<div><br>WWWebb<br></div></div>

------=_Part_93310_28637544.1218514004681--
0
8/12/2008 4:06:44 AM
William Webb wrote:
> 
> 
> On Mon, Aug 11, 2008 at 10:47 PM, patrick jankowiak <eccm@swbell.net 
> <mailto:eccm@swbell.net>> wrote:
> 
>     I guess they are still "challenged" by the "rout of '01", delivered
>     handily by OpenVMS on Alpha courtesy of The Wiz, Coremac, and Opcom;
>     the legend of which is chronicled here:
>     http://www.bunkerofdoom.com/defcon/defcon9.html
> 
>     -or maybe they forgot about it and this is completely new.
>     The rules of the 'game' were changed forever. But never mind;
> 
> 
> 
>     By the time I saw it, it was too late to get in the truck and drive
>     to the DEFCON by myself.
> 
>     Patrick J.
> 
> 
>     Mark Daniel wrote:
> 
>         http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
> 
>         is due to be presented this Sunday, Aug 10th 2008
> 
>  
> Hi, Pat-
>  
> Good to see you posting.  "What I Did On My Summer Vacation" is one of 
> the funniest VMS stories I've ever heard, and I've heard some Real Funny 
> Ones at "Magic Night" at the last two bootcamps.
> 
> WWWebb

Hi William,

Thank you and I guess I need to show up to the party from time to time. 
I guess I sort of navigated past the edge of the known world, and found 
more worlds and adventures to explore.
0
eccm (54)
8/12/2008 6:01:55 AM
Guys,

I just finished reading the presenation slides from DEFCON and
fortunately it doesn't to be anything earth-shattering, two exploits
are described:

1. A format string vulnerability in the FINGER client (VAX only). The
example shellcode is stored on a remote system's .plan file and forces
the victim FINGER client to modify SYSUAF.

2. A CLI buffer overflow on Alphas. Basically any input over 511
characters causes an overflow, it seems to be possible to have a
privileged process execute arbitrary code.

Anyway, this is from a 10 minute reading of the slides, I might have
missed something, but the important thing (IMHO) is that neither of
these exploits are possible from remote but require a malicious user
to already have an account on the targeted system.

Sampsa



0
sampsal (134)
8/12/2008 1:58:40 PM
In article <6419afac-bb99-4d7d-b61c-2e29234dfb26@z72g2000hsb.googlegroups.com>, sampsal@gmail.com writes:
>Guys,
>
>I just finished reading the presenation slides from DEFCON and
>fortunately it doesn't to be anything earth-shattering, two exploits
>are described:
>
>1. A format string vulnerability in the FINGER client (VAX only). The
>example shellcode is stored on a remote system's .plan file and forces
>the victim FINGER client to modify SYSUAF.
>

Is this with DEC TCPIP services or is it something to do with the
Multinet finger vulnerability ?

see

http://www.multinet.process.com/scripts/eco/eco_tlb.com?FINGER-010_A052



>2. A CLI buffer overflow on Alphas. Basically any input over 511
>characters causes an overflow, it seems to be possible to have a
>privileged process execute arbitrary code.
>
Can you explain this one in a bit more detail ?
Is this an attack against DCL itself, images installed with privileges
or something else ?


David Webb
Security team leader
CCSS
Middlesex University




>Anyway, this is from a 10 minute reading of the slides, I might have
>missed something, but the important thing (IMHO) is that neither of
>these exploits are possible from remote but require a malicious user
>to already have an account on the targeted system.
>
>Sampsa
>
>
>
0
david20
8/12/2008 2:49:51 PM
> >1. A format string vulnerability in the FINGER client (VAX only). The
> >example shellcode is stored on a remote system's .plan file and forces
> >the victim FINGER client to modify SYSUAF.
>
> Is this with DEC TCPIP services or is it something to do with the
> Multinet finger vulnerability ?

It appears to be something separate, since it seems to have to do with
a format string
vulnerability. Basically someone puts a bunch of % strings and
shellcode in their .plan
on a remote host, fingers that user from the target host, and the
FINGER client executes
the shellcode due to the format string vulnerability in the client.


> >2. A CLI buffer overflow on Alphas. Basically any input over 511
> >characters causes an overflow, it seems to be possible to have a
> >privileged process execute arbitrary code.
>
> Can you explain this one in a bit more detail ?
> Is this an attack against DCL itself, images installed with privileges
> or something else ?

I think this might be a DCL issue, it seems to work across a number of
different images. Not had a chance to play with this as my own VMS
box is down at the moment.

Sampsa
0
sampsal (134)
8/12/2008 3:27:47 PM
In article <6419afac-bb99-4d7d-b61c-2e29234dfb26@z72g2000hsb.googlegroups.com>, sampsal@gmail.com writes:
> Guys,
> 
> 1. A format string vulnerability in the FINGER client (VAX only). The
> example shellcode is stored on a remote system's .plan file and forces
> the victim FINGER client to modify SYSUAF.

   Do they say which finger client?  HPs?
 
0
koehler2 (8314)
8/12/2008 4:58:47 PM
In article <6419afac-bb99-4d7d-b61c-2e29234dfb26@z72g2000hsb.googlegroups.com>, sampsal@gmail.com writes:
> Guys,
> 
> I just finished reading the presenation slides from DEFCON and
> fortunately it doesn't to be anything earth-shattering, two exploits
> are described:

   Are these publically available?  (If there is anything in them, I'd
   like to review my systems).

0
koehler2 (8314)
8/12/2008 5:00:02 PM
On Aug 12, 6:00=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <6419afac-bb99-4d7d-b61c-2e29234df...@z72g2000hsb.googlegroups=
..com>, samp...@gmail.com writes:
>
> > Guys,
>
> > I just finished reading the presenation slides from DEFCON and
> > fortunately it doesn't to be anything earth-shattering, two exploits
> > are described:
>
> =A0 =A0Are these publically available? =A0(If there is anything in them, =
I'd
> =A0 =A0like to review my systems).

I got them from a friend who's colleague was at DEFCON - I don't know
what the distribution/copyright issues are with the document so I
daren't host them on my web page.

Sampsa

0
sampsal (134)
8/12/2008 5:26:13 PM
sampsal@gmail.com wrote:
>>> 1. A format string vulnerability in the FINGER client (VAX only). The
>>> example shellcode is stored on a remote system's .plan file and forces
>>> the victim FINGER client to modify SYSUAF.
>> Is this with DEC TCPIP services or is it something to do with the
>> Multinet finger vulnerability ?
> 
> It appears to be something separate, since it seems to have to do with
> a format string
> vulnerability. Basically someone puts a bunch of % strings and
> shellcode in their .plan
> on a remote host, fingers that user from the target host, and the
> FINGER client executes
> the shellcode due to the format string vulnerability in the client.
> 
> 
>>> 2. A CLI buffer overflow on Alphas. Basically any input over 511
>>> characters causes an overflow, it seems to be possible to have a
>>> privileged process execute arbitrary code.
>> Can you explain this one in a bit more detail ?
>> Is this an attack against DCL itself, images installed with privileges
>> or something else ?
> 
> I think this might be a DCL issue, it seems to work across a number of
> different images. Not had a chance to play with this as my own VMS
> box is down at the moment.
> 
> Sampsa

I would have thought a CLI overflow to have been tried by at least a few 
at DEFCON9 because the system automagically created service-rich user 
accounts with of course DCL which the hackers were then free to abuse.

We were not scrutinizing buffers however and any such overflow may in 
our case have done nothing harmful (by luck or design). I think it was 
version 7.1-? if it makes a difference. Did the gentleman specify any 
versions?

Patrick J
0
eccm (54)
8/13/2008 12:44:55 AM
> I would have thought a CLI overflow to have been tried by at least a few
> at DEFCON9 because the system automagically created service-rich user
> accounts with of course DCL which the hackers were then free to abuse.
>
> We were not scrutinizing buffers however and any such overflow may in
> our case have done nothing harmful (by luck or design). I think it was
> version 7.1-? if it makes a difference. Did the gentleman specify any
> versions?

Default 8.3 install on an Alpha according to the presentation notes.
To reproduce this, apparently one is to enter exactly 511 characters
of input, then press the up arrow three times and wait - a core dump
follows.

Sampsa

0
sampsal (134)
8/13/2008 8:22:14 AM
In article <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, sampsal@gmail.com writes:
>> I would have thought a CLI overflow to have been tried by at least a few
>> at DEFCON9 because the system automagically created service-rich user
>> accounts with of course DCL which the hackers were then free to abuse.
>>
>> We were not scrutinizing buffers however and any such overflow may in
>> our case have done nothing harmful (by luck or design). I think it was
>> version 7.1-? if it makes a difference. Did the gentleman specify any
>> versions?
>
>Default 8.3 install on an Alpha according to the presentation notes.
>To reproduce this, apparently one is to enter exactly 511 characters
>of input, then press the up arrow three times and wait - a core dump
>follows.

I know you didn't make the claim but you should first test it out before
brandishing bullshit here.

I've tried to reproduce the claimed results from your posted instruction
and it does NOT produce a "core dump". 

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/13/2008 11:30:15 AM
> >Default 8.3 install on an Alpha according to the presentation notes.
> >To reproduce this, apparently one is to enter exactly 511 characters
> >of input, then press the up arrow three times and wait - a core dump
> >follows.
>
> I know you didn't make the claim but you should first test it out before
> brandishing bullshit here.
>
> I've tried to reproduce the claimed results from your posted instruction
> and it does NOT produce a "core dump".

Hey don't shoot the messenger, people were interested in what was in
the presentation, I just relayed that information WITH THE CAVEAT THAT
I DIDN'T TEST IT. They had screenshots of the flaw and source code for
an exploit, based on that I assumed it's genuine even if we haven't
been able to reproduce it.

I'm not trying to scaremonger or stir up shit, in fact I stated in my
original post that neither of these exploits seemed particularly earth
shattering.

Sampsa


0
sampsal (134)
8/13/2008 11:56:05 AM
sampsal@gmail.com wrote:
>>>Default 8.3 install on an Alpha according to the presentation notes.
>>>To reproduce this, apparently one is to enter exactly 511 characters
>>>of input, then press the up arrow three times and wait - a core dump
>>>follows.
>>
>>I know you didn't make the claim but you should first test it out before
>>brandishing bullshit here.
>>
>>I've tried to reproduce the claimed results from your posted instruction
>>and it does NOT produce a "core dump". 
> 
> Hey don't shoot the messenger, people were interested in what was in
> the presentation, I just relayed that information WITH THE CAVEAT THAT
> I DIDN'T TEST IT. They had screenshots of the flaw and source code for
> an exploit, based on that I assumed it's genuine even if we haven't
> been able to reproduce it.

I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha 
on which to try.  It too failed to fail in any way.  Curiously, I just 
happened to build an off-the-CD V8.3 Alpha only this morning in my 
workplace (just a pastime unfortunately) and intended to try it there 
and report tomorrow.  Of course it could even be Alpha chip type 
-specific (fail on an EV56 but not an EV67, etc.) making it more obscure 
but none-the-less real even if less-than adequately documented.  The 
exploit might be more telling.  Thanks for your ongoing reports.

> I'm not trying to scaremonger or stir up shit, in fact I stated in my
> original post that neither of these exploits seemed particularly earth
> shattering.
> 
> Sampsa

--
Every year is getting shorter never seem to find the time.
Plans that either come to naught or half a page of scribbled lines
Hanging on in quiet desperation is the English way
The time is gone, the song is over,
Thought I'd something more to say.
[Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
0
mark.daniel2 (266)
8/13/2008 1:17:47 PM
On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
> samp...@gmail.com wrote:
> >>>Default 8.3 install on an Alpha according to the presentation notes.
> >>>To reproduce this, apparently one is to enter exactly 511 characters
> >>>of input, then press the up arrow three times and wait - a core dump
> >>>follows.
>
> >>I know you didn't make the claim but you should first test it out before
> >>brandishing bullshit here.
>
> >>I've tried to reproduce the claimed results from your posted instruction
> >>and it does NOT produce a "core dump".
>
> > Hey don't shoot the messenger, people were interested in what was in
> > the presentation, I just relayed that information WITH THE CAVEAT THAT
> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
> > an exploit, based on that I assumed it's genuine even if we haven't
> > been able to reproduce it.
>
> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
> on which to try.  It too failed to fail in any way.  Curiously, I just
> happened to build an off-the-CD V8.3 Alpha only this morning in my
> workplace (just a pastime unfortunately) and intended to try it there
> and report tomorrow.  Of course it could even be Alpha chip type
> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
> but none-the-less real even if less-than adequately documented.  The
> exploit might be more telling.  Thanks for your ongoing reports.
>
> > I'm not trying to scaremonger or stir up shit, in fact I stated in my
> > original post that neither of these exploits seemed particularly earth
> > shattering.
>
> > Sampsa
>
> --
> Every year is getting shorter never seem to find the time.
> Plans that either come to naught or half a page of scribbled lines
> Hanging on in quiet desperation is the English way
> The time is gone, the song is over,
> Thought I'd something more to say.
> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]

$ sh sys
VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
19:22:37
<truncate..>

$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
%DCL-W-TKNOVF, command element is too long - shorten
0
jferraro (20)
8/13/2008 11:02:36 PM
On Aug 13, 7:02 pm, jferraro <jferr...@gmail.com> wrote:
> On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>
>
>
> > samp...@gmail.com wrote:
> > >>>Default 8.3 install on an Alpha according to the presentation notes.
> > >>>To reproduce this, apparently one is to enter exactly 511 characters
> > >>>of input, then press the up arrow three times and wait - a core dump
> > >>>follows.
>
> > >>I know you didn't make the claim but you should first test it out before
> > >>brandishing bullshit here.
>
> > >>I've tried to reproduce the claimed results from your posted instruction
> > >>and it does NOT produce a "core dump".
>
> > > Hey don't shoot the messenger, people were interested in what was in
> > > the presentation, I just relayed that information WITH THE CAVEAT THAT
> > > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
> > > an exploit, based on that I assumed it's genuine even if we haven't
> > > been able to reproduce it.
>
> > I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
> > on which to try.  It too failed to fail in any way.  Curiously, I just
> > happened to build an off-the-CD V8.3 Alpha only this morning in my
> > workplace (just a pastime unfortunately) and intended to try it there
> > and report tomorrow.  Of course it could even be Alpha chip type
> > -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
> > but none-the-less real even if less-than adequately documented.  The
> > exploit might be more telling.  Thanks for your ongoing reports.
>
> > > I'm not trying to scaremonger or stir up shit, in fact I stated in my
> > > original post that neither of these exploits seemed particularly earth
> > > shattering.
>
> > > Sampsa
>
> > --
> > Every year is getting shorter never seem to find the time.
> > Plans that either come to naught or half a page of scribbled lines
> > Hanging on in quiet desperation is the English way
> > The time is gone, the song is over,
> > Thought I'd something more to say.
> > [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>
> $ sh sys
> VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
> 19:22:37
> <truncate..>
>
> $ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> %DCL-W-TKNOVF, command element is too long - shorte

Also tried with elevated and from a com file:

Username: system
Password:
 Welcome to OpenVMS (TM) VAX Operating System, Version V7.3-2
    Last interactive login on Wednesday, 13-AUG-2008 16:31

$ type test.com;1
$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
$ exit
$ @test.com
%DCL-W-MAXPARM, too many parameters - reenter command with fewer
parameters
 \AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
$
WOPR::SYSTEM 19:11:07   (DCL)   CPU=00:00:00.89 PF=1373 IO=312 MEM=260



~~~

Anything else to try? Batch mode? (perhaps I'm not reading it
correctly??!??!?!)

Joe Ferraro

0
jferraro (20)
8/13/2008 11:12:06 PM
On Wed, 13 Aug 2008 16:02:36 -0700, jferraro <jferraro@gmail.com> wrote:

> $ sh sys
> VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
> 19:22:37

I guess I haven't been paying attention, I thought the last version for  
the VAX
was 7.3

-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/14/2008 12:30:46 AM
In article <995d1554-09f0-489d-904b-150a9ed48f83@t54g2000hsg.googlegroups.com>, jferraro <jferraro@gmail.com> writes:
>On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>> samp...@gmail.com wrote:
>> >>>Default 8.3 install on an Alpha according to the presentation notes.
>> >>>To reproduce this, apparently one is to enter exactly 511 characters
>> >>>of input, then press the up arrow three times and wait - a core dump
>> >>>follows.
>>
>> >>I know you didn't make the claim but you should first test it out before
>> >>brandishing bullshit here.
>>
>> >>I've tried to reproduce the claimed results from your posted instruction
>> >>and it does NOT produce a "core dump".
>>
>> > Hey don't shoot the messenger, people were interested in what was in
>> > the presentation, I just relayed that information WITH THE CAVEAT THAT
>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
>> > an exploit, based on that I assumed it's genuine even if we haven't
>> > been able to reproduce it.
>>
>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
>> on which to try.  It too failed to fail in any way.  Curiously, I just
>> happened to build an off-the-CD V8.3 Alpha only this morning in my
>> workplace (just a pastime unfortunately) and intended to try it there
>> and report tomorrow.  Of course it could even be Alpha chip type
>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
>> but none-the-less real even if less-than adequately documented.  The
>> exploit might be more telling.  Thanks for your ongoing reports.
>>
>> > I'm not trying to scaremonger or stir up shit, in fact I stated in my
>> > original post that neither of these exploits seemed particularly earth
>> > shattering.
>>
>> > Sampsa
>>
>> --
>> Every year is getting shorter never seem to find the time.
>> Plans that either come to naught or half a page of scribbled lines
>> Hanging on in quiet desperation is the English way
>> The time is gone, the song is over,
>> Thought I'd something more to say.
>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>
>$ sh sys
>VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
>19:22:37
><truncate..>
>
>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>%DCL-W-TKNOVF, command element is too long - shorten

That's not a "core dump" or any exploitable issue.  That's merely an error
message stating you have exceeded the acceptable command length.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/14/2008 1:22:32 AM
I tried on Alpha VMS 8.3 on the system account no less. From a DECterm
window.

511 characters, no spaces. Up arrow 3 times, nothing special happened.
0
8/14/2008 1:40:59 AM
VAXman- @SendSpamHere.ORG wrote:
> In article <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, sampsal@gmail.com writes:
>>> I would have thought a CLI overflow to have been tried by at least a few
>>> at DEFCON9 because the system automagically created service-rich user
>>> accounts with of course DCL which the hackers were then free to abuse.
>>>
>>> We were not scrutinizing buffers however and any such overflow may in
>>> our case have done nothing harmful (by luck or design). I think it was
>>> version 7.1-? if it makes a difference. Did the gentleman specify any
>>> versions?
>> Default 8.3 install on an Alpha according to the presentation notes.
>> To reproduce this, apparently one is to enter exactly 511 characters
>> of input, then press the up arrow three times and wait - a core dump
>> follows.
> 
> I know you didn't make the claim but you should first test it out before
> brandishing bullshit here.
> 
> I've tried to reproduce the claimed results from your posted instruction
> and it does NOT produce a "core dump". 
> 

This isn't entirely bullshit. I reported it, case number AH800710.

I saw the original post regarding the "execution of priviledged code"
and was tempted to reply, but I didn't bother. However, I am now :-)

The issue never allowed execution of priv. code (certainly not as
far as I could see). The issue was simply a miss calculation in the
RECALL ring buffer that resulted in an access violation. This seemed
to coincide with the extension of the DCL command line buffer. Yes,
the process does crash. Yes, it was a pain. However, it happened so
infrequently and never actually did anything serious that I didn't
report it for the first few months.

The version of VMS is also incorrect. I reported the problem under
OpenVMS Alpha V7.3-2 in June, 2004.

Tim.
0
tesneddon (80)
8/14/2008 1:42:04 AM
In article <00A7E113.29A29520@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
>In article <995d1554-09f0-489d-904b-150a9ed48f83@t54g2000hsg.googlegroups.com>, jferraro <jferraro@gmail.com> writes:
>>On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>>> samp...@gmail.com wrote:
>>> >>>Default 8.3 install on an Alpha according to the presentation notes.
>>> >>>To reproduce this, apparently one is to enter exactly 511 characters
>>> >>>of input, then press the up arrow three times and wait - a core dump
>>> >>>follows.
>>>
>>> >>I know you didn't make the claim but you should first test it out before
>>> >>brandishing bullshit here.
>>>
>>> >>I've tried to reproduce the claimed results from your posted instruction
>>> >>and it does NOT produce a "core dump".
>>>
>>> > Hey don't shoot the messenger, people were interested in what was in
>>> > the presentation, I just relayed that information WITH THE CAVEAT THAT
>>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
>>> > an exploit, based on that I assumed it's genuine even if we haven't
>>> > been able to reproduce it.
>>>
>>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
>>> on which to try.  It too failed to fail in any way.  Curiously, I just
>>> happened to build an off-the-CD V8.3 Alpha only this morning in my
>>> workplace (just a pastime unfortunately) and intended to try it there
>>> and report tomorrow.  Of course it could even be Alpha chip type
>>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
>>> but none-the-less real even if less-than adequately documented.  The
>>> exploit might be more telling.  Thanks for your ongoing reports.
>>>
>>> > I'm not trying to scaremonger or stir up shit, in fact I stated in my
>>> > original post that neither of these exploits seemed particularly earth
>>> > shattering.
>>>
>>> > Sampsa
>>>
>>> --
>>> Every year is getting shorter never seem to find the time.
>>> Plans that either come to naught or half a page of scribbled lines
>>> Hanging on in quiet desperation is the English way
>>> The time is gone, the song is over,
>>> Thought I'd something more to say.
>>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>>
>>$ sh sys
>>VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
>>19:22:37
>><truncate..>
>>
>>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>>%DCL-W-TKNOVF, command element is too long - shorten
>
>That's not a "core dump" or any exploitable issue.  That's merely an error
>message stating you have exceeded the acceptable command length.
>
Plus you seem to be trying this out on a VAX 7.3x system when the reported 
problem is with Alpha VMS 8.3

"
Default 8.3 install on an Alpha according to the presentation notes.
To reproduce this, apparently one is to enter exactly 511 characters
of input, then press the up arrow three times and wait - a core dump
follows.
"
I believe the other problem which was reported which was with Finger
was supposed to occur with VAX systems.

David Webb
Security team leader
CCSS
Middlesex University 



>-- 
>VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
>.... pejorative statements of opinion are entitled to constitutional protection
>no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
>Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
>of usenet _must_ include its contents in its entirety including this copyright
>notice, disclaimer and quotations.
0
david20
8/14/2008 7:37:54 AM
On Aug 13, 9:22 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro <jferr...@gmail.com> writes:
>
>
>
> >On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
> >> samp...@gmail.com wrote:
> >> >>>Default 8.3 install on an Alpha according to the presentation notes.
> >> >>>To reproduce this, apparently one is to enter exactly 511 characters
> >> >>>of input, then press the up arrow three times and wait - a core dump
> >> >>>follows.
>
> >> >>I know you didn't make the claim but you should first test it out before
> >> >>brandishing bullshit here.
>
> >> >>I've tried to reproduce the claimed results from your posted instruction
> >> >>and it does NOT produce a "core dump".
>
> >> > Hey don't shoot the messenger, people were interested in what was in
> >> > the presentation, I just relayed that information WITH THE CAVEAT THAT
> >> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
> >> > an exploit, based on that I assumed it's genuine even if we haven't
> >> > been able to reproduce it.
>
> >> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
> >> on which to try.  It too failed to fail in any way.  Curiously, I just
> >> happened to build an off-the-CD V8.3 Alpha only this morning in my
> >> workplace (just a pastime unfortunately) and intended to try it there
> >> and report tomorrow.  Of course it could even be Alpha chip type
> >> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
> >> but none-the-less real even if less-than adequately documented.  The
> >> exploit might be more telling.  Thanks for your ongoing reports.
>
> >> > I'm not trying to scaremonger or stir up shit, in fact I stated in my
> >> > original post that neither of these exploits seemed particularly earth
> >> > shattering.
>
> >> > Sampsa
>
> >> --
> >> Every year is getting shorter never seem to find the time.
> >> Plans that either come to naught or half a page of scribbled lines
> >> Hanging on in quiet desperation is the English way
> >> The time is gone, the song is over,
> >> Thought I'd something more to say.
> >> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>
> >$ sh sys
> >VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
> >19:22:37
> ><truncate..>
>
> >$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> >%DCL-W-TKNOVF, command element is too long - shorten
>
> That's not a "core dump" or any exploitable issue.  That's merely an error
> message stating you have exceeded the acceptable command length.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional protection
> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
> of usenet _must_ include its contents in its entirety including this copyright
> notice, disclaimer and quotations.

Sorry... that was the point... its *not* a core-dump or
exploitation... only posting to remove any doubts from those who may
impose the theory on "older" openVMS instances...
0
jferraro (20)
8/14/2008 11:17:42 AM
In article <M3Mok.28077$IK1.7234@news-server.bigpond.net.au>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, sampsal@gmail.com writes:
>>>> I would have thought a CLI overflow to have been tried by at least a few
>>>> at DEFCON9 because the system automagically created service-rich user
>>>> accounts with of course DCL which the hackers were then free to abuse.
>>>>
>>>> We were not scrutinizing buffers however and any such overflow may in
>>>> our case have done nothing harmful (by luck or design). I think it was
>>>> version 7.1-? if it makes a difference. Did the gentleman specify any
>>>> versions?
>>> Default 8.3 install on an Alpha according to the presentation notes.
>>> To reproduce this, apparently one is to enter exactly 511 characters
>>> of input, then press the up arrow three times and wait - a core dump
>>> follows.
>> 
>> I know you didn't make the claim but you should first test it out before
>> brandishing bullshit here.
>> 
>> I've tried to reproduce the claimed results from your posted instruction
>> and it does NOT produce a "core dump". 
>> 
>
>This isn't entirely bullshit. I reported it, case number AH800710.
>
>I saw the original post regarding the "execution of priviledged code"
>and was tempted to reply, but I didn't bother. However, I am now :-)
>
>The issue never allowed execution of priv. code (certainly not as
>far as I could see). The issue was simply a miss calculation in the
>RECALL ring buffer that resulted in an access violation. This seemed
>to coincide with the extension of the DCL command line buffer. Yes,
>the process does crash. Yes, it was a pain. However, it happened so
>infrequently and never actually did anything serious that I didn't
>report it for the first few months.
>
>The version of VMS is also incorrect. I reported the problem under
>OpenVMS Alpha V7.3-2 in June, 2004.

I tried this "reproducer" on V7.3-2 too.  Even if it does happen, I do not
believe you could do much in terms of executing privileged code, especial-
ly with DCL at supervisor mode.
 

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/14/2008 11:50:13 AM
Tim E. Sneddon wrote:
> VAXman- @SendSpamHere.ORG wrote:
> 
>> In article 
>> <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, 
>> sampsal@gmail.com writes:
>>
>>>> I would have thought a CLI overflow to have been tried by at least a 
>>>> few
>>>> at DEFCON9 because the system automagically created service-rich user
>>>> accounts with of course DCL which the hackers were then free to abuse.
>>>>
>>>> We were not scrutinizing buffers however and any such overflow may in
>>>> our case have done nothing harmful (by luck or design). I think it was
>>>> version 7.1-? if it makes a difference. Did the gentleman specify any
>>>> versions?
>>>
>>> Default 8.3 install on an Alpha according to the presentation notes.
>>> To reproduce this, apparently one is to enter exactly 511 characters
>>> of input, then press the up arrow three times and wait - a core dump
>>> follows.
>>
>>
>> I know you didn't make the claim but you should first test it out before
>> brandishing bullshit here.
>>
>> I've tried to reproduce the claimed results from your posted instruction
>> and it does NOT produce a "core dump".
> 
> 
> This isn't entirely bullshit. I reported it, case number AH800710.
> 
> I saw the original post regarding the "execution of priviledged code"
> and was tempted to reply, but I didn't bother. However, I am now :-)
> 
> The issue never allowed execution of priv. code (certainly not as
> far as I could see). The issue was simply a miss calculation in the
> RECALL ring buffer that resulted in an access violation. This seemed
> to coincide with the extension of the DCL command line buffer. Yes,
> the process does crash. Yes, it was a pain. However, it happened so
> infrequently and never actually did anything serious that I didn't
> report it for the first few months.
> 
> The version of VMS is also incorrect. I reported the problem under
> OpenVMS Alpha V7.3-2 in June, 2004.

Little point in me reporting that I couldn't produce anything resembling 
the (albeit sketchy) description of the 'exploit' on my off-the-CD V8.3 
installation.  This is a quoted-copy (to help circumvent wrapping) of 
that test:

> $ product show hist
> ------------------------------------ ----------- ----------- --- -----------
> PRODUCT                              KIT TYPE    OPERATION   VAL DATE
> ------------------------------------ ----------- ----------- --- -----------
> CPQ AXPVMS CDSA V2.2-271             Full LP     Install     (C) 13-AUG-2008
> DEC AXPVMS DECNET_OSI V8.3           Full LP     Install     (C) 13-AUG-2008
> DEC AXPVMS DWMOTIF V1.6              Full LP     Install     (C) 13-AUG-2008
> DEC AXPVMS DWMOTIF_SUPPORT V8.3      Full LP     Install     (U) 13-AUG-2008
> DEC AXPVMS OPENVMS V8.3              Platform    Install     (U) 13-AUG-2008
> DEC AXPVMS TCPIP V5.6-9              Full LP     Install     (C) 13-AUG-2008
> DEC AXPVMS VMS V8.3                  Oper System Install     (U) 13-AUG-2008
> HP AXPVMS AVAIL_MAN_BASE V8.3        Full LP     Install     (U) 13-AUG-2008
> HP AXPVMS KERBEROS V3.0-103          Full LP     Install     (C) 13-AUG-2008
> HP AXPVMS SSL V1.3-281               Full LP     Install     (C) 13-AUG-2008
> HP AXPVMS TDC_RT V2.2-107            Full LP     Install     (C) 13-AUG-2008
> ------------------------------------ ----------- ----------- --- -----------
> 11 items found
> 
> $ show cpu/full
> 
> System: WASD, AlphaServer DS20 500 MHz
> 
>   SMP execlet   = 3 : Disabled : Uniprocessing.
>   Config tree   = None
>   Primary CPU   = 0
>   HWRPB CPUs    = 2
>   Page Size     = 8192
>   Revision Code =
>   Serial Number = S391400466
>   Default CPU Capabilities:
>         System: QUORUM RUN
>   Default Process Capabilities:
>         System: QUORUM RUN
> 
> CPU 0    State: RUN                CPUDB: 81C18000     Handle: * None *
>        Process: FTA7:SYSTEM          PID: 0000045C
>   Capabilities:
>         System: PRIMARY QUORUM RUN RAD0
>   Slot Context: 84970180
>      CPU     -  State..........: RC, PA, PP, CV, PV, PMV, PL
>                 Type...........: EV6 (21264), Pass 2.3
>                 Speed..........: 500 Mhz
>                 Variation......: VAX FP, IEEE FP, Primary Eligible
>                 Serial Number..:
>                 Revision.......:
>                 Halt Request...: 0
>                 Software Comp..: 0.0
>      PALCODE -  Revision Code..: 1.98-01
>                 Compatibility..: 79
>                 Max Shared CPUs: 2
>                 Memory  Space..: Physical = 00000000.00000000  Length = 0
>                 Scratch Space..: Physical = 00000000.00000000  Length = 0
>   Bindings:     * None *
>   Fastpath:
>         PKC0
>         BG0
>   Features:
>      Autostart - Enabled.
>      Fastpath  - Selection enabled as Preferred CPU.
> 
> $ typ test.com
> $ write sys$output 79 * 6 + 37
> $ write sys$output f$fao("!79*A")
> $ write sys$output f$fao("!79*B")
> $ write sys$output f$fao("!79*C")
> $ write sys$output f$fao("!79*D")
> $ write sys$output f$fao("!79*E")
> $ write sys$output f$fao("!79*F")
> $ write sys$output f$fao("!37*G")
> $ @test.com
> 511
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
> EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG

I then cut and paste the 511 characters (line-by-line) into the CLI and 
used the cursor keys to no result.

> Tim.

--
"And I am not frightened of dying, any time will do, I
don't mind. Why should I be frightened of dying?
There's no reason for it, you've gotta go sometime."
"If you can hear this whispering you are dying."
"I never said I was frightened of dying."
[Wright; The Dark Side of the Moon]
0
mark.daniel2 (266)
8/14/2008 11:53:18 AM
Mark Daniel wrote:
> Little point in me reporting that I couldn't produce anything resembling 
> the (albeit sketchy) description of the 'exploit' on my off-the-CD V8.3 
> installation.  This is a quoted-copy (to help circumvent wrapping) of 
> that test:
> 

     [...snip...]

> I then cut and paste the 511 characters (line-by-line) into the CLI and 
> used the cursor keys to no result.
> 

I did some looking around through old emails and came across the
reproducer (below). I believe it is what the regression test uses.
Apologies as this will probably wrap.

I might also add that this bug was fixed in VMS732_DCL-V0200.

$ CREATE RECALL_TEST_02.TXT
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
directory/date=create/output=NL:/PROTEC/SINC
$ RECALL/ERASE
$ RECALL/INPUT=RECALL_TEST_02.TXT
$ REACLL/ALL

If this test doesn't crash your process you will at least get some
very "odd" results from the RECALL list.

Tim.
0
tesneddon (80)
8/14/2008 1:23:15 PM
On Aug 14, 3:37 am, davi...@alpha2.mdx.ac.uk wrote:
> In article <00A7E113.29A29...@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
> >In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro <jferr...@gmail.com> writes:
> >>On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
> >>> samp...@gmail.com wrote:
> >>> >>>Default 8.3 install on an Alpha according to the presentation notes.
> >>> >>>To reproduce this, apparently one is to enter exactly 511 characters
> >>> >>>of input, then press the up arrow three times and wait - a core dump
> >>> >>>follows.
>
> >>> >>I know you didn't make the claim but you should first test it out before
> >>> >>brandishing bullshit here.
>
> >>> >>I've tried to reproduce the claimed results from your posted instruction
> >>> >>and it does NOT produce a "core dump".
>
> >>> > Hey don't shoot the messenger, people were interested in what was in
> >>> > the presentation, I just relayed that information WITH THE CAVEAT THAT
> >>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
> >>> > an exploit, based on that I assumed it's genuine even if we haven't
> >>> > been able to reproduce it.
>
> >>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
> >>> on which to try.  It too failed to fail in any way.  Curiously, I just
> >>> happened to build an off-the-CD V8.3 Alpha only this morning in my
> >>> workplace (just a pastime unfortunately) and intended to try it there
> >>> and report tomorrow.  Of course it could even be Alpha chip type
> >>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
> >>> but none-the-less real even if less-than adequately documented.  The
> >>> exploit might be more telling.  Thanks for your ongoing reports.
>
> >>> > I'm not trying to scaremonger or stir up shit, in fact I stated in my
> >>> > original post that neither of these exploits seemed particularly earth
> >>> > shattering.
>
> >>> > Sampsa
>
> >>> --
> >>> Every year is getting shorter never seem to find the time.
> >>> Plans that either come to naught or half a page of scribbled lines
> >>> Hanging on in quiet desperation is the English way
> >>> The time is gone, the song is over,
> >>> Thought I'd something more to say.
> >>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>
> >>$ sh sys
> >>VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
> >>19:22:37
> >><truncate..>
>
> >>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> >>%DCL-W-TKNOVF, command element is too long - shorten
>
> >That's not a "core dump" or any exploitable issue.  That's merely an error
> >message stating you have exceeded the acceptable command length.
>
> Plus you seem to be trying this out on a VAX 7.3x system when the reported
> problem is with Alpha VMS 8.3
>
> "
> Default 8.3 install on an Alpha according to the presentation notes.
> To reproduce this, apparently one is to enter exactly 511 characters
> of input, then press the up arrow three times and wait - a core dump
> follows.
> "
> I believe the other problem which was reported which was with Finger
> was supposed to occur with VAX systems.
>
> David Webb
> Security team leader
> CCSS
> Middlesex University
>
> >--
> >VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
> >.... pejorative statements of opinion are entitled to constitutional protection
> >no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
> >Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
> >of usenet _must_ include its contents in its entirety including this copyright
> >notice, disclaimer and quotations.

David,

A "core dump"? I hate to be a bit of a pedant, but do you mean "end of
users process and logout" or "system crash".

Frankly, a "bug" that causes a user to terminate his own process
(which can be done in any number of intended ways) is not a true
security vulnerability.  A security vulnerability needs to affect
other users or the system as a whole.

"Suicide" is far different from "murder".

- Bob Gezelter, http://www.rlgsc.com
0
gezelter (551)
8/14/2008 1:43:03 PM
In article <d64369e8-572c-47ba-ab61-0769b3def54e@a70g2000hsh.googlegroups.com>, Bob Gezelter <gezelter@rlgsc.com> writes:
>On Aug 14, 3:37 am, davi...@alpha2.mdx.ac.uk wrote:
>> In article <00A7E113.29A29...@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
>> >In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro <jferr...@gmail.com> writes:
>> >>On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>> >>> samp...@gmail.com wrote:
>> >>> >>>Default 8.3 install on an Alpha according to the presentation notes.
>> >>> >>>To reproduce this, apparently one is to enter exactly 511 characters
>> >>> >>>of input, then press the up arrow three times and wait - a core dump
>> >>> >>>follows.
>>
>> >>> >>I know you didn't make the claim but you should first test it out before
>> >>> >>brandishing bullshit here.
>>
>> >>> >>I've tried to reproduce the claimed results from your posted instruction
>> >>> >>and it does NOT produce a "core dump".
>>
>> >>> > Hey don't shoot the messenger, people were interested in what was in
>> >>> > the presentation, I just relayed that information WITH THE CAVEAT THAT
>> >>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
>> >>> > an exploit, based on that I assumed it's genuine even if we haven't
>> >>> > been able to reproduce it.
>>
>> >>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
>> >>> on which to try.  It too failed to fail in any way.  Curiously, I just
>> >>> happened to build an off-the-CD V8.3 Alpha only this morning in my
>> >>> workplace (just a pastime unfortunately) and intended to try it there
>> >>> and report tomorrow.  Of course it could even be Alpha chip type
>> >>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
>> >>> but none-the-less real even if less-than adequately documented.  The
>> >>> exploit might be more telling.  Thanks for your ongoing reports.
>>
>> >>> > I'm not trying to scaremonger or stir up shit, in fact I stated in my
>> >>> > original post that neither of these exploits seemed particularly earth
>> >>> > shattering.
>>
>> >>> > Sampsa   
>>
>> >>> --
>> >>> Every year is getting shorter never seem to find the time.
>> >>> Plans that either come to naught or half a page of scribbled lines
>> >>> Hanging on in quiet desperation is the English way
>> >>> The time is gone, the song is over,
>> >>> Thought I'd something more to say.
>> >>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>>
>> >>$ sh sys
>> >>VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
>> >>19:22:37
>> >><truncate..>
>>
>> >>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> >>%DCL-W-TKNOVF, command element is too long - shorten
>>
>> >That's not a "core dump" or any exploitable issue.  That's merely an error
>> >message stating you have exceeded the acceptable command length.
>>
>> Plus you seem to be trying this out on a VAX 7.3x system when the reported
>> problem is with Alpha VMS 8.3
>>
>> "
>> Default 8.3 install on an Alpha according to the presentation notes.
>> To reproduce this, apparently one is to enter exactly 511 characters
>> of input, then press the up arrow three times and wait - a core dump
>> follows.
>> "
>> I believe the other problem which was reported which was with Finger
>> was supposed to occur with VAX systems.
>>
>> David Webb
>> Security team leader
>> CCSS
>> Middlesex University
>>
>> >--
>> >VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>>
>> >.... pejorative statements of opinion are entitled to constitutional protection
>> >no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>>
>> >Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
>> >of usenet _must_ include its contents in its entirety including this copyright
>> >notice, disclaimer and quotations.
>
>David,
>
>A "core dump"? I hate to be a bit of a pedant, but do you mean "end of
>users process and logout" or "system crash".
>
>Frankly, a "bug" that causes a user to terminate his own process
>(which can be done in any number of intended ways) is not a true
>security vulnerability.  A security vulnerability needs to affect
>other users or the system as a whole.
>
>"Suicide" is far different from "murder".
>
Bob,

your asking the wrong person. I and a number of others are just responding to 
Sampsa's report of VMS vulnerabilities in the Defcon 16 slides. 
The initial report from Sampsa said about this bug

"
2. A CLI buffer overflow on Alphas. Basically any input over
511 characters causes an overflow, it seems to be possible to
have a privileged process execute arbitrary code.
"

David Webb
Security team leader
CCSS
Middlesex University



>- Bob Gezelter, http://www.rlgsc.com
0
david20
8/14/2008 2:18:01 PM
On Aug 14, 10:18 am, davi...@alpha2.mdx.ac.uk wrote:
> In article <d64369e8-572c-47ba-ab61-0769b3def...@a70g2000hsh.googlegroups.com>, Bob Gezelter <gezel...@rlgsc.com> writes:
>
> >On Aug 14, 3:37 am, davi...@alpha2.mdx.ac.uk wrote:
> >> In article <00A7E113.29A29...@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
> >> >In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro <jferr...@gmail.com> writes:
> >> >>On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
> >> >>> samp...@gmail.com wrote:
> >> >>> >>>Default 8.3 install on an Alpha according to the presentation notes.
> >> >>> >>>To reproduce this, apparently one is to enter exactly 511 characters
> >> >>> >>>of input, then press the up arrow three times and wait - a core dump
> >> >>> >>>follows.
>
> >> >>> >>I know you didn't make the claim but you should first test it out before
> >> >>> >>brandishing bullshit here.
>
> >> >>> >>I've tried to reproduce the claimed results from your posted instruction
> >> >>> >>and it does NOT produce a "core dump".
>
> >> >>> > Hey don't shoot the messenger, people were interested in what was in
> >> >>> > the presentation, I just relayed that information WITH THE CAVEAT THAT
> >> >>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for
> >> >>> > an exploit, based on that I assumed it's genuine even if we haven't
> >> >>> > been able to reproduce it.
>
> >> >>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
> >> >>> on which to try.  It too failed to fail in any way.  Curiously, I just
> >> >>> happened to build an off-the-CD V8.3 Alpha only this morning in my
> >> >>> workplace (just a pastime unfortunately) and intended to try it there
> >> >>> and report tomorrow.  Of course it could even be Alpha chip type
> >> >>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
> >> >>> but none-the-less real even if less-than adequately documented.  The
> >> >>> exploit might be more telling.  Thanks for your ongoing reports.
>
> >> >>> > I'm not trying to scaremonger or stir up shit, in fact I stated in my
> >> >>> > original post that neither of these exploits seemed particularly earth
> >> >>> > shattering.
>
> >> >>> > Sampsa
>
> >> >>> --
> >> >>> Every year is getting shorter never seem to find the time.
> >> >>> Plans that either come to naught or half a page of scribbled lines
> >> >>> Hanging on in quiet desperation is the English way
> >> >>> The time is gone, the song is over,
> >> >>> Thought I'd something more to say.
> >> >>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>
> >> >>$ sh sys
> >> >>VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
> >> >>19:22:37
> >> >><truncate..>
>
> >> >>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
> >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> >> >>%DCL-W-TKNOVF, command element is too long - shorten
>
> >> >That's not a "core dump" or any exploitable issue.  That's merely an error
> >> >message stating you have exceeded the acceptable command length.
>
> >> Plus you seem to be trying this out on a VAX 7.3x system when the reported
> >> problem is with Alpha VMS 8.3
>
> >> "
> >> Default 8.3 install on an Alpha according to the presentation notes.
> >> To reproduce this, apparently one is to enter exactly 511 characters
> >> of input, then press the up arrow three times and wait - a core dump
> >> follows.
> >> "
> >> I believe the other problem which was reported which was with Finger
> >> was supposed to occur with VAX systems.
>
> >> David Webb
> >> Security team leader
> >> CCSS
> >> Middlesex University
>
> >> >--
> >> >VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
> >> >.... pejorative statements of opinion are entitled to constitutional protection
> >> >no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
> >> >Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
> >> >of usenet _must_ include its contents in its entirety including this copyright
> >> >notice, disclaimer and quotations.
>
> >David,
>
> >A "core dump"? I hate to be a bit of a pedant, but do you mean "end of
> >users process and logout" or "system crash".
>
> >Frankly, a "bug" that causes a user to terminate his own process
> >(which can be done in any number of intended ways) is not a true
> >security vulnerability.  A security vulnerability needs to affect
> >other users or the system as a whole.
>
> >"Suicide" is far different from "murder".
>
> Bob,
>
> your asking the wrong person. I and a number of others are just responding to
> Sampsa's report of VMS vulnerabilities in the Defcon 16 slides.
> The initial report from Sampsa said about this bug
>
> "
> 2. A CLI buffer overflow on Alphas. Basically any input over
> 511 characters causes an overflow, it seems to be possible to
> have a privileged process execute arbitrary code.
> "
>
> David Webb
> Security team leader
> CCSS
> Middlesex University
>
> >- Bob Gezelter,http://www.rlgsc.com

David,

My apologies, I apparently clicked on the incorrect entry. I meant the
question for Tim Sneddon.

- Bob Gezelter, http://www.rlgsc.com
0
gezelter (551)
8/14/2008 2:48:38 PM
Bob Gezelter wrote:
> David,
> 
> My apologies, I apparently clicked on the incorrect entry. I meant the
> question for Tim Sneddon.
> 

You'll have to check the quoting again :-) I never said it was
a "core dump". I also said that the problem *didn't* allow the
execution of arbitrary code at priviledge. I just said it was a
pain. I tend to use my up arrow quite a bit. It is annoying
when the process disappears randomly. It's certainly not a
security hole and I never claimed as such. David Webb got it
right when he said people were responding to Sampsa's report.
 From what I have read Sampsa was merely passing along the work
of others at the request of readers of this newsgroup.

As I said, I wasn't even going to reply to it. The alleged
vulnerability was clearly mis-reported crap. However, when everyone
jumped on it and it turned into a big thing I decided to clear
it up. I even went and dug out the details of the regression
test and the case number, so we could finally put this thing
to rest :-)

Tim.
0
tesneddon (80)
8/14/2008 3:05:53 PM
In article <lRXok.28316$IK1.8799@news-server.bigpond.net.au>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>Bob Gezelter wrote:
>> David,
>> 
>> My apologies, I apparently clicked on the incorrect entry. I meant the
>> question for Tim Sneddon.
>> 
>
>You'll have to check the quoting again :-) I never said it was
>a "core dump". I also said that the problem *didn't* allow the
>execution of arbitrary code at priviledge. I just said it was a
>pain. I tend to use my up arrow quite a bit. It is annoying
>when the process disappears randomly. It's certainly not a
>security hole and I never claimed as such. David Webb got it
>right when he said people were responding to Sampsa's report.
> From what I have read Sampsa was merely passing along the work
>of others at the request of readers of this newsgroup.
>
>As I said, I wasn't even going to reply to it. The alleged
>vulnerability was clearly mis-reported crap. However, when everyone
>jumped on it and it turned into a big thing I decided to clear
>it up. I even went and dug out the details of the regression
>test and the case number, so we could finally put this thing
>to rest :-)

Thanks for the test.  I'll try it later.  However, I would like to see
these "hacker" slides from the DEFcon.  Are they available for general
consumption anywhere on the net?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/14/2008 3:16:44 PM
VAXman- @SendSpamHere.ORG wrote:
> Thanks for the test.  I'll try it later.  However, I would like to see
> these "hacker" slides from the DEFcon.  Are they available for general
> consumption anywhere on the net?
> 

Beats me. Sampsa seems to be the source for those.

Tim.
0
tesneddon (80)
8/14/2008 3:21:18 PM
In article <O3Yok.28319$IK1.10888@news-server.bigpond.net.au>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> Thanks for the test.  I'll try it later.  However, I would like to see
>> these "hacker" slides from the DEFcon.  Are they available for general
>> consumption anywhere on the net?
>> 
>
>Beats me. Sampsa seems to be the source for those.
>
>Tim.

Hopefully they will be at some point but for the moment we are 
reliant for information on Sampsa who said in a previous post

"
I got them from a friend who's colleague was at DEFCON - I don't know
what the distribution/copyright issues are with the document so I daren't
host them on my webpage.
"


David Webb
Security team leader
CCSS
Middlesex University

0
david20
8/14/2008 3:36:47 PM
On Aug 14, 11:05 am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
> Bob Gezelter wrote:
> > David,
>
> > My apologies, I apparently clicked on the incorrect entry. I meant the
> > question for Tim Sneddon.
>
> You'll have to check the quoting again :-) I never said it was
> a "core dump". I also said that the problem *didn't* allow the
> execution of arbitrary code at priviledge. I just said it was a
> pain. I tend to use my up arrow quite a bit. It is annoying
> when the process disappears randomly. It's certainly not a
> security hole and I never claimed as such. David Webb got it
> right when he said people were responding to Sampsa's report.
>  From what I have read Sampsa was merely passing along the work
> of others at the request of readers of this newsgroup.
>
> As I said, I wasn't even going to reply to it. The alleged
> vulnerability was clearly mis-reported crap. However, when everyone
> jumped on it and it turned into a big thing I decided to clear
> it up. I even went and dug out the details of the regression
> test and the case number, so we could finally put this thing
> to rest :-)
>
> Tim.

Tim,

Thank you for the first hand data.

As the late Richard Feynman reported in "Surely You Joking Mr.
Feynman", reports citing reports citing reports are unreliable (which
is the underlying for the hearsay rules in legal procedures).

If we can confirm that the details, perhaps someone should publish the
facts (I will do so, if someone can get me the original DEFCON
presentation so that I can see what it is).

- Bob Gezelter, http://www.rlgsc.com
0
gezelter (551)
8/14/2008 4:19:20 PM
Tim E. Sneddon wrote:
> Mark Daniel wrote:
>> Little point in me reporting that I couldn't produce anything 
>> resembling the (albeit sketchy) description of the 'exploit' on my 
>> off-the-CD V8.3 installation.  This is a quoted-copy (to help 
>> circumvent wrapping) of that test:
>>
> 
>     [...snip...]
> 
>> I then cut and paste the 511 characters (line-by-line) into the CLI 
>> and used the cursor keys to no result.
>>
> 
> I did some looking around through old emails and came across the
> reproducer (below). I believe it is what the regression test uses.
> Apologies as this will probably wrap.
> 
> I might also add that this bug was fixed in VMS732_DCL-V0200.
> 
> $ CREATE RECALL_TEST_02.TXT
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9
> directory/date=create/output=NL:/PROTEC/SINCE 
> DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;%
> directory/date=create/output=NL:/PROTEC/SINC
> $ RECALL/ERASE
> $ RECALL/INPUT=RECALL_TEST_02.TXT
> $ REACLL/ALL
> 
> If this test doesn't crash your process you will at least get some
> very "odd" results from the RECALL list.
> 
> Tim.

Well, that last line is likely the produce an unwanted result!
0
rgilbert88 (4439)
8/14/2008 6:43:24 PM
Bob Gezelter wrote:
> On Aug 14, 3:37 am, davi...@alpha2.mdx.ac.uk wrote:
>> In article <00A7E113.29A29...@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
>>> In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro <jferr...@gmail.com> writes:
>>>> On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>>>>> samp...@gmail.com wrote:
>>>>>>>> Default 8.3 install on an Alpha according to the presentation notes.
>>>>>>>> To reproduce this, apparently one is to enter exactly 511 characters
>>>>>>>> of input, then press the up arrow three times and wait - a core dump
>>>>>>>> follows.
>>>>>>> I know you didn't make the claim but you should first test it out before
>>>>>>> brandishing bullshit here.
>>>>>>> I've tried to reproduce the claimed results from your posted instruction
>>>>>>> and it does NOT produce a "core dump".
>>>>>> Hey don't shoot the messenger, people were interested in what was in
>>>>>> the presentation, I just relayed that information WITH THE CAVEAT THAT
>>>>>> I DIDN'T TEST IT. They had screenshots of the flaw and source code for
>>>>>> an exploit, based on that I assumed it's genuine even if we haven't
>>>>>> been able to reproduce it.
>>>>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha
>>>>> on which to try.  It too failed to fail in any way.  Curiously, I just
>>>>> happened to build an off-the-CD V8.3 Alpha only this morning in my
>>>>> workplace (just a pastime unfortunately) and intended to try it there
>>>>> and report tomorrow.  Of course it could even be Alpha chip type
>>>>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure
>>>>> but none-the-less real even if less-than adequately documented.  The
>>>>> exploit might be more telling.  Thanks for your ongoing reports.
>>>>>> I'm not trying to scaremonger or stir up shit, in fact I stated in my
>>>>>> original post that neither of these exploits seemed particularly earth
>>>>>> shattering.
>>>>>> Sampsa
>>>>> --
>>>>> Every year is getting shorter never seem to find the time.
>>>>> Plans that either come to naught or half a page of scribbled lines
>>>>> Hanging on in quiet desperation is the English way
>>>>> The time is gone, the song is over,
>>>>> Thought I'd something more to say.
>>>>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
>>>> $ sh sys
>>>> VMS/VAX V7.3-2  on node WOPR  13-AUG-2008 19:00:07.39  Uptime  372
>>>> 19:22:37
>>>> <truncate..>
>>>> $ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
>>>> _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>>>> %DCL-W-TKNOVF, command element is too long - shorten
>>> That's not a "core dump" or any exploitable issue.  That's merely an error
>>> message stating you have exceeded the acceptable command length.
>> Plus you seem to be trying this out on a VAX 7.3x system when the reported
>> problem is with Alpha VMS 8.3
>>
>> "
>> Default 8.3 install on an Alpha according to the presentation notes.
>> To reproduce this, apparently one is to enter exactly 511 characters
>> of input, then press the up arrow three times and wait - a core dump
>> follows.
>> "
>> I believe the other problem which was reported which was with Finger
>> was supposed to occur with VAX systems.
>>
>> David Webb
>> Security team leader
>> CCSS
>> Middlesex University
>>
>>> --
>>> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>>> .... pejorative statements of opinion are entitled to constitutional protection
>>> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>>> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
>>> of usenet _must_ include its contents in its entirety including this copyright
>>> notice, disclaimer and quotations.
> 
> David,
> 
> A "core dump"? I hate to be a bit of a pedant, but do you mean "end of
> users process and logout" or "system crash".
> 
> Frankly, a "bug" that causes a user to terminate his own process
> (which can be done in any number of intended ways) is not a true
> security vulnerability.  A security vulnerability needs to affect
> other users or the system as a whole.
> 
> "Suicide" is far different from "murder".
> 
> - Bob Gezelter, http://www.rlgsc.com

In either case the results are similar; a dead body!!
0
rgilbert88 (4439)
8/14/2008 6:45:19 PM
On Aug 14, 2:42=A0am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
> VAXman- @SendSpamHere.ORG wrote:
> > In article <9781c047-761a-4923-9aab-8c1a32ff7...@x35g2000hsb.googlegrou=
ps.com>, samp...@gmail.com writes:
> >>> I would have thought a CLI overflow to have been tried by at least a =
few
> >>> at DEFCON9 because the system automagically created service-rich user
> >>> accounts with of course DCL which the hackers were then free to abuse=
..
>
> >>> We were not scrutinizing buffers however and any such overflow may in
> >>> our case have done nothing harmful (by luck or design). I think it wa=
s
> >>> version 7.1-? if it makes a difference. Did the gentleman specify any
> >>> versions?
> >> Default 8.3 install on an Alpha according to the presentation notes.
> >> To reproduce this, apparently one is to enter exactly 511 characters
> >> of input, then press the up arrow three times and wait - a core dump
> >> follows.
>
> > I know you didn't make the claim but you should first test it out befor=
e
> > brandishing bullshit here.
>
> > I've tried to reproduce the claimed results from your posted instructio=
n
> > and it does NOT produce a "core dump".
>
> This isn't entirely bullshit. I reported it, case number AH800710.
>
> I saw the original post regarding the "execution of priviledged code"
> and was tempted to reply, but I didn't bother. However, I am now :-)
>
> The issue never allowed execution of priv. code (certainly not as
> far as I could see). The issue was simply a miss calculation in the
> RECALL ring buffer that resulted in an access violation. This seemed
> to coincide with the extension of the DCL command line buffer. Yes,
> the process does crash. Yes, it was a pain. However, it happened so
> infrequently and never actually did anything serious that I didn't
> report it for the first few months.
>
> The version of VMS is also incorrect. I reported the problem under
> OpenVMS Alpha V7.3-2 in June, 2004.
>
> Tim.


I googled the case number but didn't find anything except this thread,
so I'm not 100% sure what it refers to. But not entirely bullshit and
never exploitable? Well if you are talking about our bugs then you may
want to watch these videos:

http://www.signedness.org/misc/openvms_local_install_exploit.avi
http://www.signedness.org/misc/openvms_local_tcpip_exploit.avi
http://www.signedness.org/misc/openvms_local_telnet_exploit.avi

Can't be bothered to upload the finger video atm, and its easy enough
to reproduce. Just fingering a users whose .plan file contains %n%n%n%n
%n%n%n or something similar should do it. and while I'm on the topic
of the finger exploit, there seem to be some confusion about it. We
exploited it on VAX but Alpha is vulnerable too (and I'm guessing
Itanium too but not verified). The command line bug may or may not be
exploitable on VAX (too jet lagged to go into that atm)

PS. There are many many many more things to be explored / exploited
for those interested in OpenVMS security.. But there is only so much
you can fit into 50mins..

Cheers,
signedness.org



0
bugs6 (57)
8/14/2008 11:52:21 PM
In article <488fbb7a-2459-4753-904a-7ecd5193bdc4@2g2000hsn.googlegroups.com>, bugs@signedness.org writes:
>On Aug 14, 2:42=A0am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
>> VAXman- @SendSpamHere.ORG wrote:
>> > In article <9781c047-761a-4923-9aab-8c1a32ff7...@x35g2000hsb.googlegrou=
>ps.com>, samp...@gmail.com writes:
>> >>> I would have thought a CLI overflow to have been tried by at least a =
>few
>> >>> at DEFCON9 because the system automagically created service-rich user
>> >>> accounts with of course DCL which the hackers were then free to abuse=
>..
>>
>> >>> We were not scrutinizing buffers however and any such overflow may in
>> >>> our case have done nothing harmful (by luck or design). I think it wa=
>s
>> >>> version 7.1-? if it makes a difference. Did the gentleman specify any
>> >>> versions?
>> >> Default 8.3 install on an Alpha according to the presentation notes.
>> >> To reproduce this, apparently one is to enter exactly 511 characters
>> >> of input, then press the up arrow three times and wait - a core dump
>> >> follows.
>>
>> > I know you didn't make the claim but you should first test it out befor=
>e
>> > brandishing bullshit here.
>>
>> > I've tried to reproduce the claimed results from your posted instructio=
>n
>> > and it does NOT produce a "core dump".
>>
>> This isn't entirely bullshit. I reported it, case number AH800710.
>>
>> I saw the original post regarding the "execution of priviledged code"
>> and was tempted to reply, but I didn't bother. However, I am now :-)
>>
>> The issue never allowed execution of priv. code (certainly not as
>> far as I could see). The issue was simply a miss calculation in the
>> RECALL ring buffer that resulted in an access violation. This seemed
>> to coincide with the extension of the DCL command line buffer. Yes,
>> the process does crash. Yes, it was a pain. However, it happened so
>> infrequently and never actually did anything serious that I didn't
>> report it for the first few months.
>>
>> The version of VMS is also incorrect. I reported the problem under
>> OpenVMS Alpha V7.3-2 in June, 2004.
>>
>> Tim.
>
>
>I googled the case number but didn't find anything except this thread,
>so I'm not 100% sure what it refers to. But not entirely bullshit and
>never exploitable? Well if you are talking about our bugs then you may
>want to watch these videos:
>
>http://www.signedness.org/misc/openvms_local_install_exploit.avi
>http://www.signedness.org/misc/openvms_local_tcpip_exploit.avi
>http://www.signedness.org/misc/openvms_local_telnet_exploit.avi

Videos of several minutes of black and silence.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 12:26:35 AM
bugs@signedness.org wrote:
> On Aug 14, 2:42 am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
>> VAXman- @SendSpamHere.ORG wrote:
>>> In article <9781c047-761a-4923-9aab-8c1a32ff7...@x35g2000hsb.googlegroups.com>, samp...@gmail.com writes:
>>>>> I would have thought a CLI overflow to have been tried by at least a few
>>>>> at DEFCON9 because the system automagically created service-rich user
>>>>> accounts with of course DCL which the hackers were then free to abuse.
>>>>> We were not scrutinizing buffers however and any such overflow may in
>>>>> our case have done nothing harmful (by luck or design). I think it was
>>>>> version 7.1-? if it makes a difference. Did the gentleman specify any
>>>>> versions?
>>>> Default 8.3 install on an Alpha according to the presentation notes.
>>>> To reproduce this, apparently one is to enter exactly 511 characters
>>>> of input, then press the up arrow three times and wait - a core dump
>>>> follows.
>>> I know you didn't make the claim but you should first test it out before
>>> brandishing bullshit here.
>>> I've tried to reproduce the claimed results from your posted instruction
>>> and it does NOT produce a "core dump".
>> This isn't entirely bullshit. I reported it, case number AH800710.
>>
>> I saw the original post regarding the "execution of priviledged code"
>> and was tempted to reply, but I didn't bother. However, I am now :-)
>>
>> The issue never allowed execution of priv. code (certainly not as
>> far as I could see). The issue was simply a miss calculation in the
>> RECALL ring buffer that resulted in an access violation. This seemed
>> to coincide with the extension of the DCL command line buffer. Yes,
>> the process does crash. Yes, it was a pain. However, it happened so
>> infrequently and never actually did anything serious that I didn't
>> report it for the first few months.
>>
>> The version of VMS is also incorrect. I reported the problem under
>> OpenVMS Alpha V7.3-2 in June, 2004.
>>
>> Tim.
> 
> 
> I googled the case number but didn't find anything except this thread,
> so I'm not 100% sure what it refers to. But not entirely bullshit and
> never exploitable? Well if you are talking about our bugs then you may
> want to watch these videos:

It refers to the HP case number. I merely offered it as proof that
I logged the job and that it closed with a successful result.

Does anybody bother actually reading what I posted or are they so
busy with their heads up their arses that they seem to miss the
finer points?

I don't care about the finger exploit. I don't care about the videos.
There was a claim that this bug in the RECALL code would allow one
to run arbitrary priv. code. I know first hand that it doesn't. Why?
Because I'm the guy who found it. It lets you crash your process,
when you're at DCL! Holy shit, stop the press! It's an exploit!
I don't think so. As Bob Gezelter pointed out. There are plenty of
other ways to kill your process from DCL. It is *not* a security
vulnerability. It certainly was an annoying bug though.

Tim.
0
tesneddon (80)
8/15/2008 1:12:44 AM
On Aug 15, 3:12 am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
> b...@signedness.org wrote:
> > On Aug 14, 2:42 am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
> >> VAXman- @SendSpamHere.ORG wrote:
> >>> In article <9781c047-761a-4923-9aab-8c1a32ff7...@x35g2000hsb.googlegroups.com>, samp...@gmail.com writes:
> >>>>> I would have thought a CLI overflow to have been tried by at least a few
> >>>>> at DEFCON9 because the system automagically created service-rich user
> >>>>> accounts with of course DCL which the hackers were then free to abuse.
> >>>>> We were not scrutinizing buffers however and any such overflow may in
> >>>>> our case have done nothing harmful (by luck or design). I think it was
> >>>>> version 7.1-? if it makes a difference. Did the gentleman specify any
> >>>>> versions?
> >>>> Default 8.3 install on an Alpha according to the presentation notes.
> >>>> To reproduce this, apparently one is to enter exactly 511 characters
> >>>> of input, then press the up arrow three times and wait - a core dump
> >>>> follows.
> >>> I know you didn't make the claim but you should first test it out before
> >>> brandishing bullshit here.
> >>> I've tried to reproduce the claimed results from your posted instruction
> >>> and it does NOT produce a "core dump".
> >> This isn't entirely bullshit. I reported it, case number AH800710.
>
> >> I saw the original post regarding the "execution of priviledged code"
> >> and was tempted to reply, but I didn't bother. However, I am now :-)
>
> >> The issue never allowed execution of priv. code (certainly not as
> >> far as I could see). The issue was simply a miss calculation in the
> >> RECALL ring buffer that resulted in an access violation. This seemed
> >> to coincide with the extension of the DCL command line buffer. Yes,
> >> the process does crash. Yes, it was a pain. However, it happened so
> >> infrequently and never actually did anything serious that I didn't
> >> report it for the first few months.
>
> >> The version of VMS is also incorrect. I reported the problem under
> >> OpenVMS Alpha V7.3-2 in June, 2004.
>
> >> Tim.
>
> > I googled the case number but didn't find anything except this thread,
> > so I'm not 100% sure what it refers to. But not entirely bullshit and
> > never exploitable? Well if you are talking about our bugs then you may
> > want to watch these videos:
>
> It refers to the HP case number. I merely offered it as proof that
> I logged the job and that it closed with a successful result.
>
> Does anybody bother actually reading what I posted or are they so
> busy with their heads up their arses that they seem to miss the
> finer points?
>
> I don't care about the finger exploit. I don't care about the videos.
> There was a claim that this bug in the RECALL code would allow one
> to run arbitrary priv. code. I know first hand that it doesn't. Why?
> Because I'm the guy who found it. It lets you crash your process,
> when you're at DCL! Holy shit, stop the press! It's an exploit!
> I don't think so. As Bob Gezelter pointed out. There are plenty of
> other ways to kill your process from DCL. It is *not* a security
> vulnerability. It certainly was an annoying bug though.
>
> Tim.

LOL
The bug is not in DCL, and if you care to watch the videos you will
see that an arbitrary program can be run with higher privileges.
As an example we wrote FILE.EXE (since we can not get any output to
the terminal from 'show proc/priv' when exploiting) which simply
writes the privileges of the current process to PRIVS.TXT.
We first execute FILE.EXE from the shell to show that the user has the
default privileges.
FILE.EXE is then executed with higher privileges from the program that
we are exploiting (install, tcpip and telnet, but there are others as
well).

Oh, and you need the vmware codecs installed to watch the videos.

Cheers,
signedness.org
0
bugs6 (57)
8/15/2008 1:26:56 AM
bugs@signedness.org wrote:
> On Aug 15, 3:12 am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
>> b...@signedness.org wrote:
>>> On Aug 14, 2:42 am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
>>>> VAXman- @SendSpamHere.ORG wrote:
>>>>> In article <9781c047-761a-4923-9aab-8c1a32ff7...@x35g2000hsb.googlegroups.com>, samp...@gmail.com writes:
>>>>>>> I would have thought a CLI overflow to have been tried by at least a few
>>>>>>> at DEFCON9 because the system automagically created service-rich user
>>>>>>> accounts with of course DCL which the hackers were then free to abuse.
>>>>>>> We were not scrutinizing buffers however and any such overflow may in
>>>>>>> our case have done nothing harmful (by luck or design). I think it was
>>>>>>> version 7.1-? if it makes a difference. Did the gentleman specify any
>>>>>>> versions?
>>>>>> Default 8.3 install on an Alpha according to the presentation notes.
>>>>>> To reproduce this, apparently one is to enter exactly 511 characters
>>>>>> of input, then press the up arrow three times and wait - a core dump
>>>>>> follows.
>>>>> I know you didn't make the claim but you should first test it out before
>>>>> brandishing bullshit here.
>>>>> I've tried to reproduce the claimed results from your posted instruction
>>>>> and it does NOT produce a "core dump".
>>>> This isn't entirely bullshit. I reported it, case number AH800710.
>>>> I saw the original post regarding the "execution of priviledged code"
>>>> and was tempted to reply, but I didn't bother. However, I am now :-)
>>>> The issue never allowed execution of priv. code (certainly not as
>>>> far as I could see). The issue was simply a miss calculation in the
>>>> RECALL ring buffer that resulted in an access violation. This seemed
>>>> to coincide with the extension of the DCL command line buffer. Yes,
>>>> the process does crash. Yes, it was a pain. However, it happened so
>>>> infrequently and never actually did anything serious that I didn't
>>>> report it for the first few months.
>>>> The version of VMS is also incorrect. I reported the problem under
>>>> OpenVMS Alpha V7.3-2 in June, 2004.
>>>> Tim.
>>> I googled the case number but didn't find anything except this thread,
>>> so I'm not 100% sure what it refers to. But not entirely bullshit and
>>> never exploitable? Well if you are talking about our bugs then you may
>>> want to watch these videos:
>> It refers to the HP case number. I merely offered it as proof that
>> I logged the job and that it closed with a successful result.
>>
>> Does anybody bother actually reading what I posted or are they so
>> busy with their heads up their arses that they seem to miss the
>> finer points?
>>
>> I don't care about the finger exploit. I don't care about the videos.
>> There was a claim that this bug in the RECALL code would allow one
>> to run arbitrary priv. code. I know first hand that it doesn't. Why?
>> Because I'm the guy who found it. It lets you crash your process,
>> when you're at DCL! Holy shit, stop the press! It's an exploit!
>> I don't think so. As Bob Gezelter pointed out. There are plenty of
>> other ways to kill your process from DCL. It is *not* a security
>> vulnerability. It certainly was an annoying bug though.
>>
>> Tim.
> 
> LOL
> The bug is not in DCL, and if you care to watch the videos you will
> see that an arbitrary program can be run with higher privileges.
> As an example we wrote FILE.EXE (since we can not get any output to
> the terminal from 'show proc/priv' when exploiting) which simply
> writes the privileges of the current process to PRIVS.TXT.
> We first execute FILE.EXE from the shell to show that the user has the
> default privileges.
> FILE.EXE is then executed with higher privileges from the program that
> we are exploiting (install, tcpip and telnet, but there are others as
> well).
> 
> Oh, and you need the vmware codecs installed to watch the videos.
> 

I've got them and watched the local telnet exploit (I'll check out the
others later). I'm interested, I'd like to know more. So where is the
code used to generate those results and how come you don't use SHOW
PROCESS and INSTALL to show privs?

Tim.
0
tesneddon (80)
8/15/2008 1:47:01 AM
Forgive me, but all this "enter exactly 511 characters and press the up 
arrow three times" business reminds me of the old Dick Van Dyke episode 
schtick that started with a telephone call and ended with "..then swing 
the bag over your head and scream like a chicken"

Vaxman -please e-mail me your shipment receiving address.. I am a couple 
years remiss in sending you something.

Patrick J
0
eccm (54)
8/15/2008 2:03:15 AM
On Aug 15, 3:03=A0am, patrick jankowiak <e...@swbell.net> wrote:
> Forgive me, but all this "enter exactly 511 characters and press the up
> arrow three times" business reminds me of the old Dick Van Dyke episode
> schtick that started with a telephone call and ended with "..then swing
> the bag over your head and scream like a chicken"
>
> Vaxman -please e-mail me your shipment receiving address.. I am a couple
> years remiss in sending you something.
>
> Patrick J

We are not going to release the exploits for some time.. Seven "%n"
should be more than enough to hit something you cant write to and
crash the finger client (provided that HP has not patched it, we have
not heard from them in weeks even though we asked for updates)

System service numbers seems to move around between releases (like
windows system calls), since all our payloads assumes 8.3 (alpha) and
7.3 (vax) it would probably just mean that we get another bunch of
replies saying "it only crashes the binary and won't get "SYSTEM"".
Another thing is that at least the VAX shellcode was written purely
for demo purposes and got my username hardcoded into it (uses a system
service to enable all privs on my account)

If anybody is in or around London I'd be happy to settle whether or
not we are bullshitting with a live demo at a dc4420 meeting or
similar event..

The alpha exploits uses the sys$creprc system service to execute the
file FILE.EXE that happens to show the privs of the process. The
reason we took that route instead of spawning a new "shell" with
higher privs is that it was easier to test/debug.

btw for those of you who doubt us, check this out
http://www.securityfocus.com/archive/1/495207 either we set a new
trend making it fashionable to bullshit about OpenVMS bugs or maybe it
is possible that VMS is pretty exploitable.. ;)



0
bugs6 (57)
8/15/2008 2:35:31 AM
Mark Daniel wrote:
> Tim E. Sneddon wrote:
>> VAXman- @SendSpamHere.ORG wrote:
>>
>>> In article 
>>> <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, 
>>> sampsal@gmail.com writes:
>>>
>>>>> I would have thought a CLI overflow to have been tried by at least 
>>>>> a few
>>>>> at DEFCON9 because the system automagically created service-rich user
>>>>> accounts with of course DCL which the hackers were then free to abuse.
>>>>>
>>>>> We were not scrutinizing buffers however and any such overflow may in
>>>>> our case have done nothing harmful (by luck or design). I think it was
>>>>> version 7.1-? if it makes a difference. Did the gentleman specify any
>>>>> versions?
>>>>
>>>> Default 8.3 install on an Alpha according to the presentation notes.
>>>> To reproduce this, apparently one is to enter exactly 511 characters
>>>> of input, then press the up arrow three times and wait - a core dump
>>>> follows.
>>>
>>>
>>> I know you didn't make the claim but you should first test it out before
>>> brandishing bullshit here.
>>>
>>> I've tried to reproduce the claimed results from your posted instruction
>>> and it does NOT produce a "core dump".
>>
>>
>> This isn't entirely bullshit. I reported it, case number AH800710.
>>
>> I saw the original post regarding the "execution of priviledged code"
>> and was tempted to reply, but I didn't bother. However, I am now :-)
>>
>> The issue never allowed execution of priv. code (certainly not as
>> far as I could see). The issue was simply a miss calculation in the
>> RECALL ring buffer that resulted in an access violation. This seemed
>> to coincide with the extension of the DCL command line buffer. Yes,
>> the process does crash. Yes, it was a pain. However, it happened so
>> infrequently and never actually did anything serious that I didn't
>> report it for the first few months.
>>
>> The version of VMS is also incorrect. I reported the problem under
>> OpenVMS Alpha V7.3-2 in June, 2004.
> 
> Little point in me reporting that I couldn't produce anything resembling 
> the (albeit sketchy) description of the 'exploit' on my off-the-CD V8.3 
> installation.  This is a quoted-copy (to help circumvent wrapping) of 
> that test:
> 
>> $ product show hist
>> ------------------------------------ ----------- ----------- --- 
>> -----------
>> PRODUCT                              KIT TYPE    OPERATION   VAL DATE
>> ------------------------------------ ----------- ----------- --- 
>> -----------
>> CPQ AXPVMS CDSA V2.2-271             Full LP     Install     (C) 
>> 13-AUG-2008
>> DEC AXPVMS DECNET_OSI V8.3           Full LP     Install     (C) 
>> 13-AUG-2008
>> DEC AXPVMS DWMOTIF V1.6              Full LP     Install     (C) 
>> 13-AUG-2008
>> DEC AXPVMS DWMOTIF_SUPPORT V8.3      Full LP     Install     (U) 
>> 13-AUG-2008
>> DEC AXPVMS OPENVMS V8.3              Platform    Install     (U) 
>> 13-AUG-2008
>> DEC AXPVMS TCPIP V5.6-9              Full LP     Install     (C) 
>> 13-AUG-2008
>> DEC AXPVMS VMS V8.3                  Oper System Install     (U) 
>> 13-AUG-2008
>> HP AXPVMS AVAIL_MAN_BASE V8.3        Full LP     Install     (U) 
>> 13-AUG-2008
>> HP AXPVMS KERBEROS V3.0-103          Full LP     Install     (C) 
>> 13-AUG-2008
>> HP AXPVMS SSL V1.3-281               Full LP     Install     (C) 
>> 13-AUG-2008
>> HP AXPVMS TDC_RT V2.2-107            Full LP     Install     (C) 
>> 13-AUG-2008
>> ------------------------------------ ----------- ----------- --- 
>> -----------
>> 11 items found
>>
>> $ show cpu/full
>>
>> System: WASD, AlphaServer DS20 500 MHz
>>
>>   SMP execlet   = 3 : Disabled : Uniprocessing.
>>   Config tree   = None
>>   Primary CPU   = 0
>>   HWRPB CPUs    = 2
>>   Page Size     = 8192
>>   Revision Code =
>>   Serial Number = S391400466
>>   Default CPU Capabilities:
>>         System: QUORUM RUN
>>   Default Process Capabilities:
>>         System: QUORUM RUN
>>
>> CPU 0    State: RUN                CPUDB: 81C18000     Handle: * None *
>>        Process: FTA7:SYSTEM          PID: 0000045C
>>   Capabilities:
>>         System: PRIMARY QUORUM RUN RAD0
>>   Slot Context: 84970180
>>      CPU     -  State..........: RC, PA, PP, CV, PV, PMV, PL
>>                 Type...........: EV6 (21264), Pass 2.3
>>                 Speed..........: 500 Mhz
>>                 Variation......: VAX FP, IEEE FP, Primary Eligible
>>                 Serial Number..:
>>                 Revision.......:
>>                 Halt Request...: 0
>>                 Software Comp..: 0.0
>>      PALCODE -  Revision Code..: 1.98-01
>>                 Compatibility..: 79
>>                 Max Shared CPUs: 2
>>                 Memory  Space..: Physical = 00000000.00000000  Length = 0
>>                 Scratch Space..: Physical = 00000000.00000000  Length = 0
>>   Bindings:     * None *
>>   Fastpath:
>>         PKC0
>>         BG0
>>   Features:
>>      Autostart - Enabled.
>>      Fastpath  - Selection enabled as Preferred CPU.
>>
>> $ typ test.com
>> $ write sys$output 79 * 6 + 37
>> $ write sys$output f$fao("!79*A")
>> $ write sys$output f$fao("!79*B")
>> $ write sys$output f$fao("!79*C")
>> $ write sys$output f$fao("!79*D")
>> $ write sys$output f$fao("!79*E")
>> $ write sys$output f$fao("!79*F")
>> $ write sys$output f$fao("!37*G")
>> $ @test.com
>> 511
>> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
>>
>> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 
>>
>> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 
>>
>> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 
>>
>> EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE 
>>
>> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
>>
>> GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
> 
> I then cut and paste the 511 characters (line-by-line) into the CLI and 
> used the cursor keys to no result.
> 
>> Tim.
> 
> -- 
> "And I am not frightened of dying, any time will do, I
> don't mind. Why should I be frightened of dying?
> There's no reason for it, you've gotta go sometime."
> "If you can hear this whispering you are dying."
> "I never said I was frightened of dying."
> [Wright; The Dark Side of the Moon]

I'm running that version on the Alpha out in the lab. I used a 
privileged acct. and I am using a 132 column terminal width. (never mind 
the system time, I just did this now.)

$ show sys
OpenVMS V7.3-2  on node WIZ  16-DEC-2005 11:52:17.01  Uptime  29 02:28:59

$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG

up three times, and down three times, nothing.. but this shows now:
$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$


Nothing more.. so finally I ran the up arrow till all the commands were 
gone, and held it a bit, then down arrow till the same, holding it a bit 
as well, and did this a few times and got this:



$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$ 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$ 
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
%RMS-F-RER, file read error
-SYSTEM-W-DATAOVERUN, data overrun
$


It did not trash my (telnet) session, and after pressing the up arrow 
lots of times (which did nothing but replace the line above with the 
previous line as shown by the $ signs interspersed) I started pressing 
the down arrow (reversing the process), then it apparently got pissed 
off as shown.

I do not have the resources to know what really happened or where, if 
anywhere besides the bit bucket, the overrun went. I assume into the 
bottomless pit where all naughty VMS user keystrokes go..

But all I have likely done is confirm the previously reported Miss 
Calculation of June 2004.

Patrick
0
eccm (54)
8/15/2008 2:37:57 AM
bugs@signedness.org wrote:
> On Aug 15, 3:03 am, patrick jankowiak <e...@swbell.net> wrote:
>> Forgive me, but all this "enter exactly 511 characters and press the up
>> arrow three times" business reminds me of the old Dick Van Dyke episode
>> schtick that started with a telephone call and ended with "..then swing
>> the bag over your head and scream like a chicken"
>>
>> Vaxman -please e-mail me your shipment receiving address.. I am a couple
>> years remiss in sending you something.
>>
>> Patrick J
> 
> We are not going to release the exploits for some time.. Seven "%n"
> should be more than enough to hit something you cant write to and
> crash the finger client (provided that HP has not patched it, we have
> not heard from them in weeks even though we asked for updates)
> 
> System service numbers seems to move around between releases (like
> windows system calls), since all our payloads assumes 8.3 (alpha) and
> 7.3 (vax) it would probably just mean that we get another bunch of
> replies saying "it only crashes the binary and won't get "SYSTEM"".
> Another thing is that at least the VAX shellcode was written purely
> for demo purposes and got my username hardcoded into it (uses a system
> service to enable all privs on my account)
> 
> If anybody is in or around London I'd be happy to settle whether or
> not we are bullshitting with a live demo at a dc4420 meeting or
> similar event..
> 
> The alpha exploits uses the sys$creprc system service to execute the
> file FILE.EXE that happens to show the privs of the process. The
> reason we took that route instead of spawning a new "shell" with
> higher privs is that it was easier to test/debug.
> 
> btw for those of you who doubt us, check this out
> http://www.securityfocus.com/archive/1/495207 either we set a new
> trend making it fashionable to bullshit about OpenVMS bugs or maybe it
> is possible that VMS is pretty exploitable.. ;)
> 
> 
> 
  I meant no disrespect but I do like a bit of humor, especially when a 
seemingly intricate or repetitive method is involved.

Patrick
0
eccm (54)
8/15/2008 3:20:00 AM
bugs@signedness.org wrote:
> [...snip...]
> Can't be bothered to upload the finger video atm, and its easy enough
> to reproduce. Just fingering a users whose .plan file contains %n%n%n%n
> %n%n%n or something similar should do it. and while I'm on the topic
> of the finger exploit, there seem to be some confusion about it. We
> exploited it on VAX but Alpha is vulnerable too (and I'm guessing
> Itanium too but not verified). The command line bug may or may not be
> exploitable on VAX (too jet lagged to go into that atm)

Hmmm... looks like there's something in this.

Wizard� show sys/noproc
OpenVMS V8.3  on node WIZARD  15-AUG-2008 09:05:07.62
Wizard� type .plan
%n
Wizard� finger roy
Login name: ROY            In real life: Roy Omond
Account: SYSTEM            Directory: $U:[ROY]
Last login: Wed 13-AUG-2008 10:43:45
No unread mail
Access violation, reason mask=04,
virtual address=0000000000000000, PC=FFFFFFFF80BA3BA4, PS=0000001B

   Improperly handled condition, image exit forced.
     Signal arguments:   Number = 0000000000000005
                         Name   = 000000000000000C
                                  0000000000000004
                                  0000000000000000
                                  FFFFFFFF80BA3BA4
                                  000000000000001B

     Register dump:
     R0  = 0000000000000000  R1  = 0000000000000049
     R2  = 000000007BEEDCD0
     R3  = 000000007AE48940  R4  = 0000000000000000
     R5  = 0000000000000000
     R6  = 000000007AE48928  R7  = FFFFFFFFFFFFFFFF
     R8  = 000000007BF628E8
     R9  = 0000000000050011  R10 = 00000000000202D0
     R11 = 0000000000000000
     R12 = 0000000000116C88  R13 = 0000000000000000
     R14 = 0000000000000052
     R15 = 0000000000116BC8  R16 = 0000000000050011
     R17 = 000000007AE48DB0
     R18 = 000000007AE48DB0  R19 = 000000007AE48930
     R20 = 0000000000000008
     R21 = 0000000000000000  R22 = 0000000000000000
     R23 = 0000000000000000
     R24 = 0000000000000000  R25 = FFFFFFFFFFFFEC96
     R26 = 0000000000000001
     R27 = FFFFFFFF80BA36D0  R28 = FFFFFFFF80BA3B30
     R29 = 000000007AE48880
     SP  = 000000007AE48880  PC  = FFFFFFFF80BA3BA4
     PS  = 000000000000001B

Same behaviour for any number of "%n" strings.
0
Roy.Omond (380)
8/15/2008 8:08:53 AM
Verified (finally got my VMS box up):

$ show sys/noproc
OpenVMS V8.3  on node CHIMPY  15-AUG-2008 09:27:20.73  Uptime  0
23:14:17
$ type .plan
%n
$ show sys/noproc
OpenVMS V8.3  on node CHIMPY  15-AUG-2008 09:27:25.34  Uptime  0
23:14:21
$ finger sampsa
Login name: SAMPSA         In real life: SAMPSA LAINE
Account: SAMPSA            Directory: SYS$SYSDEVICE:
[SAMPSA]
Last login: Fri 15-AUG-2008 09:26:39
No unread mail
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=0000000000000000, PC=FFFFFFFF80BA3BA4, PS=0000001B

  Improperly handled condition, image exit forced.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000004
                                 0000000000000000
                                 FFFFFFFF80BA3BA4
                                 000000000000001B

    Register dump:
    R0  = 0000000000000000  R1  = 0000000000000049  R2  =
000000007BEEDCD0
    R3  = 000000007AE26940  R4  = 0000000000000000  R5  =
0000000000000000
    R6  = 000000007AE26928  R7  = FFFFFFFFFFFFFFFF  R8  =
000000007BF628E8
    R9  = 0000000000050011  R10 = 00000000000202D0  R11 =
0000000000000000
    R12 = 0000000000116C88  R13 = 0000000000000000  R14 =
0000000000000053
    R15 = 0000000000116BC8  R16 = 0000000000050011  R17 =
000000007AE26DB0
    R18 = 000000007AE26DB0  R19 = 000000007AE26930  R20 =
0000000000000008
    R21 = 0000000000000000  R22 = 0000000000000000  R23 =
0000000000000000
    R24 = 0000000000000000  R25 = FFFFFFFFFFFFEC96  R26 =
0000000000000001
    R27 = FFFFFFFF80BA36D0  R28 = FFFFFFFF80BA3B30  R29 =
000000007AE26880
    SP  = 000000007AE26880  PC  = FFFFFFFF80BA3BA4  PS  =
000000000000001B

0
sampsal (134)
8/15/2008 8:27:35 AM
In article <6e77d46c-8fd3-4b11-be3b-64f53ae4598b@y38g2000hsy.googlegroups.com>, bugs@signedness.org writes:
>{...snip...}
>LOL
>The bug is not in DCL, and if you care to watch the videos you will
>see that an arbitrary program can be run with higher privileges.
>As an example we wrote FILE.EXE (since we can not get any output to
__________________________________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the terminal from 'show proc/priv' when exploiting) which simply
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WHy not?


>writes the privileges of the current process to PRIVS.TXT.
>We first execute FILE.EXE from the shell to show that the user has the
>default privileges.
>FILE.EXE is then executed with higher privileges from the program that
>we are exploiting (install, tcpip and telnet, but there are others as
>well).
>
>Oh, and you need the vmware codecs installed to watch the videos.

Why not .MPG which doesn't require the download of some questionable
software from some site on the internet?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 11:11:21 AM
In article <du5pk.17842$cW3.1737@nlpi064.nbdc.sbc.com>, patrick jankowiak <eccm@swbell.net> writes:
>
>Forgive me, but all this "enter exactly 511 characters and press the up 
>arrow three times" business reminds me of the old Dick Van Dyke episode 
>schtick that started with a telephone call and ended with "..then swing 
>the bag over your head and scream like a chicken"

ROFL!


>Vaxman -please e-mail me your shipment receiving address.. I am a couple 
>years remiss in sending you something.

A rack of DTC03s?

Address forthcoming in separate email.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 11:18:50 AM
On Aug 15, 4:37 am, patrick jankowiak <e...@swbell.net> wrote:
> Mark Daniel wrote:
> > Tim E. Sneddon wrote:
> >> VAXman- @SendSpamHere.ORG wrote:
>
> >>> In article
> >>> <9781c047-761a-4923-9aab-8c1a32ff7...@x35g2000hsb.googlegroups.com>,
> >>> samp...@gmail.com writes:
>
> >>>>> I would have thought a CLI overflow to have been tried by at least
> >>>>> a few
> >>>>> at DEFCON9 because the system automagically created service-rich us=
er
> >>>>> accounts with of course DCL which the hackers were then free to abu=
se.
>
> >>>>> We were not scrutinizing buffers however and any such overflow may =
in
> >>>>> our case have done nothing harmful (by luck or design). I think it =
was
> >>>>> version 7.1-? if it makes a difference. Did the gentleman specify a=
ny
> >>>>> versions?
>
> >>>> Default 8.3 install on an Alpha according to the presentation notes.
> >>>> To reproduce this, apparently one is to enter exactly 511 characters
> >>>> of input, then press the up arrow three times and wait - a core dump
> >>>> follows.
>
> >>> I know you didn't make the claim but you should first test it out bef=
ore
> >>> brandishing bullshit here.
>
> >>> I've tried to reproduce the claimed results from your posted instruct=
ion
> >>> and it does NOT produce a "core dump".
>
> >> This isn't entirely bullshit. I reported it, case number AH800710.
>
> >> I saw the original post regarding the "execution of priviledged code"
> >> and was tempted to reply, but I didn't bother. However, I am now :-)
>
> >> The issue never allowed execution of priv. code (certainly not as
> >> far as I could see). The issue was simply a miss calculation in the
> >> RECALL ring buffer that resulted in an access violation. This seemed
> >> to coincide with the extension of the DCL command line buffer. Yes,
> >> the process does crash. Yes, it was a pain. However, it happened so
> >> infrequently and never actually did anything serious that I didn't
> >> report it for the first few months.
>
> >> The version of VMS is also incorrect. I reported the problem under
> >> OpenVMS Alpha V7.3-2 in June, 2004.
>
> > Little point in me reporting that I couldn't produce anything resemblin=
g
> > the (albeit sketchy) description of the 'exploit' on my off-the-CD V8.3
> > installation.  This is a quoted-copy (to help circumvent wrapping) of
> > that test:
>
> >> $ product show hist
> >> ------------------------------------ ----------- ----------- ---
> >> -----------
> >> PRODUCT                              KIT TYPE    OPERATION   VAL DATE
> >> ------------------------------------ ----------- ----------- ---
> >> -----------
> >> CPQ AXPVMS CDSA V2.2-271             Full LP     Install     (C)
> >> 13-AUG-2008
> >> DEC AXPVMS DECNET_OSI V8.3           Full LP     Install     (C)
> >> 13-AUG-2008
> >> DEC AXPVMS DWMOTIF V1.6              Full LP     Install     (C)
> >> 13-AUG-2008
> >> DEC AXPVMS DWMOTIF_SUPPORT V8.3      Full LP     Install     (U)
> >> 13-AUG-2008
> >> DEC AXPVMS OPENVMS V8.3              Platform    Install     (U)
> >> 13-AUG-2008
> >> DEC AXPVMS TCPIP V5.6-9              Full LP     Install     (C)
> >> 13-AUG-2008
> >> DEC AXPVMS VMS V8.3                  Oper System Install     (U)
> >> 13-AUG-2008
> >> HP AXPVMS AVAIL_MAN_BASE V8.3        Full LP     Install     (U)
> >> 13-AUG-2008
> >> HP AXPVMS KERBEROS V3.0-103          Full LP     Install     (C)
> >> 13-AUG-2008
> >> HP AXPVMS SSL V1.3-281               Full LP     Install     (C)
> >> 13-AUG-2008
> >> HP AXPVMS TDC_RT V2.2-107            Full LP     Install     (C)
> >> 13-AUG-2008
> >> ------------------------------------ ----------- ----------- ---
> >> -----------
> >> 11 items found
>
> >> $ show cpu/full
>
> >> System: WASD, AlphaServer DS20 500 MHz
>
> >>   SMP execlet   =3D 3 : Disabled : Uniprocessing.
> >>   Config tree   =3D None
> >>   Primary CPU   =3D 0
> >>   HWRPB CPUs    =3D 2
> >>   Page Size     =3D 8192
> >>   Revision Code =3D
> >>   Serial Number =3D S391400466
> >>   Default CPU Capabilities:
> >>         System: QUORUM RUN
> >>   Default Process Capabilities:
> >>         System: QUORUM RUN
>
> >> CPU 0    State: RUN                CPUDB: 81C18000     Handle: * None =
*
> >>        Process: FTA7:SYSTEM          PID: 0000045C
> >>   Capabilities:
> >>         System: PRIMARY QUORUM RUN RAD0
> >>   Slot Context: 84970180
> >>      CPU     -  State..........: RC, PA, PP, CV, PV, PMV, PL
> >>                 Type...........: EV6 (21264), Pass 2.3
> >>                 Speed..........: 500 Mhz
> >>                 Variation......: VAX FP, IEEE FP, Primary Eligible
> >>                 Serial Number..:
> >>                 Revision.......:
> >>                 Halt Request...: 0
> >>                 Software Comp..: 0.0
> >>      PALCODE -  Revision Code..: 1.98-01
> >>                 Compatibility..: 79
> >>                 Max Shared CPUs: 2
> >>                 Memory  Space..: Physical =3D 00000000.00000000  Lengt=
h =3D 0
> >>                 Scratch Space..: Physical =3D 00000000.00000000  Lengt=
h =3D 0
> >>   Bindings:     * None *
> >>   Fastpath:
> >>         PKC0
> >>         BG0
> >>   Features:
> >>      Autostart - Enabled.
> >>      Fastpath  - Selection enabled as Preferred CPU.
>
> >> $ typ test.com
> >> $ write sys$output 79 * 6 + 37
> >> $ write sys$output f$fao("!79*A")
> >> $ write sys$output f$fao("!79*B")
> >> $ write sys$output f$fao("!79*C")
> >> $ write sys$output f$fao("!79*D")
> >> $ write sys$output f$fao("!79*E")
> >> $ write sys$output f$fao("!79*F")
> >> $ write sys$output f$fao("!37*G")
> >> $ @test.com
> >> 511
> >> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAAAAA
>
> >> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=
BBBBBBBBB
>
> >> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC=
CCCCCCCCC
>
> >> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD=
DDDDDDDDD
>
> >> EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE=
EEEEEEEEE
>
> >> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF=
FFFFFFFFF
>
> >> GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
>
> > I then cut and paste the 511 characters (line-by-line) into the CLI and
> > used the cursor keys to no result.
>
> >> Tim.
>
> > --
> > "And I am not frightened of dying, any time will do, I
> > don't mind. Why should I be frightened of dying?
> > There's no reason for it, you've gotta go sometime."
> > "If you can hear this whispering you are dying."
> > "I never said I was frightened of dying."
> > [Wright; The Dark Side of the Moon]
>
> I'm running that version on the Alpha out in the lab. I used a
> privileged acct. and I am using a 132 column terminal width. (never mind
> the system time, I just did this now.)
>
> $ show sys
> OpenVMS V7.3-2  on node WIZ  16-DEC-2005 11:52:17.01  Uptime  29 02:28:59
>
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC=
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF=
FFFFFFFGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
>
> up three times, and down three times, nothing.. but this shows now:
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC=
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> $
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
>
> Nothing more.. so finally I ran the up arrow till all the commands were
> gone, and held it a bit, then down arrow till the same, holding it a bit
> as well, and did this a few times and got this:
>
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC=
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> $
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> $
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEE=
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> $
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> $ ...
>
> read more =BB

You have all the information that you need to reproduce this
vulnerability on a vulnerable system.
If you watch the video you can see that the bug is triggered from the
prompt of the vulnerable program (like for example INSTALL>).
0
bugs6 (57)
8/15/2008 11:26:51 AM
On Aug 15, 1:11 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <6e77d46c-8fd3-4b11-be3b-64f53ae45...@y38g2000hsy.googlegroups.com>, b...@signedness.org writes:>{...snip...}
> >LOL
> >The bug is not in DCL, and if you care to watch the videos you will
> >see that an arbitrary program can be run with higher privileges.
> >As an example we wrote FILE.EXE (since we can not get any output to
>
> __________________________________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>the terminal from 'show proc/priv' when exploiting) which simply
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> WHy not?
>
> >writes the privileges of the current process to PRIVS.TXT.
> >We first execute FILE.EXE from the shell to show that the user has the
> >default privileges.
> >FILE.EXE is then executed with higher privileges from the program that
> >we are exploiting (install, tcpip and telnet, but there are others as
> >well).
>
> >Oh, and you need the vmware codecs installed to watch the videos.
>
> Why not .MPG which doesn't require the download of some questionable
> software from some site on the internet?
Because this is recorded from vmware, and the resulting file is
an .avi file.
You can recode it yourself if you feel that it is a problem.
Unfortunately the codec for vmware vary in quality.
If you run the movie on a Linux box with vmware installed it should
display just fine.
0
bugs6 (57)
8/15/2008 11:30:01 AM
In article <9b6cde05-affa-4ebe-a55f-1237d2de2008@a1g2000hsb.googlegroups.com>, sampsal@gmail.com writes:
>Verified (finally got my VMS box up):
>
>$ show sys/noproc
>OpenVMS V8.3  on node CHIMPY  15-AUG-2008 09:27:20.73  Uptime  0
>23:14:17
>$ type .plan
>%n
>$ show sys/noproc
>OpenVMS V8.3  on node CHIMPY  15-AUG-2008 09:27:25.34  Uptime  0
>23:14:21
>$ finger sampsa
>Login name: SAMPSA         In real life: SAMPSA LAINE
>Account: SAMPSA            Directory: SYS$SYSDEVICE:
>[SAMPSA]
>Last login: Fri 15-AUG-2008 09:26:39
>No unread mail
>%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
>address=0000000000000000, PC=FFFFFFFF80BA3BA4, PS=0000001B
>
>  Improperly handled condition, image exit forced.
>    Signal arguments:   Number = 0000000000000005
>                        Name   = 000000000000000C
>                                 0000000000000004
>                                 0000000000000000
>                                 FFFFFFFF80BA3BA4
>                                 000000000000001B
>
>    Register dump:
>    R0  = 0000000000000000  R1  = 0000000000000049  R2  =
>000000007BEEDCD0
>    R3  = 000000007AE26940  R4  = 0000000000000000  R5  =
>0000000000000000
>    R6  = 000000007AE26928  R7  = FFFFFFFFFFFFFFFF  R8  =
>000000007BF628E8
>    R9  = 0000000000050011  R10 = 00000000000202D0  R11 =
>0000000000000000
>    R12 = 0000000000116C88  R13 = 0000000000000000  R14 =
>0000000000000053
>    R15 = 0000000000116BC8  R16 = 0000000000050011  R17 =
>000000007AE26DB0
>    R18 = 000000007AE26DB0  R19 = 000000007AE26930  R20 =
>0000000000000008
>    R21 = 0000000000000000  R22 = 0000000000000000  R23 =
>0000000000000000
>    R24 = 0000000000000000  R25 = FFFFFFFFFFFFEC96  R26 =
>0000000000000001
>    R27 = FFFFFFFF80BA36D0  R28 = FFFFFFFF80BA3B30  R29 =
>000000007AE26880
>    SP  = 000000007AE26880  PC  = FFFFFFFF80BA3BA4  PS  =
>000000000000001B
>

The same happens on Alpha VMS 7.3-1 with 
Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2

and it happens with %n in a .project file as well as a .plan file.

Whilst I was at it I thought I'd check what happened with % in front of other
characters. 

so I set up a .plan file with

%a
%b
%c
%d
%e
%f
%g
%h
%i
%j
%k
%l
%m
%o
%p
%q
%r
%s
%t
%u
%w
%x
%y
%z
%0
%1
%2
%3
%4
%5
%6
%7
%8
%9
%

(note missing %n for obvious reasons)

The results were interesting

Alpha2:finger XXXXXX1
Username     Program      Login     Term/Location
XXXXXX1       TCPIP$FINGER Fri 11:39 ALPHA2::YYYYYY

Login name: XXXXXX1        In real life:
Account:                   Directory: USERZ:[XXXXXX]
Last login: Fri 15-AUG-2008 11:39:56
Unread mail: 494
Plan:
a
b

0
-6.179570e+307
0.000000
0

65536
j
k

m
626550
106D0
q
r
..project
t
2080207092
v
w
20500
y
z












Alpha2:


I'm not really familiar with finger .project and .plan files but is 
% supposed to do this sort of thing ? I thought the .plan and .project files 
were just supposed to be a pure text file which was displayed.


David Webb
Security team leader
CCSS
Middlesex University
0
david20
8/15/2008 11:31:50 AM
On Aug 15, 1:11 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <6e77d46c-8fd3-4b11-be3b-64f53ae45...@y38g2000hsy.googlegroups.com>, b...@signedness.org writes:>{...snip...}
> >LOL
> >The bug is not in DCL, and if you care to watch the videos you will
> >see that an arbitrary program can be run with higher privileges.
> >As an example we wrote FILE.EXE (since we can not get any output to
>
> __________________________________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>the terminal from 'show proc/priv' when exploiting) which simply
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> WHy not?
>
> >writes the privileges of the current process to PRIVS.TXT.
> >We first execute FILE.EXE from the shell to show that the user has the
> >default privileges.
> >FILE.EXE is then executed with higher privileges from the program that
> >we are exploiting (install, tcpip and telnet, but there are others as
> >well).
>
> >Oh, and you need the vmware codecs installed to watch the videos.
>
> Why not .MPG which doesn't require the download of some questionable
> software from some site on the internet?
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional protection
> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
> of usenet _must_ include its contents in its entirety including this copyright
> notice, disclaimer and quotations.

As we have mentioned earlier we have no output stream to write the
output of 'show proc/priv' to when executing the shellcode.
That is the reason for using the FILE.EXE program.
0
bugs6 (57)
8/15/2008 11:33:21 AM
david20@alpha1.mdx.ac.uk wrote:

> [...snip...]
> 
> The same happens on Alpha VMS 7.3-1 with 
> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
> 
> and it happens with %n in a .project file as well as a .plan file.
> 
> Whilst I was at it I thought I'd check what happened with % in front of other
> characters. 
> 
> so I set up a .plan file with
> 
> %a
>  [...snip...]

As far as I can see, this is probably very sloppy programming in
TCP/IP's Finger client.  It looks like the "%<letter>" is being
interpreted by the C RTL, which is probably expecting some other
argument(s) to format according to the "%<letter>".

Looking at the PC from the access violation:

Wizard� anal/sys

OpenVMS system analyzer

SDA> map FFFFFFFF80BA3BA4
Image Resident Section       Base     End   Image Offset
DECC$SHR_EV56              80A94000 80C909FF  0010FBA4
0
Roy.Omond (380)
8/15/2008 11:41:55 AM
In article <cf43a18f-0ea7-47fa-a015-1d6c034199c7@34g2000hsh.googlegroups.com>, bugs@signedness.org writes:
>On Aug 15, 3:03=A0am, patrick jankowiak <e...@swbell.net> wrote:
>> Forgive me, but all this "enter exactly 511 characters and press the up
>> arrow three times" business reminds me of the old Dick Van Dyke episode
>> schtick that started with a telephone call and ended with "..then swing
>> the bag over your head and scream like a chicken"
>>
>> Vaxman -please e-mail me your shipment receiving address.. I am a couple
>> years remiss in sending you something.
>>
>> Patrick J
>
>We are not going to release the exploits for some time.. Seven "%n"
>should be more than enough to hit something you cant write to and
>crash the finger client (provided that HP has not patched it, we have
>not heard from them in weeks even though we asked for updates)

I don't run finger but I enabled it to see what you are on about.
I get nothing but a stream of %n%n%n%n%n%n back.


>System service numbers seems to move around between releases (like
>windows system calls), since all our payloads assumes 8.3 (alpha) and
>7.3 (vax) it would probably just mean that we get another bunch of
>replies saying "it only crashes the binary and won't get "SYSTEM"".
>Another thing is that at least the VAX shellcode was written purely
>for demo purposes and got my username hardcoded into it (uses a system
>service to enable all privs on my account)
>
>If anybody is in or around London I'd be happy to settle whether or
>not we are bullshitting with a live demo at a dc4420 meeting or
>similar event..
>
>The alpha exploits uses the sys$creprc system service to execute the
>file FILE.EXE that happens to show the privs of the process. The
>reason we took that route instead of spawning a new "shell" with
>higher privs is that it was easier to test/debug.

Why SYS$CREPRC to get privs?  Why not SYS$GETJPI?



>btw for those of you who doubt us, check this out
>http://www.securityfocus.com/archive/1/495207 either we set a new
>trend making it fashionable to bullshit about OpenVMS bugs or maybe it

Multinet!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 11:42:16 AM
On Aug 15, 1:42 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <cf43a18f-0ea7-47fa-a015-1d6c03419...@34g2000hsh.googlegroups.com>, b...@signedness.org writes:
>
> >On Aug 15, 3:03=A0am, patrick jankowiak <e...@swbell.net> wrote:
> >> Forgive me, but all this "enter exactly 511 characters and press the up
> >> arrow three times" business reminds me of the old Dick Van Dyke episode
> >> schtick that started with a telephone call and ended with "..then swing
> >> the bag over your head and scream like a chicken"
>
> >> Vaxman -please e-mail me your shipment receiving address.. I am a couple
> >> years remiss in sending you something.
>
> >> Patrick J
>
> >We are not going to release the exploits for some time.. Seven "%n"
> >should be more than enough to hit something you cant write to and
> >crash the finger client (provided that HP has not patched it, we have
> >not heard from them in weeks even though we asked for updates)
>
> I don't run finger but I enabled it to see what you are on about.
> I get nothing but a stream of %n%n%n%n%n%n back.
>
>
>
> >System service numbers seems to move around between releases (like
> >windows system calls), since all our payloads assumes 8.3 (alpha) and
> >7.3 (vax) it would probably just mean that we get another bunch of
> >replies saying "it only crashes the binary and won't get "SYSTEM"".
> >Another thing is that at least the VAX shellcode was written purely
> >for demo purposes and got my username hardcoded into it (uses a system
> >service to enable all privs on my account)
>
> >If anybody is in or around London I'd be happy to settle whether or
> >not we are bullshitting with a live demo at a dc4420 meeting or
> >similar event..
>
> >The alpha exploits uses the sys$creprc system service to execute the
> >file FILE.EXE that happens to show the privs of the process. The
> >reason we took that route instead of spawning a new "shell" with
> >higher privs is that it was easier to test/debug.
>
> Why SYS$CREPRC to get privs?  Why not SYS$GETJPI?
>
> >btw for those of you who doubt us, check this out
> >http://www.securityfocus.com/archive/1/495207either we set a new
> >trend making it fashionable to bullshit about OpenVMS bugs or maybe it
>
> Multinet!
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional protection
> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
> of usenet _must_ include its contents in its entirety including this copyright
> notice, disclaimer and quotations.

Why SYS$CREPRC to get privs?  Why not SYS$GETJPI?

SYS$CREPRC is used in the shellcode to allow for arbitrary programs to
be
run with inherited privileges. SYS$GETJPI is used by the FILE.EXE
program to _get_
privileges and print them to a file.
That should be obvious to any OpenVMS user.
0
bugs6 (57)
8/15/2008 12:11:32 PM
In article <48a56b86$0$90265$14726298@news.sunsite.dk>, "R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> writes:
> david20@alpha1.mdx.ac.uk wrote:
> 
>> [...snip...]
>> 
>> The same happens on Alpha VMS 7.3-1 with 
>> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
>> 
>> and it happens with %n in a .project file as well as a .plan file.
>> 
>> Whilst I was at it I thought I'd check what happened with % in front of other
>> characters. 
>> 
>> so I set up a .plan file with
>> 
>> %a
>>  [...snip...]
> 
> As far as I can see, this is probably very sloppy programming in
> TCP/IP's Finger client.  It looks like the "%<letter>" is being
> interpreted by the C RTL, which is probably expecting some other
> argument(s) to format according to the "%<letter>".
> 

I suspect that anyone who's written some C code knows what TCP/IP
Engineering have almost certainly done while writing the finger
client code.

I also suspect that, like me, many programmers here with C experience
also regard this as a first year undergraduate type programming mistake
and that code review procedures should have stopped this type of mistake
from _ever_ appearing within production code for a enterprise quality
operating system.

I wonder how many other mistakes like this are just waiting to be found
within the UCX code base ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
8/15/2008 12:29:44 PM
In article <3eTvgpv1kpLI@eisner.encompasserve.org>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:
>In article <48a56b86$0$90265$14726298@news.sunsite.dk>, "R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> writes:
>> david20@alpha1.mdx.ac.uk wrote:
>> 
>>> [...snip...]
>>> 
>>> The same happens on Alpha VMS 7.3-1 with 
>>> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
>>> 
>>> and it happens with %n in a .project file as well as a .plan file.
>>> 
>>> Whilst I was at it I thought I'd check what happened with % in front of other
>>> characters. 
>>> 
>>> so I set up a .plan file with
>>> 
>>> %a
>>>  [...snip...]
>> 
>> As far as I can see, this is probably very sloppy programming in
>> TCP/IP's Finger client.  It looks like the "%<letter>" is being
>> interpreted by the C RTL, which is probably expecting some other
>> argument(s) to format according to the "%<letter>".
>> 
>
>I suspect that anyone who's written some C code knows what TCP/IP
>Engineering have almost certainly done while writing the finger
>client code.
>
>I also suspect that, like me, many programmers here with C experience
>also regard this as a first year undergraduate type programming mistake
>and that code review procedures should have stopped this type of mistake
>from _ever_ appearing within production code for a enterprise quality
>operating system.
>
>I wonder how many other mistakes like this are just waiting to be found
>within the UCX code base ?
>
Considering that UCX was rewritten at version 5.0 to be based upon the same
code as the TCPIP stack for Tru64 I wondered whether that would have the same
problem. 
A quick test on a Tru64 V5.1B box showed that it doesn't have this problem.

David Webb
Security team leader
CCSS
Middlesex University


>Simon.
>
>-- 
>Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>Microsoft: Bringing you 1980's technology to a 21st century world
0
david20
8/15/2008 12:48:02 PM
In article <e7c2204c-2d67-4ef0-adaa-8205a01dea2d@k7g2000hsd.googlegroups.com>, bugs@signedness.org writes:
>On Aug 15, 1:11 pm, VAXman-  @SendSpamHere.ORG wrote:
>> In article <6e77d46c-8fd3-4b11-be3b-64f53ae45...@y38g2000hsy.googlegroups.com>, b...@signedness.org writes:>{...snip...}
>> >LOL
>> >The bug is not in DCL, and if you care to watch the videos you will
>> >see that an arbitrary program can be run with higher privileges.
>> >As an example we wrote FILE.EXE (since we can not get any output to
>>
>> __________________________________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>the terminal from 'show proc/priv' when exploiting) which simply
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> WHy not?
>>
>> >writes the privileges of the current process to PRIVS.TXT.
>> >We first execute FILE.EXE from the shell to show that the user has the
>> >default privileges.
>> >FILE.EXE is then executed with higher privileges from the program that
>> >we are exploiting (install, tcpip and telnet, but there are others as
>> >well).
>>
>> >Oh, and you need the vmware codecs installed to watch the videos.
>>
>> Why not .MPG which doesn't require the download of some questionable
>> software from some site on the internet?
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>>
>> ... pejorative statements of opinion are entitled to constitutional protection
>> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>>
>> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
>> of usenet _must_ include its contents in its entirety including this copyright
>> notice, disclaimer and quotations.
>
>As we have mentioned earlier we have no output stream to write the
>output of 'show proc/priv' to when executing the shellcode.
>That is the reason for using the FILE.EXE program.


OK.  Perhaps I don't understand your "shell code" comment.  You report 
that you are executing DCL (shell) commands.  I have no problem getting
output from SHOW PROCESS/PRIVILEGE from a DCL 'shell'.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 12:55:12 PM
In article <50f78810-9630-4a1d-aad4-91f071bab9ad@d45g2000hsc.googlegroups.com>, bugs@signedness.org writes:
{...snip...}
>SYS$CREPRC is used in the shellcode to allow for arbitrary programs to
>be
>run with inherited privileges. SYS$GETJPI is used by the FILE.EXE
>program to _get_
>privileges and print them to a file.
>That should be obvious to any OpenVMS user.

OK.  I'm most confused.  How do you invoke SYS$CREPRC from DCL?  

Also, I just scanned all of DCL and the only SYS$CREPRC in it is in
the SPAWN command.  Are you spawning the FILE.EXE program?  You've
been incessantly terse explaining this.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 1:10:44 PM
On Aug 15, 2:10=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> OK. =A0I'm most confused. =A0How do you invoke SYS$CREPRC from DCL? =A0
>
> Also, I just scanned all of DCL and the only SYS$CREPRC in it is in
> the SPAWN command. =A0Are you spawning the FILE.EXE program? =A0You've
> been incessantly terse explaining this.

I think you might be confused (not saying you are) by the term
"shellcode".

It means the machine code payload of the exploit, typically used to
launch a shell,
not some kind of DCL script, therefore the SYS$CREPRC call is made
from
machine code, not DCL.

Sampsa

0
sampsal (134)
8/15/2008 1:29:51 PM
In article <bd97f922-ae8b-44d1-929d-25948e06158e@2g2000hsn.googlegroups.com>, sampsal@gmail.com writes:
>On Aug 15, 2:10=A0pm, VAXman-  @SendSpamHere.ORG wrote:
>> OK. =A0I'm most confused. =A0How do you invoke SYS$CREPRC from DCL? =A0
>>
>> Also, I just scanned all of DCL and the only SYS$CREPRC in it is in
>> the SPAWN command. =A0Are you spawning the FILE.EXE program? =A0You've
>> been incessantly terse explaining this.
>
>I think you might be confused (not saying you are) by the term
>"shellcode".
>
>It means the machine code payload of the exploit, typically used to
>launch a shell,
>not some kind of DCL script, therefore the SYS$CREPRC call is made
>from
>machine code, not DCL.

And where does this come into play in the 511 characters and 3 up arrows?


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 1:40:14 PM
Simon Clubley wrote:
> In article <48a56b86$0$90265$14726298@news.sunsite.dk>, "R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> writes:
>> david20@alpha1.mdx.ac.uk wrote:
>>
>>> [...snip...]
>>>
>>> The same happens on Alpha VMS 7.3-1 with 
>>> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
>>>
>>> and it happens with %n in a .project file as well as a .plan file.
>>>
>>> Whilst I was at it I thought I'd check what happened with % in front of other
>>> characters. 
>>>
>>> so I set up a .plan file with
>>>
>>> %a
>>>  [...snip...]
>> As far as I can see, this is probably very sloppy programming in
>> TCP/IP's Finger client.  It looks like the "%<letter>" is being
>> interpreted by the C RTL, which is probably expecting some other
>> argument(s) to format according to the "%<letter>".
>>
> 
> I suspect that anyone who's written some C code knows what TCP/IP
> Engineering have almost certainly done while writing the finger
> client code.
> 
> I also suspect that, like me, many programmers here with C experience
> also regard this as a first year undergraduate type programming mistake
> and that code review procedures should have stopped this type of mistake
> from _ever_ appearing within production code for a enterprise quality
> operating system.
> 
> I wonder how many other mistakes like this are just waiting to be found
> within the UCX code base ?

ISTR that UCX 5.x was based on a port of the Unix/Ultrix TCP/IP.  I also 
seem to recall that 5.x was significantly better than UCX 3.x and 4.x. 
Not perfect but a huge improvement.  Did anyone but me EVER get a DNS 
server running under UCX 3.3?  (Hint, you were dead in the water until 
ECO-13 came out!)  The relationship between the documentation and what 
the code actually did and/or expected from you was one of those 
mysteries. . . .  I needed, and got, a LOT of high powered technical 
help. . . .  Thank you Smiley Smith and Karol Zielonko.

Ten years ago, the code base was FULL of those little mistakes.  DEC 
could have saved a lot of money and pain by buying a WORKING TCP/IP 
stack from TGV or Wollongong.



0
rgilbert88 (4439)
8/15/2008 2:04:41 PM
On Aug 15, 2:40=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <bd97f922-ae8b-44d1-929d-25948e061...@2g2000hsn.googlegroups.c=
om>, samp...@gmail.com writes:
> >It means the machine code payload of the exploit, typically used to
> >launch a shell,
> >not some kind of DCL script, therefore the SYS$CREPRC call is made
> >from
> >machine code, not DCL.
>
> And where does this come into play in the 511 characters and 3 up arrows?

I think what they do (more or less) is to inject some shellcode into a
logical before running the exploit, then insert some other code after
the overflow that executes the code in the logical. Signedness guys
care to comment, I didn't see the demo, just have the notes second
hand?

Sampsa

0
sampsal (134)
8/15/2008 2:12:25 PM
On Aug 15, 3:04=A0pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:

> Ten years ago, the code base was FULL of those little mistakes. =A0DEC
> could have saved a lot of money and pain by buying a WORKING TCP/IP
> stack from TGV or Wollongong.

Interesting, especially considering they're still popping up (mind
you, in fairly obscure
tools such as the FINGER client). I wonder what the general state of
that codebase
is nowadays.

Sampsa

0
sampsal (134)
8/15/2008 2:14:18 PM
sampsal@gmail.com wrote:
> On Aug 15, 3:04 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:
> 
>> Ten years ago, the code base was FULL of those little mistakes.  DEC
>> could have saved a lot of money and pain by buying a WORKING TCP/IP
>> stack from TGV or Wollongong.
> 
> Interesting, especially considering they're still popping up (mind
> you, in fairly obscure
> tools such as the FINGER client). I wonder what the general state of
> that codebase
> is nowadays.
> 
> Sampsa
> 

If the Berkeley code ca. 1995 had it wrong, DEC just copied the bugs! 
DEC was pretty much starting from zero.  "A stern chase is a long 
chase!"  I think we've caught up with the rest of the world now but 
there certainly werer some "interesting times" back then!

0
rgilbert88 (4439)
8/15/2008 2:21:49 PM
sampsal@gmail.com wrote:

> [...snip...]
> I think what they do (more or less) is to inject some shellcode into a
> logical before running the exploit, then insert some other code after
> the overflow that executes the code in the logical. Signedness guys
> care to comment, I didn't see the demo, just have the notes second
> hand?

Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
but I actually didn't understand what that is meant to mean.

I'm a skeptic and proud of it, but I'm beginning to suspect that
this is all a hoax.
0
Roy.Omond (380)
8/15/2008 2:35:53 PM
On Aug 15, 3:35=A0pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:
> samp...@gmail.com wrote:
> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
> but I actually didn't understand what that is meant to mean.
>
> I'm a skeptic and proud of it, but I'm beginning to suspect that
> this is all a hoax.

Ok, I'll have a go at making that more understandable:

1. The input (=3Dshellcode) after the overflow will be executed by the
process with elevated privileges
2. There are quite a few input restrictions in what can be fed in
through the CLI, making any meaningful attack difficult through just
placing some shellcode after the overflow.
3. It is possible to execute shellcode stored in logicals, however.
4. Therefore the code injected after the overflow executes some other
code stored in a logical.

Sampsa

0
sampsal (134)
8/15/2008 2:48:44 PM
On Aug 15, 3:35 pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:
> samp...@gmail.com wrote:
> > [...snip...]
> > I think what they do (more or less) is to inject some shellcode into a
> > logical before running the exploit, then insert some other code after
> > the overflow that executes the code in the logical. Signedness guys
> > care to comment, I didn't see the demo, just have the notes second
> > hand?
>
> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
> but I actually didn't understand what that is meant to mean.
>
> I'm a skeptic and proud of it, but I'm beginning to suspect that
> this is all a hoax.

I've only been on VMS (and Unixes) since 1985 so I am not worthy, and
am risking teaching you how to suck eggs...

The general principle being referred to in the extract you quote is
that these exploits work by finding some OS-managed storage which is
writable by users and can potentially be executed later, preferably by
code with elevated privileges. So, for example, the name and/or
contents of a logical are in writable storage, and although that
storage isn't normally intended to hold code, if the memory management
subsystem doesn't prevent it being treated as code, then it can be
treated as code. So, you put some string of values in there somehow
that you want executed later, and all that's left to do is getting
control transferred to that code.

The classic mechanism for this unintended transfer of control is the
stack based buffer overflow scribbling over a return address. Here an
unchecked copy into a limited-size buffer is allowed to deposit more
data than the item can hold (which is why STR$this and DSC$that and
associated RTL routines are a NICE idea, one day maybe Billco and UNIX
will catch on to it). In the right circumstances, the excess data goes
far enough up(down?) the stack to overwrite the original return
address on the stack. Then all you have to do is work out how to get
the address of your "shell code" (?) written on to the stack in
exactly the right place to be interpreted as a return address when the
function in the picture returns to the caller (or in this case,
"returns" to the shell code).

If all this is done correctly you don't see an ACCVIO, you just end up
with unintended code being silently executed, potentially in the
context of an exploitable program. I haven't watched the videos but
the ACCVIOs here aren't what I'd expect to see as part of a successful
exploit; they are what I'd expect to see as the result of a bit of
traditional broken UNIX code with a traditional off-by-one or similar
schoolboy error (like the ones I still make :)). I'm entirely happy
that these things can be done in general, especially on commodity
OSes, and may even be possible on VMS, especially on apps with a UNIX
heritage which haven't been kept up to date.

I'm reserving judgement on whether I've seen proof.
0
8/15/2008 3:12:36 PM
In article <a13e2b99-8c71-45e3-bd9b-44b16b00ed06@34g2000hsh.googlegroups.com>, sampsal@gmail.com writes:
>On Aug 15, 3:35=A0pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:
>> samp...@gmail.com wrote:
>> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
>> but I actually didn't understand what that is meant to mean.
>>
>> I'm a skeptic and proud of it, but I'm beginning to suspect that
>> this is all a hoax.
>
>Ok, I'll have a go at making that more understandable:
>
>1. The input (=3Dshellcode) after the overflow will be executed by the
>process with elevated privileges
>2. There are quite a few input restrictions in what can be fed in
>through the CLI, making any meaningful attack difficult through just
>placing some shellcode after the overflow.
>3. It is possible to execute shellcode stored in logicals, however.
>4. Therefore the code injected after the overflow executes some other
>code stored in a logical.

I've mucked around quite a bit in DCL and I don't see how you get some
command or command procedure (shellcode) stored in a logical to be ex-
ecuted by DCL when you ACCVIO an image.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 3:56:23 PM
johnwallace4@yahoo.co.uk wrote:
> On Aug 15, 3:35 pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:

> If all this is done correctly you don't see an ACCVIO, you just end up
> with unintended code being silently executed, potentially in the
> context of an exploitable program. I haven't watched the videos but
> the ACCVIOs here aren't what I'd expect to see as part of a successful
> exploit;

IOW, isn't the ACCVIO a *proof* that the exploit was
*un*-successful ? They tried, but VMS "got them"...

Jan-Erik.
0
8/15/2008 5:42:08 PM
On Aug 15, 5:56 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <a13e2b99-8c71-45e3-bd9b-44b16b00e...@34g2000hsh.googlegroups.com>, samp...@gmail.com writes:
>
>
>
> >On Aug 15, 3:35=A0pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:
> >> samp...@gmail.com wrote:
> >> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
> >> but I actually didn't understand what that is meant to mean.
>
> >> I'm a skeptic and proud of it, but I'm beginning to suspect that
> >> this is all a hoax.
>
> >Ok, I'll have a go at making that more understandable:
>
> >1. The input (=3Dshellcode) after the overflow will be executed by the
> >process with elevated privileges
> >2. There are quite a few input restrictions in what can be fed in
> >through the CLI, making any meaningful attack difficult through just
> >placing some shellcode after the overflow.
> >3. It is possible to execute shellcode stored in logicals, however.
> >4. Therefore the code injected after the overflow executes some other
> >code stored in a logical.
>
> I've mucked around quite a bit in DCL and I don't see how you get some
> command or command procedure (shellcode) stored in a logical to be ex-
> ecuted by DCL when you ACCVIO an image.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional protection
> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
> of usenet _must_ include its contents in its entirety including this copyright
> notice, disclaimer and quotations.

You really don't get it. At all.
It has nothing to do with running code in a logical when a program
_causes_ an access violation
since the exploit take advantage of an error to take control of the
execution flow.
Since the PC is controlled in the CLI bug we simply jump to the
address of a logical that contains the
shellcode that we want to run.
In the case of the CLI bug (THE BUG IS NOT IN THE DCL SHELL) we use a
shellcode to execute
the create process system service which in turn executes FILE.EXE.
However, we did not bother
to add a clean exit after the create process shellcode so the process
crashes when FILE.EXE
has been executed.
This is not a problem since FILE.EXE already have been executed with
the privileges of the target program inherited.

Please pick up some book on exploit development and think a little
before doing statements
about things that you obviously don't know anything about.
0
bugs6 (57)
8/15/2008 6:00:49 PM
On Aug 15, 7:42 pm, Jan-Erik S=F6derholm <jan-erik.soderh...@telia.com>
wrote:
> johnwalla...@yahoo.co.uk wrote:
> > On Aug 15, 3:35 pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:
> > If all this is done correctly you don't see an ACCVIO, you just end up
> > with unintended code being silently executed, potentially in the
> > context of an exploitable program. I haven't watched the videos but
> > the ACCVIOs here aren't what I'd expect to see as part of a successful
> > exploit;
>
> IOW, isn't the ACCVIO a *proof* that the exploit was
> *un*-successful ? They tried, but VMS "got them"...
>
> Jan-Erik.

Yeah right .... You should probably get a book about exploit
development as well.
0
bugs6 (57)
8/15/2008 6:02:00 PM
bugs@signedness.org wrote:
> On Aug 15, 7:42 pm, Jan-Erik S�derholm <jan-erik.soderh...@telia.com>
> wrote:
>> johnwalla...@yahoo.co.uk wrote:
>>> On Aug 15, 3:35 pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:
>>> If all this is done correctly you don't see an ACCVIO, you just end up
>>> with unintended code being silently executed, potentially in the
>>> context of an exploitable program. I haven't watched the videos but
>>> the ACCVIOs here aren't what I'd expect to see as part of a successful
>>> exploit;
>> IOW, isn't the ACCVIO a *proof* that the exploit was
>> *un*-successful ? They tried, but VMS "got them"...
>>
>> Jan-Erik.
> 
> Yeah right .... You should probably get a book about exploit
> development as well.

OK, The process ACCVIO's *after* your code has run.
If so, there might be a "problem"...
0
8/15/2008 6:05:24 PM
In article <2970caa7-7806-4278-996e-79af773dc750@r66g2000hsg.googlegroups.com>, bugs@signedness.org writes:
> On Aug 15, 5:56 pm, VAXman-  @SendSpamHere.ORG wrote:
>>
>> I've mucked around quite a bit in DCL and I don't see how you get some
>> command or command procedure (shellcode) stored in a logical to be ex-
>> ecuted by DCL when you ACCVIO an image.
>>
> 
> You really don't get it. At all.

I think that Brian may be thinking that shellcode is a series of DCL
commands instead of machine code. I think it's already been pointed
out on this thread already what the definition of shellcode is in the
context that you are using it, but Wikipedia has a writeup in case
Brian missed the earlier message:

	http://en.wikipedia.org/wiki/Shellcode

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
8/15/2008 6:14:45 PM
In article <2970caa7-7806-4278-996e-79af773dc750@r66g2000hsg.googlegroups.com>, bugs@signedness.org writes:
>On Aug 15, 5:56 pm, VAXman-  @SendSpamHere.ORG wrote:
>> In article <a13e2b99-8c71-45e3-bd9b-44b16b00e...@34g2000hsh.googlegroups.com>, samp...@gmail.com writes:
>>
>>
>>
>> >On Aug 15, 3:35=A0pm, "R.A.Omond" <Roy.Om...@BlueBubble.UK.Com> wrote:
>> >> samp...@gmail.com wrote:
>> >> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
>> >> but I actually didn't understand what that is meant to mean.
>>
>> >> I'm a skeptic and proud of it, but I'm beginning to suspect that
>> >> this is all a hoax.
>>
>> >Ok, I'll have a go at making that more understandable:
>>
>> >1. The input (=3Dshellcode) after the overflow will be executed by the
>> >process with elevated privileges
>> >2. There are quite a few input restrictions in what can be fed in
>> >through the CLI, making any meaningful attack difficult through just
>> >placing some shellcode after the overflow.
>> >3. It is possible to execute shellcode stored in logicals, however.
>> >4. Therefore the code injected after the overflow executes some other
>> >code stored in a logical.
>>
>> I've mucked around quite a bit in DCL and I don't see how you get some
>> command or command procedure (shellcode) stored in a logical to be ex-
>> ecuted by DCL when you ACCVIO an image.
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>>
>> ... pejorative statements of opinion are entitled to constitutional protection
>> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>>
>> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
>> of usenet _must_ include its contents in its entirety including this copyright
>> notice, disclaimer and quotations.
>
>You really don't get it. At all.

No, as you really haven't explained it!  At all.



>It has nothing to do with running code in a logical when a program
>_causes_ an access violation
>since the exploit take advantage of an error to take control of the
>execution flow.
>Since the PC is controlled in the CLI bug we simply jump to the
>address of a logical that contains the
>shellcode that we want to run.

You keep talking about shellcode.  That's scripting in unix... what the
fuck ARE you talking about?



>In the case of the CLI bug (THE BUG IS NOT IN THE DCL SHELL) we use a
>shellcode to execute
>the create process system service which in turn executes FILE.EXE.
>However, we did not bother
>to add a clean exit after the create process shellcode so the process
>crashes when FILE.EXE
>has been executed.
>This is not a problem since FILE.EXE already have been executed with
>the privileges of the target program inherited.

Send me your so called "shellcode" and FILE.EXE then along with some
instuctions other than typing 511 characters and 3 up-arrows.



>Please pick up some book on exploit development and think a little
>before doing statements
>about things that you obviously don't know anything about.

Yeah, I know nothing about VMS.  Please, oh great one, teach me your
weirding way. 

Fuck off!  You come here claiming to have found some great exploit but
you won't clearly explain yourself.  Then, when you're questioned about
it, you cleverly -- as cleverly as you've explained yourself -- resort
to insult.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 7:24:42 PM
bugs@signedness.org wrote:

> That is the reason for using the FILE.EXE program.

Does FILE.EXE need to be installed with privileges and/or executed from
an account with elevated privileges ?
0
8/15/2008 7:34:56 PM
on 15-8-2008 21:24 VAXman- @SendSpamHere.ORG wrote...
[snip]
>> In the case of the CLI bug (THE BUG IS NOT IN THE DCL SHELL) we use a
>> shellcode to execute
>> the create process system service which in turn executes FILE.EXE.
>> However, we did not bother
>> to add a clean exit after the create process shellcode so the process
>> crashes when FILE.EXE
>> has been executed.
>> This is not a problem since FILE.EXE already have been executed with
>> the privileges of the target program inherited.
> 
> Send me your so called "shellcode" and FILE.EXE then along with some
> instuctions other than typing 511 characters and 3 up-arrows.

Exactly! The scientific method requires that "bugs" publish a 
reproducer, with instructions clear enough for all of us. It would also 
help if he provided a translation table to convert his arcane 
incantations to our own.

So far, from the discussion, I'm convinced bugs wouldn't recognize a VMS 
security flaw if it danced naked on his head and sang "Happy Days Are 
Here Again". (Oh, Blackadder, where hast thou gone?)


-- 
Wilm Boerhout                      Zwolle, NL
remove OLD PAINT from return address to reply
0
8/15/2008 7:37:21 PM
VAXman- @SendSpamHere.ORG wrote:

> OK.  I'm most confused.  How do you invoke SYS$CREPRC from DCL?  

$HELP SPAWN
$HELP RUN process

and to the original poster:

$HELP SHOW PROCESS /OUTPUT
0
8/15/2008 7:41:40 PM
sampsal@gmail.com wrote:

> 3. It is possible to execute shellcode stored in logicals, however.
> 4. Therefore the code injected after the overflow executes some other
> code stored in a logical.


Since there is no such thing as "shellcode" in VMS, it would greatly
help if you use terminology native to VMS so we could understand it.

For an application to execute the content of a logical name, it would
need to first extract those contents into memory, and then declare that
area of memory to be executable and then branch to it. This doesn't
happen by mistake/luck.
0
8/15/2008 7:49:30 PM
In article <48a5dcd2$0$1847$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>VAXman- @SendSpamHere.ORG wrote:
>
>> OK.  I'm most confused.  How do you invoke SYS$CREPRC from DCL?  
>
>$HELP SPAWN
>$HELP RUN process

I know that JF.  He said he called from his shellcode.  I now see, thanks
to another poster, that it is NOT what I understood it to be.  These unix
guys can be so confusing.



>and to the original poster:
>
>$HELP SHOW PROCESS /OUTPUT

Yeah, he still hasn't clearly stated WHY he needs to run a special program
to garner the process's privies when SHOW PROCESS/PRIV works JUST FINE.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 7:54:19 PM
On Aug 15, 8:49=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> samp...@gmail.com wrote:
> > 3. It is possible to execute shellcode stored in logicals, however.
> > 4. Therefore the code injected after the overflow executes some other
> > code stored in a logical.
>
> Since there is no such thing as "shellcode" in VMS, it would greatly
> help if you use terminology native to VMS so we could understand it.
>
> For an application to execute the content of a logical name, it would
> need to first extract those contents into memory, and then declare that
> area of memory to be executable and then branch to it. This doesn't
> happen by mistake/luck.

Ok, sorry guys, I'll stop using the term shellcode and use the term
exploit payload from now on, if that's ok with everyone? Bugs?

Anyway, I'm not going to rehash the whole explanation, but yes JF,
you're right, it doesn't happen by mistake or luck, instead there's a
small payload that follows the overflow which triggers the system into
executing the larger payload stored in the logical. I hope this makes
a bit more sense.

Bugs, can you verify my explanation is correct?

Sampsa

0
sampsal (134)
8/15/2008 7:57:51 PM
bugs@signedness.org wrote:

> since the exploit take advantage of an error to take control of the
> execution flow.

You mean you have discovered error handlers in VMS where you can
register a subroutine to execute when errors/access violations happen in
an executable program ?

Those are fully documented. No exploit there.

> Since the PC is controlled in the CLI bug we simply jump to the
> address of a logical that contains the
> shellcode that we want to run.

How do you obtain the address of that logical ? This is pretty critical
to knowing if you can jump to it or not.



> However, we did not bother
> to add a clean exit after the create process shellcode so the process
> crashes when FILE.EXE
> has been executed.

You mean you don't know about the "exit(1);" statement in C ?



> Please pick up some book on exploit development and think a little
> before doing statements
> about things that you obviously don't know anything about.

For someone to find such an exploit, one would need a fair amount of VMS
experience. And since you use terminology that is completely foreign to
VMS, it is hard to understand how you could have enough experience with
VMS to find such an exploit.


For instance, if Mr VAXman had found this exploit, he would have given
an explanation using terminology that is native to VMS because we know
he has a lot of experience with VMS.
0
8/15/2008 8:03:10 PM
In article <48a5daf7$0$6017$ba620dc5@text.nova.planet.nl>, Wilm Boerhout <w6OLD.PAINTboerhout@planet.nl> writes:
> on 15-8-2008 21:24 VAXman- @SendSpamHere.ORG wrote...
> [snip]
>> 
>> Send me your so called "shellcode" and FILE.EXE then along with some
>> instuctions other than typing 511 characters and 3 up-arrows.
> 
> Exactly! The scientific method requires that "bugs" publish a 
> reproducer, with instructions clear enough for all of us. It would also 
> help if he provided a translation table to convert his arcane 
> incantations to our own.
> 

Would you prefer the OP to post an exploit _before_ HP has issued a
patch for it ?

I saw in an earlier message that it had been reported to HP (IIRC).

If he has indeed reported it to HP, the OP seems to be following the
standard and responsible practice of not issuing detailed exploit
information until after a patch is available.

I would be interested in hearing what the current status on fixing this
problem is within HP however, given the recent UCX DNS issue.

> So far, from the discussion, I'm convinced bugs wouldn't recognize a VMS 
> security flaw if it danced naked on his head and sang "Happy Days Are 
> Here Again". (Oh, Blackadder, where hast thou gone?)
> 

Be careful here people when you accuse the OP of not been fully honest.

Based on how these things work on other operating systems, it's quite
possible that the OP has indeed found a unique VMS angle on a
traditional security problem that does indeed leave VMS systems
vulnerable.

As for me, I'm going to assume that there's something to this until
it's proven otherwise. Even if this specific attack turns out to not
be a real problem, he may have still found an approach that could
reveal more serious security problems in the future.

Don't be complaceant just before no-one has bothered taking some attack
vectors that work on other operating systems and tried them on VMS
until now.

Don't forget that we have one confirmed issue (the UCX finger client)
already. If that's what I think it is, then that one should never have
happened.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
8/15/2008 8:28:38 PM
On Aug 15, 9:03 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> b...@signedness.org wrote:
> > since the exploit take advantage of an error to take control of the
> > execution flow.
>
> You mean you have discovered error handlers in VMS where you can
> register a subroutine to execute when errors/access violations happen in
> an executable program ?
>
> Those are fully documented. No exploit there.
>
> > Since the PC is controlled in the CLI bug we simply jump to the
> > address of a logical that contains the
> > shellcode that we want to run.
>
> How do you obtain the address of that logical ? This is pretty critical
> to knowing if you can jump to it or not.
>
> > However, we did not bother
> > to add a clean exit after the create process shellcode so the process
> > crashes when FILE.EXE
> > has been executed.
>
> You mean you don't know about the "exit(1);" statement in C ?
>
> > Please pick up some book on exploit development and think a little
> > before doing statements
> > about things that you obviously don't know anything about.
>
> For someone to find such an exploit, one would need a fair amount of VMS
> experience. And since you use terminology that is completely foreign to
> VMS, it is hard to understand how you could have enough experience with
> VMS to find such an exploit.
>
> For instance, if Mr VAXman had found this exploit, he would have given
> an explanation using terminology that is native to VMS because we know
> he has a lot of experience with VMS.

I have been around long enough to realise that whatever bit of IT you
work in, it has its own private terminology (as do many trades and
professions). When I started my 2nd job, a couple of decades ago, I
heard a lot of references to "scenario interpreters". Because I wasn't
directly involved, it took me weeks to work out that what was actually
being talked about was a test script interpreting tool with a fancy
name. Same thing here. A common set of terminology is helpful, but
often doesn't exist across different communities. How you get that
common terminology/language is interesting, but I thought it was
mostly the stereotypical English (and Yanks) that insisted that
everyone changed to speak in *their* language...

Wrt obtaining the address of the logical/shellcode etc: there are lots
of ways, depending on the circumstances. In the Windows and Unix
world, many exploits have traditionally depended on the fact that the
same OS or common application code and data is always loaded at the
same virtual address, across different systems and at different times
(consequently this staticness has begun to change recently). Does VMS
have that predictability too? Even if it doesn't, given that you know
what the shellcode looks like and if you have access to the relevant
memory, maybe you just go looking for it and adjust (something)
accordingly. Maybe.

One thing that anyone who's ever done "customer support" work (which
is a lot of contributors here, I think) should understand is the well-
known concept of "a simple reproducer", with minimal obfuscation and
clutter. Language difficulties apart, have we got one of those here
yet?
0
8/15/2008 8:32:34 PM
On Aug 15, 9:49 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> samp...@gmail.com wrote:
> > 3. It is possible to execute shellcode stored in logicals, however.
> > 4. Therefore the code injected after the overflow executes some other
> > code stored in a logical.
>
> Since there is no such thing as "shellcode" in VMS, it would greatly
> help if you use terminology native to VMS so we could understand it.
>
> For an application to execute the content of a logical name, it would
> need to first extract those contents into memory, and then declare that
> area of memory to be executable and then branch to it. This doesn't
> happen by mistake/luck.

There sure is shellcode for OpenVMS, we wrote it. :)
And there is no need to extract the contents of a logical into memory,
since it is already part of the memory in a process.

You can check out wikipedia for information about the shellcode that
we refer to:
http://en.wikipedia.org/wiki/Shellcode

And here is an entry about exploits as well:
http://en.wikipedia.org/wiki/Exploit_%28computer_security%29

And one on format string vulnerabilities:
http://en.wikipedia.org/wiki/Format_string_attack

Oh, and just for the record, you don't find an exploit, you find a
vulnerability and write an exploit for it. :)

As stated earlier, we will not release the exploit to the public yet.
We have informed HP about the problems (we did this about two months
ago
together with information about how to reproduce the bugs)
so there will hopefully be a patch for it in a near future.

And no, FILE.EXE does not require any privileges, it is just a simple
tool
to write the current privileges of the process to a file.

Please don't tell us to "fuck off", it makes some of us belive that it
is
a good idea to post sensitive information to fd.

And there still is enough information in the previous posts to
reproduce the bugs on a vulnerable machine.
0
bugs6 (57)
8/15/2008 8:57:38 PM
In article <48a5e1dd$0$1845$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> For someone to find such an exploit, one would need a fair amount of VMS
> experience. And since you use terminology that is completely foreign to
> VMS, it is hard to understand how you could have enough experience with
> VMS to find such an exploit.
> 

Hello JF,

Unfortunately, that's an assumption you can't make.

In the same way that a programming language has it's own set of terminology
regardless of the operating system that you are running that language on,
the security community also has it's own set of terminology that stays
consistant regardess of the operating system that they are examining.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
0
clubley (1478)
8/15/2008 8:58:16 PM
On Aug 15, 10:03 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> b...@signedness.org wrote:
> > since the exploit take advantage of an error to take control of the
> > execution flow.
>
> You mean you have discovered error handlers in VMS where you can
> register a subroutine to execute when errors/access violations happen in
> an executable program ?
>
> Those are fully documented. No exploit there.
>
> > Since the PC is controlled in the CLI bug we simply jump to the
> > address of a logical that contains the
> > shellcode that we want to run.
>
> How do you obtain the address of that logical ? This is pretty critical
> to knowing if you can jump to it or not.
>
> > However, we did not bother
> > to add a clean exit after the create process shellcode so the process
> > crashes when FILE.EXE
> > has been executed.
>
> You mean you don't know about the "exit(1);" statement in C ?
We know about the exit() statement, but it is a little more to it
to write it in assembly for OpenVMS so we did not spend any time
to look up the system service index for it since the exploit works
without
a clean exit.

>
> > Please pick up some book on exploit development and think a little
> > before doing statements
> > about things that you obviously don't know anything about.
>
> For someone to find such an exploit, one would need a fair amount of VMS
> experience. And since you use terminology that is completely foreign to
> VMS, it is hard to understand how you could have enough experience with
> VMS to find such an exploit.
>
> For instance, if Mr VAXman had found this exploit, he would have given
> an explanation using terminology that is native to VMS because we know
> he has a lot of experience with VMS.

Well, knowing a whole lot about VMS is not the same thing as writing
an exploit.
We are pretty sure that VAXman knows a lot more about OpenVMS then we
do.
We just wrote some exploits for vulnerabilities that we found.

This is how we trigger the CLI bug:

1) Start a program using the command line interface library, like
install
2) At the prompt (INSTALL>), paste 511 characters and then press the
    upp arrow key three times to move the history line pointer in
memory
3) The pointer now points to a address that will be jumped to, so go
ahead
    and manually write the return address, like pressing the 'b'
character 4 times
4) Wait
5) If the machine is vulnerable you will get an access violation.
0
bugs6 (57)
8/15/2008 9:04:31 PM
On Aug 15, 10:03 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> How do you obtain the address of that logical ? This is pretty critical
> to knowing if you can jump to it or not.

Yes, that is correct and a lot of time was consumed to determine that
the value of a logical actually can be executed.
We also looked at other areas without success (CLI Data for example).

To find the address of a logical you can write a small program that
set a logical and then crashes and scan the core dump as a local user,
the logical will be
located att the same address when you attack your target.

The LOADCODE.EXE tool in the movie loads the shellcode into a logical
at a known address before exploiting the target program.

You can also use analyze/system and clue process/logical to find the
exact address of a logical, but that requires SYSTEM privileges.
0
bugs6 (57)
8/15/2008 9:19:51 PM
On Aug 15, 9:57 pm, samp...@gmail.com wrote:
> On Aug 15, 8:49 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
> > samp...@gmail.com wrote:
> > > 3. It is possible to execute shellcode stored in logicals, however.
> > > 4. Therefore the code injected after the overflow executes some other
> > > code stored in a logical.
>
> > Since there is no such thing as "shellcode" in VMS, it would greatly
> > help if you use terminology native to VMS so we could understand it.
>
> > For an application to execute the content of a logical name, it would
> > need to first extract those contents into memory, and then declare that
> > area of memory to be executable and then branch to it. This doesn't
> > happen by mistake/luck.
>
> Ok, sorry guys, I'll stop using the term shellcode and use the term
> exploit payload from now on, if that's ok with everyone? Bugs?
>
> Anyway, I'm not going to rehash the whole explanation, but yes JF,
> you're right, it doesn't happen by mistake or luck, instead there's a
> small payload that follows the overflow which triggers the system into
> executing the larger payload stored in the logical. I hope this makes
> a bit more sense.
>
> Bugs, can you verify my explanation is correct?
>
> Sampsa

Yup, pretty much like that except that we actually does not need the
first
stage since we fully control the PC from start and just have to jump
to
the address of the logical containing the shellcode.
Thanx for helping out explaining.
0
bugs6 (57)
8/15/2008 9:37:42 PM
bugs@signedness.org wrote:

> You can check out wikipedia for information about the shellcode that
> we refer to:
> http://en.wikipedia.org/wiki/Shellcode

Then you should have simply used "executable code" when speaking in
comp.os.vms terms. Or even "compiled" code.

> As stated earlier, we will not release the exploit to the public yet.

I don't need the specific exploit. But since you came here, one would
have expected you could be able to explain it in normal VMS terminology.

For instance, when use the term "logical", are you refering to a VMS
logical name ? Was that logical name created by a program, or via DCL
commands ? which logical name table, what attributes (user, super, exec,
tranlstion=terminal or translation=concealed etc).

Lack of such specifics makes us wonder if you are even talking about a
real logical name because your terminology is so out of wack with the
VMS world so we have no idea if you know what a logical name is.




> We have informed HP about the problems (we did this about two months
> ago

No surprise there. You may need to publish the exploit in CERT, *and*
then make a lot of noise in order to get HP's attention on this and get
them to reluctantly assign resources to look into it.

> Please don't tell us to "fuck off", it makes some of us belive that it
> is
> a good idea to post sensitive information to fd.

I have no intention to tell you that. It is just that because of the
foreign terminology you insist on using, it is very hard to understand
that you know anything about VMS.



What I don't understand is how, after pressing the up arrow 3 times, VMS
would magically branch to some memory address magically containing the
contents of some logical name, and make that block of memory executable.

If, entering excess characters during an input operation would result in
your excess characters overwriting executable memory locations, then
this would be a serious issue with some linker option file that didn't
properly declare executable memory as non-writable.

The whole concept of memory management in VMS makes it very hard to have
it execute data memory, or write over executable memory.
0
8/15/2008 10:50:04 PM
Ok, rereading some of the posts:

You don,t enter 511 characters. You enter a few more than 511, with
those few more essentially being a binary branch instruction to a
specific area of memory known to contain the contents of a logical name.

That logical name contains more binary code that is executed without any
 access violations.

Does this mean that you have succesfully found a way to create a logical
name whose contents are in a memory location that has been tagged as
executable ?

If i understand right, there are 2 bugs here;

1: that the input operation will succesfully write data to an
execute-only section of memory located after the input buffer.

2- that the contents of a logical name are stored in memory that can be
executed.
0
8/15/2008 10:55:11 PM
On Aug 15, 4:04=A0pm, b...@signedness.org wrote:
> On Aug 15, 10:03 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
> > b...@signedness.org wrote:
> > > since the exploit take advantage of an error to take control of the
> > > execution flow.
>
> > You mean you have discovered error handlers in VMS where you can
> > register a subroutine to execute when errors/access violations happen i=
n
> > an executable program ?
>
> > Those are fully documented. No exploit there.
>
> > > Since the PC is controlled in the CLI bug we simply jump to the
> > > address of a logical that contains the
> > > shellcode that we want to run.
>
> > How do you obtain the address of that logical ? This is pretty critical
> > to knowing if you can jump to it or not.
>
> > > However, we did not bother
> > > to add a clean exit after the create process shellcode so the process
> > > crashes when FILE.EXE
> > > has been executed.
>
> > You mean you don't know about the "exit(1);" statement in C ?
>
> We know about the exit() statement, but it is a little more to it
> to write it in assembly for OpenVMS so we did not spend any time
> to look up the system service index for it since the exploit works
> without
> a clean exit.
>
>
>
> > > Please pick up some book on exploit development and think a little
> > > before doing statements
> > > about things that you obviously don't know anything about.
>
> > For someone to find such an exploit, one would need a fair amount of VM=
S
> > experience. And since you use terminology that is completely foreign to
> > VMS, it is hard to understand how you could have enough experience with
> > VMS to find such an exploit.
>
> > For instance, if Mr VAXman had found this exploit, he would have given
> > an explanation using terminology that is native to VMS because we know
> > he has a lot of experience with VMS.
>
> Well, knowing a whole lot about VMS is not the same thing as writing
> an exploit.
> We are pretty sure that VAXman knows a lot more about OpenVMS then we
> do.
> We just wrote some exploits for vulnerabilities that we found.
>
> This is how we trigger the CLI bug:
>
> 1) Start a program using the command line interface library, like
> install
> 2) At the prompt (INSTALL>), paste 511 characters and then press the
> =A0 =A0 upp arrow key three times to move the history line pointer in
> memory
> 3) The pointer now points to a address that will be jumped to, so go
> ahead
> =A0 =A0 and manually write the return address, like pressing the 'b'
> character 4 times
> 4) Wait
> 5) If the machine is vulnerable you will get an access violation.

Can't duplicate this on any system, any version of VMS, with or
without patches.  I then tried from the V8.3 CD boot environment
(about as basic as it gets)on a DS10L 466MHz.  All tests were with
INSTALL.

I even installed a fresh V8.3 off the CD on the DS10L and tried, then
installed TCPIP, rebooted, tried again, installed DECnet, rebooted,
tried again.  Tried variants entering a carriage return after the 511
before the up arrows, after the 'bbbb', etc, all I ever get is the
expected CLI-W-IVVERB, unrecognized command verb.  Entering the 511
characters, then three up arrows, then bbbb then waiting did nothing
at all no matter which system or OS version I was running.

How long is the wait time?  I gave it 4-5 minutes each time.

No I haven't watched the videos; can't load foreign codecs on the work
peecees.

VMS Versions tried:  V7.3 with current ECOs, V7.3-2 with current ECOs,
V8.2 with current ECOs, V8.3 with current ECOs, V8.2 CD boot
environment, V8.3 CD boot environment, V8.3 basic install, V8.3 basic
install plus TCPIP, V8.3 basic install plus TCPIP plus DECnet Phase
IV.
0
jordan (1228)
8/15/2008 11:01:45 PM
In article <48a609ef$0$18591$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Ok, rereading some of the posts:
>
>You don,t enter 511 characters. You enter a few more than 511, with
>those few more essentially being a binary branch instruction to a
>specific area of memory known to contain the contents of a logical name.
>
>That logical name contains more binary code that is executed without any
> access violations.
>
>Does this mean that you have succesfully found a way to create a logical
>name whose contents are in a memory location that has been tagged as
>executable ?

Memory is readable-only or read-write on Alpha.  There's nothing in the
PTE on VMS to indicate that it is or is not executable instruction code.
 
Take, for example, SYS$PUBLIC_VECTORS.  In SDA you can look at this execlet
and it contains two sections: Nonpaged read only and Nonpaged read/write.
The non-paged read only contains code.  

The PTE for the non-page read-only looks like:

 3 3 2  2              2   1   1 1
 1 0 9  7              0   8   6 5               7 6           0
+-+-+--+--------------+-+-+---+-+---------------+-+-----------+-+
|0|0|00|     0000     |0|X| 00|0|      0F       |X|    39     |1|
+-+-+--+--------------+-+-+---+-+---------------+-+-----------+-+
|                            00000200                           |
+---------------------------------------------------------------+
Valid PTE: Read Prot = KESU, Write Prot = NONE
           Owner = K, Fault on = ---R, ASM = 01, Granularity Hint = 03
           CPY = 00  PFN = 00000200

The PTE for the non-page read-write looks like:

 3 3 2  2              2   1   1 1
 1 0 9  7              0   8   6 5               7 6           0
+-+-+--+--------------+-+-+---+-+---------------+-+-----------+-+
|0|0|00|     0000     |0|X| 00|0|      1F       |X|    28     |1|
+-+-+--+--------------+-+-+---+-+---------------+-+-----------+-+
|                            00000600                           |
+---------------------------------------------------------------+
Valid PTE: Read Prot = KESU, Write Prot = K---
           Owner = K, Fault on = NONE, ASM = 01, Granularity Hint = 02
           CPY = 00  PFN = 00000600

I have routinely changed code in both of these types of regions.  Read-
only by mapping the physical address to a writeable page I allocate.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/15/2008 11:20:25 PM
In message <850bdecd-1a8b-40a2-9053-d259148afc43@d1g2000hsg.googlegroups.com>,
  bugs@signedness.org writes:
>To find the address of a logical you can write a small program that
>set a logical and then crashes and scan the core dump as a local user,
>the logical will be located att the same address when you attack your target.

I don't know how this 'core dump as a local user' technique would find what
you are looking for, but process logical names are kept in non-shared memory
readable in user mode.  Therefore, after you call LIB$SET_LOGICAL, you can
retrieve the pointer at CTL$GL_LNMHASH and search live memory for the logical
name and address of its equivalence string.



David L. Jones               |      Phone:    (614) 271-6718
Ohio State University        |      Internet:
140 W. 19th St.              |               jonesd@ecr6.ohio-state.edu
Columbus, OH 43210           |               vman+@osu.edu

Disclaimer: I'm looking for marbles all day long.
0
JONESD2 (40)
8/16/2008 12:04:12 AM
In article <g855hs$d4v$1@charm.magnus.acs.ohio-state.edu>, JONESD@ecr6.ohio-state.edu (David Jones) writes:
>In message <850bdecd-1a8b-40a2-9053-d259148afc43@d1g2000hsg.googlegroups.com>,
>  bugs@signedness.org writes:
>>To find the address of a logical you can write a small program that
>>set a logical and then crashes and scan the core dump as a local user,
>>the logical will be located att the same address when you attack your target.
>
>I don't know how this 'core dump as a local user' technique would find what
>you are looking for, but process logical names are kept in non-shared memory
>readable in user mode.  Therefore, after you call LIB$SET_LOGICAL, you can
>retrieve the pointer at CTL$GL_LNMHASH and search live memory for the logical
>name and address of its equivalence string.

I fail to see why this code, if it can be executed, must be stored in a 
logical name block's translation region which may be somewhat arduous to 
locate and its address is, more likely than not, empirically derived and
hard-coded in this exploit.  

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 12:37:59 AM
VAXman- @SendSpamHere.ORG wrote:

> Memory is readable-only or read-write on Alpha.  There's nothing in the
> PTE on VMS to indicate that it is or is not executable instruction code.

Oh wow. I was way off then. Was this the case for VAX where memory would
be tagged as executable or not ?

So, if, on alpha-VMS, one can branch to any memory address you have read
access to, I can see how this problem becomes much easier to
reproduce/cause.

0
8/16/2008 12:44:49 AM
On Aug 12, 9:58=A0am, samp...@gmail.com wrote:
> 2. A CLI buffer overflow on Alphas. Basically any input over 511
> characters causes an overflow, it seems to be possible to have a
> privileged process execute arbitrary code.

As an interested observer, I was able to duplicate this problem on my
DS10L running OpenVMS v7.3-2.  I am a little behind in patches on this
machine.  I tried the same thing on a system which is up-to-date and
could not duplicate the problem.

It certainly does open an interesting hole that could be exploited.

1) Enter an application which presents a prompt for a command string
(for example, MAIL).  Presumably any application released with the o/s
uses the CLI utility routines to parse the command string.  This is
then a problem with the CLI routines.

2) Paste 511 characters, then press the up-arrow key three times, then
type in some other string of characters.

3) Wait patiently.  The application will crash with an access
violation.

4) Look at the address where the accvio occurred, and compare it to
the hex representation of the characters typed after the three up-
arrow keystrokes.
0
sapienza (410)
8/16/2008 12:54:01 AM
In article <48a623a0$0$18525$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>VAXman- @SendSpamHere.ORG wrote:
>
>> Memory is readable-only or read-write on Alpha.  There's nothing in the
>> PTE on VMS to indicate that it is or is not executable instruction code.
>
>Oh wow. I was way off then. Was this the case for VAX where memory would
>be tagged as executable or not ?
>
>So, if, on alpha-VMS, one can branch to any memory address you have read
>access to, I can see how this problem becomes much easier to
>reproduce/cause.

Same with VAX.  You could have specified it in Macro .PSECTs for example
but it didnt translate to PTE protections.

Itanium does have an EXECUTE for PTEs.  I still haven't seen that used.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 1:00:53 AM
In article <ac6dba7e-daf6-43d7-94d3-f5b32a243788@a1g2000hsb.googlegroups.com>, FrankS <sapienza@noesys.com> writes:
>On Aug 12, 9:58=A0am, samp...@gmail.com wrote:
>> 2. A CLI buffer overflow on Alphas. Basically any input over 511
>> characters causes an overflow, it seems to be possible to have a
>> privileged process execute arbitrary code.
>
>As an interested observer, I was able to duplicate this problem on my
>DS10L running OpenVMS v7.3-2.  I am a little behind in patches on this
>machine.  I tried the same thing on a system which is up-to-date and
>could not duplicate the problem.
>
>It certainly does open an interesting hole that could be exploited.
>
>1) Enter an application which presents a prompt for a command string
>(for example, MAIL).  Presumably any application released with the o/s
>uses the CLI utility routines to parse the command string.  This is
>then a problem with the CLI routines.
>
>2) Paste 511 characters, then press the up-arrow key three times, then
>type in some other string of characters.

OK.  I booted from my virgin V7.3-2 test disk.  I entered MAIL.  I typed
64 Xs in an edit session and cut from it.  Pasted it in 7 times and then
deleted one X in the string in the edit session to pasted the last 63 Xs.
(That's 511 on my calculator!) I then hit 3 up arrows and typed in XYZZY. 


>3) Wait patiently.  The application will crash with an access
>violation.

How patiently should I wait?  I'm going to bed now.  If I'm still at the
MAIL prompt in the morning, this is a red herring.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 1:10:49 AM
On Aug 15, 9:10=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> How patiently should I wait? =A0I'm going to bed now. =A0If I'm still at =
the
> MAIL prompt in the morning, this is a red herring.

E pur si muove.

I didn't say my v7.3-2 install was virginal.  Just that it wasn't up-
to-date.

I have no interest in getting your system to crash.  I can only
honestly tell you that mine does, in the manner described.
Furthermore, I have no connection to any of the people that posted the
description of the problem in the first place.  Just figured I'd try
and duplicate it on my own.

If you want to study this more on your own then here's the PCSI
install history from my system:

----------------------------------- ----------- -----------
--------------------
DEC AXPVMS COBOL V2.9-1453          Full LP     Install     15-
JUN-2008 11:49:06
DEC AXPVMS COBOL V2.8-1286          Full LP     Remove      15-
JUN-2008 11:49:06
CPQ AXPVMS OMSVA V1.2               Full LP     Install     16-
JAN-2008 19:37:10
DEC AXPVMS COBRTL V2.8-670B         Full LP     Install     16-
JAN-2008 17:51:47
DEC AXPVMS COBOL V2.8-1286          Full LP     Install     16-
JAN-2008 17:49:46
DEC AXPVMS VMS732_AUDSRV V5.0       Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_CLIUTL V1.0       Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_DCL V9.0          Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_FIBRE_SCSI V13.0  Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_LIBRTL V2.0       Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_LOADSS V3.0       Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_MANAGE V6.0       Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_MOUNT96 V3.0      Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_PTHREAD V6.0      Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_SHADOWING V6.0    Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS VMS732_STARLETOLB V1.0   Patch       Install     16-
JAN-2008 17:35:38
DEC AXPVMS TCPIP V5.4-15ECO7        Full LP     Install     16-
JAN-2008 16:58:22
DEC AXPVMS TCPIP V5.4-15            Full LP     Remove      16-
JAN-2008 16:58:22
DEC AXPVMS DWMOTIF_ECO03 V1.3-1     Patch       Install     16-
JAN-2008 16:57:15
DEC AXPVMS DNVOSIECO03 V7.3-2       Patch       Install     16-
JAN-2008 16:56:52
DEC AXPVMS DNVOSIMUP01 V7.3-2       Patch       Install     16-
JAN-2008 16:56:35
DEC AXPVMS VMS732_SYS V14.0         Patch       Install     16-
JAN-2008 16:52:15
DEC AXPVMS VMS732_UPDATE V13.0      Patch       Install     16-
JAN-2008 16:37:16
DEC AXPVMS VMS732_PCSI V3.0         Patch       Install     16-
JAN-2008 16:31:06
CPQ AXPVMS CDSA V2.0-109            Full LP     Install     16-
JAN-2008 10:30:21
DEC AXPVMS DECNET_OSI V7.3-2        Full LP     Install     16-
JAN-2008 10:30:21
DEC AXPVMS DWMOTIF V1.3-1           Full LP     Install     16-
JAN-2008 10:30:21
DEC AXPVMS OPENVMS V7.3-2           Platform    Install     16-
JAN-2008 10:30:21
DEC AXPVMS TCPIP V5.4-15            Full LP     Install     16-
JAN-2008 10:30:21
DEC AXPVMS VMS V7.3-2               Oper System Install     16-
JAN-2008 10:30:21
HP AXPVMS KERBEROS V2.0-6           Full LP     Install     16-
JAN-2008 10:30:21
----------------------------------- ----------- -----------
--------------------

0
sapienza (410)
8/16/2008 2:22:15 AM
FrankS wrote:

> I have no interest in getting your system to crash. 

Does the 511 character recall buffer thing crash the system, the process
or just the application that was running at the time ?

Obviously, if you manage to $CMKRNL and call a nasty routine, you can
easily crash the system (trying to divide by 0 for instance).

But just entering random characters after the 511 up-up-up sequence
should just branch you to some random memory address within your
process's memory space.

Ahhh, I see the vulnerability now...

If MAIL or INSTALL is installed with privileges, then getting them to
execute some of your own code that exists in your process' memory space
would allow that code to execute with whatever privileges that image was
installed with (assuming the image did not de-activate the priv at the
time you caused it to branch to your own code.
0
8/16/2008 3:00:28 AM
On Aug 15, 8:37=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <g855hs$d4...@charm.magnus.acs.ohio-state.edu>, JON...@ecr6.oh=
io-state.edu (David Jones) writes:
>
> >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegroups=
..com>,
> > =A0b...@signedness.org writes:
> >>To find the address of a logical you can write a small program that
:
> I fail to see why this code, if it can be executed, must be stored in a
> logical name block's translation region which may be somewhat arduous to
> locate

Best I understand this, the hack needs any address which can be
expressed with a series of ASCII expressable address mappings and
survives image activation.
Logical names are stored in Process Allocation Region (P1 Pool) which
typically starts at (sysgen param dependend) 7Fxxxxxx. So you would
use a '~' for a first char. When I tried one, it started at
"7FF565A0". That F5 would be hard to express. So you would need many
more logicals to eat up space.
An other good zone could be the the Process I/O Segment (PIO). A first
test showed a buffer at 07B0B4400 ($open x login.com $read x y...
$ANAL/SYS... SHOW PROC/RMS=3D(BDBSUM,PIO). If you open a relative fiel
with bucket size of 60 or so, then you can make the system read 30KB
of 'stuff' into p1 space.

For a quick address overview: SDA> CLUE PROC/LAYOUT

fwiw,
Hein.
0
8/16/2008 3:26:54 AM
On Aug 15, 11:00=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Does the 511 character recall buffer thing crash the system, the process
> or just the application that was running at the time ?

Sorry for the confusion, JF.  It simply generates an access violation
in the process that was running at the time.  Not a system crash.  The
process terminates and you're returned to DCL.

However, given that the address where the access violation occurs can
be predetermined, I at least can see that it is possible to exploit
the problem as has been described already.

For example, TCPIP is installed with CMKRNL.  If you do this with
TCPIP as the application instead of MAIL then you can end up with a
situation where an unprivileged user has free access to CMKRNL.
0
sapienza (410)
8/16/2008 10:57:44 AM
On Aug 16, 4:26=A0am, Hein RMS van den Heuvel
<heinvandenheu...@gmail.com> wrote:
> On Aug 15, 8:37=A0pm, VAXman- =A0@SendSpamHere.ORG wrote:
>
> > In article <g855hs$d4...@charm.magnus.acs.ohio-state.edu>, JON...@ecr6.=
ohio-state.edu (David Jones) writes:
>
> > >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegrou=
ps.com>,
> > > =A0b...@signedness.org writes:
> > >>To find the address of a logical you can write a small program that
> :
> > I fail to see why this code, if it can be executed, must be stored in a
> > logical name block's translation region which may be somewhat arduous t=
o
> > locate
>
> Best I understand this, the hack needs any address which can be
> expressed with a series of ASCII expressable address mappings and
> survives image activation.
> Logical names are stored in Process Allocation Region (P1 Pool) which
> typically starts at (sysgen param dependend) 7Fxxxxxx. So you would
> use a '~' for a first char. When I tried one, it started at
> "7FF565A0". That F5 would be hard to express. So you would need many
> more logicals to eat up space.
> An other good zone could be the the Process I/O Segment (PIO). A first
> test showed a buffer at 07B0B4400 ($open x login.com $read x y...
> $ANAL/SYS... SHOW PROC/RMS=3D(BDBSUM,PIO). If you open a relative fiel
> with bucket size of 60 or so, then you can make the system read 30KB
> of 'stuff' into p1 space.
>
> For a quick address overview: SDA> CLUE PROC/LAYOUT
>
> fwiw,
> Hein.

Still fighting jetlag but I'm back to comment on a few things... (some
things another presenter already pointed out but they are worth saying
again)..

1) People complaining about our terminology.. Well here is the thing,
our material was presented at a SECURITY conference so it  makes sense
to use recognised security terminology, don't you think?

2) Insinuations that we are bullshitting.. Well thats just hilarious
coming from people by their own admission triggered one of the bugs
(R.A.Omond you may want to read the teso paper on exploiting format
string vulnerabilities to understand the output you are getting from
finger)

3) Sampsa and johnwalla...@yahoo.co.uk seems to have gotten it mostly
right.

To johnwalla...@yahoo.co.uk and Jan-Erik S=F6derholm, the reason why you
see the access violation in the exploit video is not that the exploit
isn't working, the shellcode is executed and executes FILE.EXE.
However since we have trashed the stackframe it crashes when it tries
to return from the already executed shellcode. The reason you don't
often see similar behavior in UNIX exploits is that they often use a
shellcode that executes a shell with the execve() system call.
execve() replaces the process image and never returns if sucessful.. I
hope that clears that up.

4) "There is no such thing as "shellcode" in VMS".. Well shellcode is
platform neutral terminology, and while there might not be any public
VMS shellcodes we certainly have a few..

5) JF Mezei, yes we know about the exit() function.. But it would have
to be called from the shellcode written in assembler, and as already
mentioned it would only be a cosmetic thing since the injected code
already been executed. Do YOU know the openvms calling standard on the
affected platforms? We just didn't think it was worth the effort.. IF
YOU feel it is worth the effort, then you are free to write you own
exploit... We never claimed to be VMS experts, infact one of the first
thing we mention in the talk is that we are NOT.. However exploiting
these bugs are hardly rocket science (again at some point I believe we
mentioned that we found it interesting/surprising that such simple
bugs still existed in a supposedly secure OS)... For your complaint
about our terminology see 1)...
=A8
The comment that fair amount of experience with OpenVMS is required to
find these bugs is laughable, we had absolutely none when we started
looking for bugs. Fair enough there were some obstacles to overcome,
like pretty poor debugging environments, tools not working the way we
are used to, having to read up on VAX and Alpha asm etc. But in the
end an overflow is still an overflow and a format string bug is still
a format string bug and if you exploited things like that for the last
10 year or so its not terribly hard to adapt to a new environment. I
think your comment says more about the attitudes in the VMS community
than it says about our lack of experience with VMS.

6) Bradhamilton, yes we contacted the right people. Had a short dialog
with them and then they stopped replying. The two finger bugs we
exploited are local priv escalation bugs (well the format string bug
anyway). The remote fingerd bug reported by someone at NGS we have not
looked at so I can not really comment on that one.. At least on VAX it
most likely depends on the C function causing the overflow and the
ability of writing NULL bytes, and on alpha I'd assume there would be
some interesting problem to solve too..

7) Hein RMS van den Heuvel. Don't know if you seen the video, but the
problem with typing in return address composed of "weird" characters
is why we use a homebrewed telnet client.

8) FrankS. Congrats on reproducing it!


9) Wilm Boerhout, well buddy.. We already stated that we won't release
any exploits at least until HP released a fix and people had a chance
to patch. The finger bug several people here managed to reproduce, in
some cases even without realising themselves! See 2).

How is that for not being able to recognise a naked, dancing security
bug on your head?

The cmdline stuff have now been reproduced by FrankS. On top of that
we are offering to DEMO the exploit LIVE for anyone that is able to
meet up with us.... Maybe you rather want us to release a working
exploit before patches are out.. We will keep that in mind for the
next set of bugs, maybe you also like to share the IP addresses of
your VMS boxes so we can include them in the exploit code for demo
purposes? </sarcasm>


10) For the naysayers... We already stated that we are not releasing
an exploit for this issue at least not until HP patched it and people
had a chance to patch. Judging from some email address, there are
people from the UK here.. You are all welcome to visit a dc4420
meeting and I'll DEMO the exploit for you LIVE (no video)... Also we
are visiting Stockholm in September so assuming he can make it, We'd
be happy to show Jan-Erik S=F6derholm or any other Swedish naysayers a
live demo.

11) Finally... It is pretty interesting to see peoples reaction to
this.. 2 out of 3 PRESENTED issues seems to have been independently
verified now. Yet, we are not believed, told to go fuck ourselves,
doubted and more or less called liars.. I can understand some healthy
scepticism, but maybe you also have some of that to spare for claims
of OpenVMS "superior security"...but if you rather take the
comfortable "head in sand" position then thats fine by me as long as
you don't host any of my data.
0
bugs6 (57)
8/16/2008 11:01:21 AM
In article <7f1b0e7d-6901-4426-b337-8498c14cfe06@m73g2000hsh.googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>On Aug 15, 8:37=A0pm, VAXman-  @SendSpamHere.ORG wrote:
>> In article <g855hs$d4...@charm.magnus.acs.ohio-state.edu>, JON...@ecr6.oh=
>io-state.edu (David Jones) writes:
>>
>> >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegroups=
>..com>,
>> > =A0b...@signedness.org writes:
>> >>To find the address of a logical you can write a small program that
>:
>> I fail to see why this code, if it can be executed, must be stored in a
>> logical name block's translation region which may be somewhat arduous to
>> locate
>
>Best I understand this, the hack needs any address which can be
>expressed with a series of ASCII expressable address mappings and
>survives image activation.

Surviving image activation I understand.  There are many ways to achieve 
that goal.


>Logical names are stored in Process Allocation Region (P1 Pool) which
>typically starts at (sysgen param dependend) 7Fxxxxxx. So you would
>use a '~' for a first char. When I tried one, it started at
>"7FF565A0". That F5 would be hard to express. So you would need many
>more logicals to eat up space.

OK.  Now we're getting somewhere.


>An other good zone could be the the Process I/O Segment (PIO). A first
>test showed a buffer at 07B0B4400 ($open x login.com $read x y...
>$ANAL/SYS... SHOW PROC/RMS=3D(BDBSUM,PIO). If you open a relative fiel
>with bucket size of 60 or so, then you can make the system read 30KB
>of 'stuff' into p1 space.
>
>For a quick address overview: SDA> CLUE PROC/LAYOUT

>fwiw,
>Hein.

BTW, Hein, I've heard nothing more re my question concerning that macro
comment.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 11:05:49 AM
In article <d22b5510-adbc-494b-bc54-6bb124a9c2ae@f63g2000hsf.googlegroups.com>, FrankS <sapienza@noesys.com> writes:
>On Aug 15, 11:00=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> Does the 511 character recall buffer thing crash the system, the process
>> or just the application that was running at the time ?
>
>Sorry for the confusion, JF.  It simply generates an access violation
>in the process that was running at the time.  Not a system crash.  The
>process terminates and you're returned to DCL.

I've understood that from the posted process stack dumps.  



>However, given that the address where the access violation occurs can
>be predetermined, I at least can see that it is possible to exploit
>the problem as has been described already.

However, I can't replicate the process stack dumps based upon any of the
posted reproducer scenarios to date.



>For example, TCPIP is installed with CMKRNL.  If you do this with
>TCPIP as the application instead of MAIL then you can end up with a
>situation where an unprivileged user has free access to CMKRNL.

OK. 

FWIW, I tried with MAIL and left the process active all evening while I
was asleep.  This morning, it still had not stack dumped.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 11:18:18 AM
On Aug 15, 11:26=A0pm, Hein RMS van den Heuvel
<heinvandenheu...@gmail.com> wrote:
> Best I understand this, the hack needs any address which can be
> expressed with a series of ASCII expressable address mappings and
> survives image activation.

Correct.

I haven't played with it as much as the folks that have posted the
problem.  I'm guessing that if you spawn a subprocess and provide a SYS
$INPUT stream you might get around the issue regarding non-printable
characters that need to be used to express certain address ranges.

The procedures seems to be:
- The code which is to be run at elevated privileges (a.k.a.
shellcode, I think) needs to be loaded into memory which survives both
image rundown (from the application that is storing it in memory) as
well as image activation of the application which is installed with
elevated privileges (be it TCPIP, INSTALL, TELNET, or any other).

- You spawn a subprocess that will load the shellcode as well as
activate the privileged application.  You also feed the privileged
application the 511 + up-up-up + ASCII-expressed shellcode address.

- Another curious thing is that it appears the user account doing all
this must not have any privileges.  I've tried this on my system with
a non-privileged (TMPMBX,NETMBX only) account as well as one with all
privileges (like SYSTEM).  The privileged account doesn't generate the
access violation.
0
sapienza (410)
8/16/2008 11:21:41 AM
On Aug 16, 1:21 pm, FrankS <sapie...@noesys.com> wrote:
> On Aug 15, 11:26 pm, Hein RMS van den Heuvel
>
> <heinvandenheu...@gmail.com> wrote:
> > Best I understand this, the hack needs any address which can be
> > expressed with a series of ASCII expressable address mappings and
> > survives image activation.
>
> Correct.
>
> I haven't played with it as much as the folks that have posted the
> problem.  I'm guessing that if you spawn a subprocess and provide a SYS
> $INPUT stream you might get around the issue regarding non-printable
> characters that need to be used to express certain address ranges.

Or write your own SSH/TELNET client as mentioned previously ...
In that case you can fully control the return address.
Perhaps someone on the list figures this out and posts it
so that people like VAXman can belive it.

>
0
bugs6 (57)
8/16/2008 11:30:40 AM
On Aug 16, 7:18=A0am, VAXman-  @SendSpamHere.ORG wrote:
> FWIW, I tried with MAIL and left the process active all evening while I
> was asleep. =A0This morning, it still had not stack dumped.

By "wait patiently" I meant only seconds, not hours.  It may be that a
virgin v7.3-2 install doesn't have the bug (it might have been
introduced in a later patch), or you're trying it with a privileged
account, or something else is different about your environment .vs.
mine.

Nevertheless, it is reproducable.
0
sapienza (410)
8/16/2008 11:34:24 AM
In article <f11b5498-c3b3-4fa2-8283-350904cad131@k37g2000hsf.googlegroups.com>, FrankS <sapienza@noesys.com> writes:
>{...snip...}
>- You spawn a subprocess that will load the shellcode as well as
>activate the privileged application.  You also feed the privileged
>application the 511 + up-up-up + ASCII-expressed shellcode address.

OK.  Non-privied account.

$ SPAWN MAIL
MAIL> AAA(511 of them)AAA
Then 3 up-arrows
MAIL> @@@@

Which translates to %x40404040 in the lowest regions of P1.  I verified
using SDA that the page is NOT MAPPED.  I should have received an ACCVIO
at this address based upon your description of how to reproduce this.  I
do not.


>- Another curious thing is that it appears the user account doing all
>this must not have any privileges.  I've tried this on my system with
>a non-privileged (TMPMBX,NETMBX only) account as well as one with all
>privileges (like SYSTEM).  The privileged account doesn't generate the
>access violation.

I have been testing this all along using a non-privied account.  In fact,
its username is NOPRIV_USER (one of my development test accounts) and has
only NETMBX and TMPMBX (otherwise, there would be no SPAWNing).

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 11:51:57 AM
In article <47f42318-d79e-460d-97cf-fed1f5c9eb43@e39g2000hsf.googlegroups.com>, FrankS <sapienza@noesys.com> writes:
>On Aug 16, 7:18=A0am, VAXman-  @SendSpamHere.ORG wrote:
>> FWIW, I tried with MAIL and left the process active all evening while I
>> was asleep. =A0This morning, it still had not stack dumped.
>
>By "wait patiently" I meant only seconds, not hours.  It may be that a
>virgin v7.3-2 install doesn't have the bug (it might have been
>introduced in a later patch), or you're trying it with a privileged
>account, or something else is different about your environment .vs.
>mine.
>
>Nevertheless, it is reproducable.

Dave Jones sent me a private email with one of the details that has
been elided from this discussion.  I have now been able to get the
stack dump as previously professed.

Now to write my so-called "shellcode".

And then I will up update SecurityGuard to thwart such an attack, if
needed.  

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 1:34:14 PM
On Sat, 16 Aug 2008 04:34:24 -0700, FrankS <sapienza@noesys.com> wrote:

> On Aug 16, 7:18�am, VAXman-  @SendSpamHere.ORG wrote:
>> FWIW, I tried with MAIL and left the process active all evening while I
>> was asleep. �This morning, it still had not stack dumped.
>
> By "wait patiently" I meant only seconds, not hours.  It may be that a
> virgin v7.3-2 install doesn't have the bug (it might have been
> introduced in a later patch), or you're trying it with a privileged
> account, or something else is different about your environment .vs.
> mine.
>
> Nevertheless, it is reproducable.

How would you go about this on a remote machine to which you do not
have login priveleges?

-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/16/2008 2:29:15 PM
On Aug 16, 3:29=A0pm, "Tom Linden" <t...@kednos.company> wrote:
> On Sat, 16 Aug 2008 04:34:24 -0700, FrankS <sapie...@noesys.com> wrote:
> > On Aug 16, 7:18=A0am, VAXman- =A0@SendSpamHere.ORG wrote:
> >> FWIW, I tried with MAIL and left the process active all evening while =
I
> >> was asleep. =A0This morning, it still had not stack dumped.
>
> > By "wait patiently" I meant only seconds, not hours. =A0It may be that =
a
> > virgin v7.3-2 install doesn't have the bug (it might have been
> > introduced in a later patch), or you're trying it with a privileged
> > account, or something else is different about your environment .vs.
> > mine.
>
> > Nevertheless, it is reproducable.
>
> How would you go about this on a remote machine to which you do not
> have login priveleges?
>
> --
> PL/I for OpenVMSwww.kednos.com

You don't, it is a local priv escalation bug and you need an account
on the box to run the exploit from. How you get access to the box in
the first place is up to you.. But someone else posted a fingerd
overflow that shouldn't be too difficult to exploit, apparently there
is a patch out for it but people looking for bugs should have no
problem finding more 0day on their own...

We would also like to remind group as a whole that it is not too late
doubt the validity of our modest claims, call us liars, tell us to go
fuck ourselves, hint that the whole thing is a hoax, make outrageous
claims about OpenVMS superior security and paint yourself into a
corner and comment on matters you have absolute no idea about...

Does anyone still doubt the videos are real? Even more interesting
question is, does anyone think these are the only exploitable mem
corruption type bugs in OpenVMS? Then it REALLY is time to get the
head out of the sand and face reality...


PS.. We hope VAXman prepared one hell of a proof that he triggered the
vuln, because video, independent parties reproducing it and offers to
demonstrate it live publically just isn't enough! LOL!!!!!
0
bugs6 (57)
8/16/2008 3:24:23 PM
On Sat, 16 Aug 2008 08:24:23 -0700, <bugs@signedness.org> wrote:

> You don't, it is a local priv escalation bug and you need an account
> on the box to run the exploit from. How you get access to the box in
> the first place is up to you.. But someone else posted a fingerd
> overflow that shouldn't be too difficult to exploit, apparently there
> is a patch out for it but people looking for bugs should have no
> problem finding more 0day on their own...

Well I have always disabled fingerd whether on Unix or VMS, but there
may well be other avenues.  Such exploits would not be possible had the  
code
been written using a safe language like PL/I or Ada with apporpriate
ON conditions.

-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/16/2008 3:51:25 PM
In article <e9af8c0e-3e8b-4b83-888d-79f433cec07e@z66g2000hsc.googlegroups.com>, bugs@signedness.org writes:
>On Aug 15, 10:03 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> b...@signedness.org wrote:
>> > since the exploit take advantage of an error to take control of the
>> > execution flow.
>>
>> You mean you have discovered error handlers in VMS where you can
>> register a subroutine to execute when errors/access violations happen in
>> an executable program ?
>>
>> Those are fully documented. No exploit there.
>>
>> > Since the PC is controlled in the CLI bug we simply jump to the
>> > address of a logical that contains the
>> > shellcode that we want to run.
>>
>> How do you obtain the address of that logical ? This is pretty critical
>> to knowing if you can jump to it or not.
>>
>> > However, we did not bother
>> > to add a clean exit after the create process shellcode so the process
>> > crashes when FILE.EXE
>> > has been executed.
>>
>> You mean you don't know about the "exit(1);" statement in C ?
>We know about the exit() statement, but it is a little more to it
>to write it in assembly for OpenVMS so we did not spend any time
>to look up the system service index for it since the exploit works
>without
>a clean exit.
>
>>
>> > Please pick up some book on exploit development and think a little
>> > before doing statements
>> > about things that you obviously don't know anything about.
>>
>> For someone to find such an exploit, one would need a fair amount of VMS
>> experience. And since you use terminology that is completely foreign to
>> VMS, it is hard to understand how you could have enough experience with
>> VMS to find such an exploit.
>>
>> For instance, if Mr VAXman had found this exploit, he would have given
>> an explanation using terminology that is native to VMS because we know
>> he has a lot of experience with VMS.
>
>Well, knowing a whole lot about VMS is not the same thing as writing
>an exploit.
>We are pretty sure that VAXman knows a lot more about OpenVMS then we
>do.
>We just wrote some exploits for vulnerabilities that we found.
>
>This is how we trigger the CLI bug:
>
>1) Start a program using the command line interface library, like
>install
>2) At the prompt (INSTALL>), paste 511 characters and then press the
>    upp arrow key three times to move the history line pointer in
>memory
>3) The pointer now points to a address that will be jumped to, so go
>ahead
>    and manually write the return address, like pressing the 'b'
>character 4 times
>4) Wait
>5) If the machine is vulnerable you will get an access violation.

Thanks for the explanation. Unfortunately I don't seem to see any
access violation when following that procedure

 sh sys/noproc
OpenVMS V8.3  on node HELIUM  16-AUG-2008 16:36:23.54  Uptime  89 17:21:09

$ install
INSTALL> 12345678901234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
23456789012345678901234567890123456789012345678901234567890123456789012345678901
2345678901234567890123456789012345678901

press up-arrow key 3 times

type

INSTALL> bbbb
%CLI-W-IVVERB, unrecognized command verb - check validity and spelling
 \BBBB\
INSTALL>

I have tried all the variations I can think of

pressing return after inputting the 511 characters before pressing the up-arrows
pressing return after each b

none seems to make any difference.

Of course this isn't proof your procedure doesn't cause problems on some
systems but my Alpha VMS 8.3 home system doesn't seem to exhibit the problem.

David Webb
Security team leader
CCSS
Middlesex University
0
david20
8/16/2008 4:04:51 PM
In article <f11b5498-c3b3-4fa2-8283-350904cad131@k37g2000hsf.googlegroups.com>, FrankS <sapienza@noesys.com> writes:
>On Aug 15, 11:26=A0pm, Hein RMS van den Heuvel
><heinvandenheu...@gmail.com> wrote:
>> Best I understand this, the hack needs any address which can be
>> expressed with a series of ASCII expressable address mappings and
>> survives image activation.
>
>Correct.
>
>I haven't played with it as much as the folks that have posted the
>problem.  I'm guessing that if you spawn a subprocess and provide a SYS
>$INPUT stream you might get around the issue regarding non-printable
>characters that need to be used to express certain address ranges.
>
>The procedures seems to be:
>- The code which is to be run at elevated privileges (a.k.a.
>shellcode, I think) needs to be loaded into memory which survives both
>image rundown (from the application that is storing it in memory) as
>well as image activation of the application which is installed with
>elevated privileges (be it TCPIP, INSTALL, TELNET, or any other).
>
>- You spawn a subprocess that will load the shellcode as well as
>activate the privileged application.  You also feed the privileged
>application the 511 + up-up-up + ASCII-expressed shellcode address.
>
>- Another curious thing is that it appears the user account doing all
>this must not have any privileges.  I've tried this on my system with
>a non-privileged (TMPMBX,NETMBX only) account as well as one with all
>privileges (like SYSTEM).  The privileged account doesn't generate the
>access violation.

I've just retried it on my home VMS 8.3 alpha from a non-privileged
account and still can't reproduce it.

David Webb
Security team leader
CCSS
Middlesex University

0
david20
8/16/2008 4:28:46 PM
On Aug 16, 9:34 am, VAXman-  @SendSpamHere.ORG wrote:
[...]
> Dave Jones sent me a private email with one of the details that has
> been elided from this discussion.  I have now been able to get the
> stack dump as previously professed.
>
> Now to write my so-called "shellcode".
>
> And then I will up update SecurityGuard to thwart such an attack, if
> needed.

Thanks for that - I know that there is a problem, and I suspected that
we weren't being told the "whole story" until now.
0
8/16/2008 5:47:13 PM
In article <89fa21b2-3b42-41f1-9f53-604c38ce357b@d45g2000hsc.googlegroups.com>, bugs@signedness.org writes:
>On Aug 16, 3:29=A0pm, "Tom Linden" <t...@kednos.company> wrote:
>> On Sat, 16 Aug 2008 04:34:24 -0700, FrankS <sapie...@noesys.com> wrote:
>> > On Aug 16, 7:18=A0am, VAXman- =A0@SendSpamHere.ORG wrote:
>> >> FWIW, I tried with MAIL and left the process active all evening while =
>I
>> >> was asleep. =A0This morning, it still had not stack dumped.
>>
>> > By "wait patiently" I meant only seconds, not hours. =A0It may be that =
>a
>> > virgin v7.3-2 install doesn't have the bug (it might have been
>> > introduced in a later patch), or you're trying it with a privileged
>> > account, or something else is different about your environment .vs.
>> > mine.
>>
>> > Nevertheless, it is reproducable.
>>
>> How would you go about this on a remote machine to which you do not
>> have login priveleges?
>>
>> --
>> PL/I for OpenVMSwww.kednos.com
>
>You don't, it is a local priv escalation bug and you need an account
>on the box to run the exploit from. How you get access to the box in
>the first place is up to you.. But someone else posted a fingerd
>overflow that shouldn't be too difficult to exploit, apparently there
>is a patch out for it but people looking for bugs should have no
>problem finding more 0day on their own...
>
>We would also like to remind group as a whole that it is not too late
>doubt the validity of our modest claims, call us liars, tell us to go
>fuck ourselves, hint that the whole thing is a hoax, make outrageous
>claims about OpenVMS superior security and paint yourself into a
>corner and comment on matters you have absolute no idea about...
>
>Does anyone still doubt the videos are real? Even more interesting
>question is, does anyone think these are the only exploitable mem
>corruption type bugs in OpenVMS? Then it REALLY is time to get the
>head out of the sand and face reality...
>
>
>PS.. We hope VAXman prepared one hell of a proof that he triggered the
>vuln, because video, independent parties reproducing it and offers to
>demonstrate it live publically just isn't enough! LOL!!!!!

You can be an ass.  The whole spat here was derived from supplying only
PART of the instructions to reproduce the alluded to process stack dump.
As I stated in a prior post, Mr. Dave Jones emailed me with the elided
bit of non-trivial information you and your videos (I haven't seen them
as they don't play but others have and can't reproduce wither) fail to
point out.

I, and I'd wager Dave, would gladly discuss the missing bit with anyone
who cares to ask.  Oh, Hein too as I just emailed him because he was my
prior post.

FWIW, use of a logical name is going about it the hard way and it could
be made to fail for your scheme too. 

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 5:56:25 PM
In article <f5b398cb-6cab-4e7c-b929-5a81ae76e6f9@e53g2000hsa.googlegroups.com>, bradford.hamilton@gmail.com writes:
>On Aug 16, 9:34 am, VAXman-  @SendSpamHere.ORG wrote:
>[...]
>> Dave Jones sent me a private email with one of the details that has
>> been elided from this discussion.  I have now been able to get the
>> stack dump as previously professed.
>>
>> Now to write my so-called "shellcode".
>>
>> And then I will up update SecurityGuard to thwart such an attack, if
>> needed.
>
>Thanks for that - I know that there is a problem, and I suspected that
>we weren't being told the "whole story" until now.

Brad, 

If you do this, first issue:

$ SET TERMINAL/UNKNOWN

Without this, the terminal driver will interpret the ESCAPE sequences of
the UP-ARROW.  Setting the terminal type to UNKNOWN allows the ESCAPE to
pass through to the RMS $GET used in DCL to read from the process perm-
anent channel.  You should now see the process stack dump as reported.
Test with something like VMS MAIL.

MAIL> XXX...XXX(511st char->)X [UP][UP][UP]@@@@

You should see an ACCVIO exception reported with VA and PC = ^x40404040
(^x40 being @ character's ASCII in hex)


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/16/2008 6:21:14 PM
In article <00A7E333.CD792D87@SendSpamHere.ORG>, 
VAXman-  @SendSpamHere.ORG wrote:
>Brad, 
>
>If you do this, first issue:
>
>$ SET TERMINAL/UNKNOWN
>
>Without this, the terminal driver will interpret the ESCAPE sequences of
>the UP-ARROW.  Setting the terminal type to UNKNOWN allows the ESCAPE to
>pass through to the RMS $GET used in DCL to read from the process perm-
>anent channel.  You should now see the process stack dump as reported.
>Test with something like VMS MAIL.
>
>MAIL> XXX...XXX(511st char->)X [UP][UP][UP]@@@@
>
>You should see an ACCVIO exception reported with VA and PC = ^x40404040
>(^x40 being @ character's ASCII in hex)

Thanks, Brian - I had tried to reproduce the error on my V8.3 with SET
TERMINAL/EIGHTBIT (as it appeared in the video), but that didn't work.  I'll
try it again with SET TERMINAL/UNKNOWN in a few minutes.
[...]
0
BRAD77 (76)
8/16/2008 7:24:41 PM
In article <slrngaeabp.5qh.BRAD@rabbit.turquoisewitch.com>, Brad Hamilton wrote:
[...]
>Thanks, Brian - I had tried to reproduce the error on my V8.3 with SET
>TERMINAL/EIGHTBIT (as it appeared in the video), but that didn't work.  I'll
>try it again with SET TERMINAL/UNKNOWN in a few minutes.
>[...]

Well, now - I get:

$ set terminal/unknown
$ mail

MAIL>
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
ccccccccccccccccccccccccccccccccccccc
%CLI-W-IVVERB, unrecognized command verb - check validity and spelling

\CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCC

before I can even enter the three up-arrows...anyway, I'll take your word for
it that the vuln is reporduceable (and no, cmn, that does *not* mean that I am
diss'ing you by any means, it's just that your reputation - if you are indeed
cmn - worries me a little.  MITM-SSH and SAdoor don't exactly bring me the warm
and fuzzies.	:-)  I've met and talked to Brian on a number of occasions -
he's a good man to have a Guinness with, if you drink. 
0
BRAD77 (76)
8/16/2008 7:39:53 PM
On Aug 16, 7:56 pm, VAXman-  @SendSpamHere.ORG wrote:
> You can be an ass.

Well,  we are not the ones telling others to "fuck off", are we?
So who is the ass around here?

>
0
bugs6 (57)
8/16/2008 10:31:52 PM
JF Mezei wrote:
> bugs@signedness.org wrote:
> 
> 
>>You can check out wikipedia for information about the shellcode that
>>we refer to:
>>http://en.wikipedia.org/wiki/Shellcode
> 
> 
> Then you should have simply used "executable code" when speaking in
> comp.os.vms terms. Or even "compiled" code.
> 
> 
>>As stated earlier, we will not release the exploit to the public yet.
> 
> 
> I don't need the specific exploit. But since you came here, one would
> have expected you could be able to explain it in normal VMS terminology.
> 
> For instance, when use the term "logical", are you refering to a VMS
> logical name ? Was that logical name created by a program, or via DCL
> commands ? which logical name table, what attributes (user, super, exec,
> tranlstion=terminal or translation=concealed etc).
> 
> Lack of such specifics makes us wonder if you are even talking about a
> real logical name because your terminology is so out of wack with the
> VMS world so we have no idea if you know what a logical name is.
> 

As I understand it, the logical name is being used as a place to store
the payload of the exploit in process-permanent memory accessible to
the exploit.  Any user, with out any privileges at all, can create
an arbitrary process or job logical name with an arbitrary name and
value[1].  It maybe you could dispense with the logical name and use
the symbol directly, or maybe the logical name is easier to find in
memory, or you can call sys$trnlnm() to get its value in a known (to
the exploit) location.

The bug seems to be the ability to execute code from arbitrary locations
in memory while executing a privileged image, and not the specifics of
logical names, etc.

What I don't understand is do both the Finger bug and the 511-byte DCL
command bug induce the same vulnerability, or are they two different
things?

Also, I don't understand how you gain privileges by typing something
invalid to DCL.  Where are these privileges coming from?  If you already
have them while at the DCL prompt, then you don't need any exploit, just
type your nefarious commands directly.  As far as I know, no privileged
programs execute arbitrary DCL commands on your behalf.  (Or if they
have a command interface with a spawn command, they drop privs before
spawning your DCL subprocess.  ISTR there were a few bugs like this back
in VMS V1.x, but all were fixed in the late 1970's.)

Or do you start up a privilege program, interrupt it (ctrl/Y) to get
to DCL, then type something illegal that DCL barfs on, leaving you with
elevated privileges, before it decides your not going to CONTINUE and
executes image rundown on the privileged program.  (I thought they fixed
this long ago so that interrupting an image installed with privs immediately 
invokes image rundown, but that
appears not to be the case.)


> 
> 
> 
> 
>>We have informed HP about the problems (we did this about two months
>>ago
> 
> 
> No surprise there. You may need to publish the exploit in CERT, *and*
> then make a lot of noise in order to get HP's attention on this and get
> them to reluctantly assign resources to look into it.

There is a magic channel leading right to the correct people at HP for
security-related bugs, but I don't recall it off the top of my head.
It is *not* necessary to have a support contract or any other kind of
relationship with HP to feed things to it, but you might not get any
direct response if they don't need any additional information to
reproduce it.  The first indication you may get that they even received
your message might be the publication of an ECO to fix it, possibly
months later.  (If you have a support contract, they *should* send
you a copy of the fix in order to verify they've really fixed it,
before they publish the ECO.)

I'm sure that the channel has been publicized on comp.os.vms, and
a google search should reveal it[2].

> 
> 
>>Please don't tell us to "fuck off", it makes some of us belive that it
>>is
>>a good idea to post sensitive information to fd.
> 
> 
> I have no intention to tell you that. It is just that because of the
> foreign terminology you insist on using, it is very hard to understand
> that you know anything about VMS.
> 
> 
> 
> What I don't understand is how, after pressing the up arrow 3 times, VMS
> would magically branch to some memory address magically containing the
> contents of some logical name, and make that block of memory executable.
> 
> If, entering excess characters during an input operation would result in
> your excess characters overwriting executable memory locations, then
> this would be a serious issue with some linker option file that didn't
> properly declare executable memory as non-writable.
> 
> The whole concept of memory management in VMS makes it very hard to have
> it execute data memory, or write over executable memory.

Hard but not impossible, speaking as someone who has written programs that
construct subroutines on the fly from bits and pieces of code and then
calls them!  This was much easier to do on VAX then Alpha or Itanium, and
when porting to them I made it table-driven instead, which while slightly
slower, is *much* easier to maintain.  Also, the program was compute-bound
on a VAX-11/780, and was about twice as fast with generated code vs. table-
driven code, so it mattered.  On Alphas and Itaniums, it is I/O-bound, so
the theoretical savings using generated code aren't significant.  One could
still generate a file containing arbitrary source code in some language,
spawn a subprocess to compile and link it as a shareable image, then load
it into the main image with LIB$FIND_IMAGE_SYMBOL and call it, but the
overhead in doing that completely swamps any savings.  BTW,
LIB$FIND_IMAGE_SYMBOL would make a pretty good secondary loader of some
nasty payload, assuming you could 1st deposit the said image into an
accessible directory on the target system.  But I don't think you can
call LIB$FIND_IMAGE_SYMBOL from a privileged image unless the target
image is also installed as a known, shareable, protected image.  So maybe
as tertiary loader after you've used the exploit to install the payload.
But this is all irrelevant; once you've got your foot in the door, you
can do anything.



[1] Construct a string symbol in DCL with FOO<x>[0,8]=%X<hex value> and 
concatenate the FOO<x> symbols, then define the logical name as the value
of the symbol.  Reduction in number of steps left as an exercise for the
reader.

[2] Unless you are JF...  In his alternate universe, nothing seems to
work as it should! :-) :-)

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
0
john5 (550)
8/16/2008 11:16:55 PM
In article <00A7E333.CD792D87@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
>In article <f5b398cb-6cab-4e7c-b929-5a81ae76e6f9@e53g2000hsa.googlegroups.com>, bradford.hamilton@gmail.com writes:
>>On Aug 16, 9:34 am, VAXman-  @SendSpamHere.ORG wrote:
>>[...]
>>> Dave Jones sent me a private email with one of the details that has
>>> been elided from this discussion.  I have now been able to get the
>>> stack dump as previously professed.
>>>
>>> Now to write my so-called "shellcode".
>>>
>>> And then I will up update SecurityGuard to thwart such an attack, if
>>> needed.
>>
>>Thanks for that - I know that there is a problem, and I suspected that
>>we weren't being told the "whole story" until now.
>
>Brad, 
>
>If you do this, first issue:
>
>$ SET TERMINAL/UNKNOWN
>
>Without this, the terminal driver will interpret the ESCAPE sequences of
>the UP-ARROW.  Setting the terminal type to UNKNOWN allows the ESCAPE to
>pass through to the RMS $GET used in DCL to read from the process perm-
>anent channel.  You should now see the process stack dump as reported.
>Test with something like VMS MAIL.
>
>MAIL> XXX...XXX(511st char->)X [UP][UP][UP]@@@@
>
>You should see an ACCVIO exception reported with VA and PC = ^x40404040
>(^x40 being @ character's ASCII in hex)
>
Thanks for that important additional piece of information. I can now 
reproduce it on my Alpha VMS 8.3 home system.

David Webb
Security team leader
CCSS
Middlesex University



>
>-- 
>VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
>.... pejorative statements of opinion are entitled to constitutional protection
>no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
>Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
>of usenet _must_ include its contents in its entirety including this copyright
>notice, disclaimer and quotations.
0
david20
8/16/2008 11:34:11 PM
On 2008-08-16, John Santos <john@egh.com> wrote:
> What I don't understand is do both the Finger bug and the 511-byte DCL
> command bug induce the same vulnerability, or are they two different
> things?

From what it sounds like to me, no.

The finger bug involves code somewhere doing something like

    printf( Plan );

where Plan is an arbitrary string read from the .plan file. If it
contains things understood by printf (say, %d), printf will expect more
parameters to be passed. Since there aren't any, printf tries to fetch
the parameter using whatever random stuff happens to be on the stack,
causing a crash.

The command recall bug sounds like a garden-variety buffer overflow. A
certain size buffer is allocated in an automatic variable (on the stack)
and the bounds aren't checked when the command line is stored there.
Storing something larger than the buffer space allocated allows you to
munch other things on the stack, like the return address.

The difference being that the finger bug isn't corrupting the stack,
just pulling unexpected data from it. The command recall bug is
corrupting the stack.
-- 
roger ivie
rivie@ridgenet.net
0
rivie (670)
8/17/2008 12:22:36 AM
On Aug 17, 1:22=A0am, Roger Ivie <ri...@ridgenet.net> wrote:
> On 2008-08-16, John Santos <j...@egh.com> wrote:
>
> > What I don't understand is do both the Finger bug and the 511-byte DCL
> > command bug induce the same vulnerability, or are they two different
> > things?
>
> From what it sounds like to me, no.
>
> The finger bug involves code somewhere doing something like
>
> =A0 =A0 printf( Plan );
>
> where Plan is an arbitrary string read from the .plan file. If it
> contains things understood by printf (say, %d), printf will expect more
> parameters to be passed. Since there aren't any, printf tries to fetch
> the parameter using whatever random stuff happens to be on the stack,
> causing a crash.
>
> The command recall bug sounds like a garden-variety buffer overflow. A
> certain size buffer is allocated in an automatic variable (on the stack)
> and the bounds aren't checked when the command line is stored there.
> Storing something larger than the buffer space allocated allows you to
> munch other things on the stack, like the return address.
>
> The difference being that the finger bug isn't corrupting the stack,
> just pulling unexpected data from it. The command recall bug is
> corrupting the stack.
> --
> roger ivie
> ri...@ridgenet.net

You are wrong, writing to the stack is entirely possible (and oh yeah
we do have a working exploit for it too! :)) with a format string bug
vuln on most implementations including VMS. We have already
recommended a paper on format string vulnerabilities.  For more info
read http://linux.die.net/man/3/printf

And here is an example for you:-

$ type fmt.c
main()
{
        int i=3D0;
        printf("%.100d %n\n",1,&i);
        printf("wrote %i to \"i\" using nothing but printf!\n",i);
}

$ run fmt
000000000000000000000000000000000000000000000000000000000000000000000000000=
00000
00000000000000000001
wrote 101 to "i" using nothing but printf!


If we can place the address of a saved return address, function
pointer, deconstructor etc on the stack, we then can "pop" enough
values of values using things like %x until we reach our target write
address. Obviously at this point it is game over controling the PC
register..


The remote finger bug is an overflow too and therefore somewhat
similar to the cmdline bug but a different bug... The other local
finger bug is just plain stupid and not related to any of the other
bugs.


0
bugs6 (57)
8/17/2008 12:54:37 AM
On Aug 16, 2:21=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> If you do this, first issue:
>
> $ SET TERMINAL/UNKNOWN

That explains why I didn't see the problem when using a privileged
account.  It has nothing to do with privilege -- my privileged account
has a LOGIN.COM that issues a $SET TERM/INQ, whereas my unprivileged
account does not.  I tried it on the privileged account by logging in
with /NOCOMMAND and the stack dumps did happen.

I also logged in using /NOCOMMAND on the system which has all current
patches installed and reproduced it there as well.

0
sapienza (410)
8/17/2008 1:33:13 AM
In article <g87o5j$lb5$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:
>In article <00A7E333.CD792D87@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
>>In article <f5b398cb-6cab-4e7c-b929-5a81ae76e6f9@e53g2000hsa.googlegroups.com>, bradford.hamilton@gmail.com writes:
>>>On Aug 16, 9:34 am, VAXman-  @SendSpamHere.ORG wrote:
>>>[...]
>>>> Dave Jones sent me a private email with one of the details that has
>>>> been elided from this discussion.  I have now been able to get the
>>>> stack dump as previously professed.
>>>>
>>>> Now to write my so-called "shellcode".
>>>>
>>>> And then I will up update SecurityGuard to thwart such an attack, if
>>>> needed.
>>>
>>>Thanks for that - I know that there is a problem, and I suspected that
>>>we weren't being told the "whole story" until now.
>>
>>Brad, 
>>
>>If you do this, first issue:
>>
>>$ SET TERMINAL/UNKNOWN
>>
>>Without this, the terminal driver will interpret the ESCAPE sequences of
>>the UP-ARROW.  Setting the terminal type to UNKNOWN allows the ESCAPE to
>>pass through to the RMS $GET used in DCL to read from the process perm-
>>anent channel.  You should now see the process stack dump as reported.
>>Test with something like VMS MAIL.
>>
>>MAIL> XXX...XXX(511st char->)X [UP][UP][UP]@@@@
>>
>>You should see an ACCVIO exception reported with VA and PC = ^x40404040
>>(^x40 being @ character's ASCII in hex)
>>
>Thanks for that important additional piece of information. I can now 
>reproduce it on my Alpha VMS 8.3 home system.

Save that after further investigation, it's not DCL... it's in a shareable
image.  The shareable and code has been identified.

Too many things happening my other life today to report on this sooner.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/17/2008 3:19:23 AM
On Aug 16, 8:22=A0pm, Roger Ivie <ri...@ridgenet.net> wrote:
> On 2008-08-16, John Santos <j...@egh.com> wrote:
>
> > What I don't understand is do both the Finger bug and the 511-byte DCL
> > command bug induce the same vulnerability, or are they two different
> > things?

2 unrelated problems

Minor details...

>> and the 511-byte DCL command bug ...

Nit picking... It is not DCL bug, but a problem a common input /
parsing routine can run into.

> The command recall bug sounds like a garden-variety buffer overflow.

Nit picking... It is not a command recall bug.
That's just one way of starting an escape sequence at an
'inconvenient' point in time.
A simple <escape> as byte 512 followed by random text can do the same.

fwiw... by pasting in just the right random text, even without a
special telnet, I can make it look at an RMS buffer which in turn I
can load with 30+ kb of arbitrary data/instructions.

Hein.
0
8/17/2008 6:23:35 AM
bugs@signedness.org wrote:
> Well,  we are not the ones telling others to "fuck off", are we?
> So who is the ass around here?

I don"t recall anyone telling you to fuck off. You came to a VMS
newsgroup, announced some vulnerability that you could not explain in
VMS terms. It is like you talking chinese to an american. You insisted
in using terms like "shellcode" even after people told you they didn't
understand what that meant. Then you proceed to use the word "logical",
and people wonder if this is the "VMS" logical name, or the "chinese
language" logical so we have no way to understand what you said.


If you had said:

if you enter 511 bytes, add a couple of escape sequenmces (like 3
uparrows) followed by 4 bytes, then the application will branch to the
address indicated by those 4 bytes, this would have been understood very
quickly by everyone, even if they couldn't reproduce it.

Your own binary code is irrelevant here. People here would understand
that if you can specify an address to branch, you could get the program
to branch to your own code.
0
8/17/2008 9:43:26 AM
Hein RMS van den Heuvel wrote:

> Nit picking... It is not DCL bug, but a problem a common input /
> parsing routine can run into.

I had been told that to use command recall in a utility, one needs to
use SMG. Would this be an SMG problem ?


Also, I am curious as to the role of the up-arrows in this vulnerability.

With SET TERM/UNKNOWN, it would mean that the <esc> [ A gets added to
the input buffer as any other character, right ?

Would there be any significance of having those specific characters
instead of any other 3 characters being sent ?

for instance, instead of pressing UP 3 times, what about typing ABC 3
times ? (same number of bytes being addded to the input buffer).
0
8/17/2008 9:51:10 AM
In article <9994beaf-67aa-4ba7-9b77-e8614bd52813@k30g2000hse.googlegroups.com>, bugs@signedness.org writes:
>On Aug 17, 1:22=A0am, Roger Ivie <ri...@ridgenet.net> wrote:
>> On 2008-08-16, John Santos <j...@egh.com> wrote:
>>
>> > What I don't understand is do both the Finger bug and the 511-byte DCL
>> > command bug induce the same vulnerability, or are they two different
>> > things?
>>
>> From what it sounds like to me, no.
>>
>> The finger bug involves code somewhere doing something like
>>
>> =A0 =A0 printf( Plan );
>>
>> where Plan is an arbitrary string read from the .plan file. If it
>> contains things understood by printf (say, %d), printf will expect more
>> parameters to be passed. Since there aren't any, printf tries to fetch
>> the parameter using whatever random stuff happens to be on the stack,
>> causing a crash.
>>
>> The command recall bug sounds like a garden-variety buffer overflow. A
>> certain size buffer is allocated in an automatic variable (on the stack)
>> and the bounds aren't checked when the command line is stored there.
>> Storing something larger than the buffer space allocated allows you to
>> munch other things on the stack, like the return address.
>>
>> The difference being that the finger bug isn't corrupting the stack,
>> just pulling unexpected data from it. The command recall bug is
>> corrupting the stack.
>> --
>> roger ivie
>> ri...@ridgenet.net
>
>You are wrong, writing to the stack is entirely possible (and oh yeah
>we do have a working exploit for it too! :)) with a format string bug
>vuln on most implementations including VMS. We have already
>recommended a paper on format string vulnerabilities.  For more info
>read http://linux.die.net/man/3/printf
>
>And here is an example for you:-
>
>$ type fmt.c
>main()
>{
>        int i=3D0;
>        printf("%.100d %n\n",1,&i);
>        printf("wrote %i to \"i\" using nothing but printf!\n",i);
>}
>
>$ run fmt
>000000000000000000000000000000000000000000000000000000000000000000000000000=
>00000
>00000000000000000001
>wrote 101 to "i" using nothing but printf!
>
>
>If we can place the address of a saved return address, function
>pointer, deconstructor etc on the stack, we then can "pop" enough
>values of values using things like %x until we reach our target write
>address. Obviously at this point it is game over controling the PC
>register..
>
>
>The remote finger bug is an overflow too and therefore somewhat
>similar to the cmdline bug but a different bug... The other local
>finger bug is just plain stupid and not related to any of the other
>bugs.
>
I still don't see where the privilege escalation with this finger client bug
comes from. Yes it's bad code but the finger client is not usually installed
with any privileges it is just running with the user's privileges.


The other bug though can be exercised within images such as Install which are
installed with privileges ie

INSTALL> list/full sys$system:install.exe

DISK$ALPHASYS:<SYS0.SYSCOMMON.SYSEXE>.EXE
   INSTALL;1        Open              Prv
        Entry access count         = 462
        Current / Maximum shared   = 3 / 2
        Privileges = CMKRNL PRMGBL SYSGBL SHMEM AUDIT
        Authorized = CMKRNL PRMGBL SYSGBL SHMEM AUDIT


and are able to be run by anyone on the system.

(Can anyone think of any reason why sys$system:install.exe should be set to 
w:re ? )

David Webb
Security team leader
CCSS
Middlesex University


>
0
david20
8/17/2008 10:09:52 AM
In article <48a7f577$0$1837$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Hein RMS van den Heuvel wrote:
>
>> Nit picking... It is not DCL bug, but a problem a common input /
>> parsing routine can run into.
>
>I had been told that to use command recall in a utility, one needs to
>use SMG. Would this be an SMG problem ?
>
>
>Also, I am curious as to the role of the up-arrows in this vulnerability.
>
>With SET TERM/UNKNOWN, it would mean that the <esc> [ A gets added to
>the input buffer as any other character, right ?
>
>Would there be any significance of having those specific characters
>instead of any other 3 characters being sent ?
>
>for instance, instead of pressing UP 3 times, what about typing ABC 3
>times ? (same number of bytes being addded to the input buffer).
If you just add in characters like ABC then the system tries to echo them to
the screen and , at least in install, errors with
%CLI-W-IVVERB, unrecognized command verb - check validity and spelling

However other non-printing characters eg all the other arrow keys seem to
work the same way UP works (as do FIND and SELECT - I haven't tried any
others).

David Webb
Security team leader
CCSS
Middlesex University




0
david20
8/17/2008 10:29:02 AM
On Aug 17, 11:43 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> b...@signedness.org wrote:
> > Well,  we are not the ones telling others to "fuck off", are we?
> > So who is the ass around here?
>
> I don"t recall anyone telling you to fuck off.

Perhaps you have not read the whole thread:

On Aug 15, 9:24 pm, VAXman-  @SendSpamHere.ORG wrote:
[...]
> Yeah, I know nothing about VMS.  Please, oh great one, teach me your
> weirding way.
>
> Fuck off!
[...]

Does that refresh your memory?
Seems kind of hostile if you ask me.
We expect an apology for this.

> You came to a VMS
> newsgroup, announced some vulnerability that you could not explain in
> VMS terms.
No, we came to an VMS group that already discussed the vulnerabilities
that we found and claimed that they were lies and a hoax.
So we provided you with videos of working PoC exploits to clarify that
this
for sure was a real thing. Unfortunately that did not help.

We are sorry that we assumed that you guys
knew what shellcode was, it is a common used description in SECURITY
which obviously is not an area that you are interested of.
It is laughable that there are still people working with security
in IT that does not know what shellcode is.
That imply that someone have buried is head in
sand for the past 15 years.

> It is like you talking chinese to an american. You insisted
> in using terms like "shellcode" even after people told you they didn't
> understand what that meant.
There was attempts to try to clarify this, for example by Simon
Clubley:

On Aug 15, 8:14 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
(Simon Clubley) wrote:
> I think that Brian may be thinking that shellcode is a series of DCL
> commands instead of machine code. I think it's already been pointed
> out on this thread already what the definition of shellcode is in the
> context that you are using it, but Wikipedia has a writeup in case
> Brian missed the earlier message:
>
>        http://en.wikipedia.org/wiki/Shellcode

But people are obviously to stubborn
to even attempt to understand or even try to look it up
(google for shellcode +security would have been enough for anyone).
[...]

> If you had said:
>
> if you enter 511 bytes, add a couple of escape sequenmces (like 3
> uparrows) followed by 4 bytes, then the application will branch to the
> address indicated by those 4 bytes, this would have been understood very
> quickly by everyone, even if they couldn't reproduce it.
LOL
That is exactly what we did, except that we used "address to jump to"
and
"return address" instead of "followed by four bytes". I'm not even
going
to quote that post.

But that was obviously not clear enough, since we are not VMS-people,
and theirfore can not be fully trusted:

On Aug 15, 9:24 pm, VAXman-  @SendSpamHere.ORG wrote:
[...]
> Send me your so called "shellcode" and FILE.EXE then along with some
> instuctions other than typing 511 characters and 3 up-arrows.
[...]

VAXman did not even bother to watch the videos, he continued to
mess with DCL even though we nicely pointed out that the bug
was located elsewhere. He also did not listen to us when we explained
why FILE.EXE is used.

> Your own binary code is irrelevant here. People here would understand
> that if you can specify an address to branch, you could get the program
> to branch to your own code.

It is not irrelevant when trying to describe what the exploit actually
does,
obviously there are people that have a great trouble understanding the
basics of the exploit since questions with trivial answers has been
repeated
all over the thread.

With trivial we mean questions that could easily have been looked up
using
for example google. But that of course, requires a will to learn and
understand
new things, and that is probably not the main issue for some of you
here.

We are NOT VMS people, and we have never claimed to be that either.
In fact, we know very little about the system itself, we find
vulnerabilities and write PoC code to proof that the vulnerabilities
exist.

The reason for this is to make the digital world a little safer for
everybody.
Obviously that is not what everybody wants. Instead of taking a piss
on
people trying to secure your system you should perhaps be a bit humble
and TRY to understand so that problems can be solved.
Telling people to "fuck off" and call them liars is not the way to go
when they actually try to HELP you SECURE YOUR SYSTEM.
0
bugs6 (57)
8/17/2008 10:38:31 AM
In article <g88tdg$t4$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:
>In article <9994beaf-67aa-4ba7-9b77-e8614bd52813@k30g2000hse.googlegroups.com>, bugs@signedness.org writes:
>>On Aug 17, 1:22=A0am, Roger Ivie <ri...@ridgenet.net> wrote:
>>> On 2008-08-16, John Santos <j...@egh.com> wrote:
>>>
>>> > What I don't understand is do both the Finger bug and the 511-byte DCL
>>> > command bug induce the same vulnerability, or are they two different
>>> > things?
>>>
>>> From what it sounds like to me, no.
>>>
>>> The finger bug involves code somewhere doing something like
>>>
>>> =A0 =A0 printf( Plan );
>>>
>>> where Plan is an arbitrary string read from the .plan file. If it
>>> contains things understood by printf (say, %d), printf will expect more
>>> parameters to be passed. Since there aren't any, printf tries to fetch
>>> the parameter using whatever random stuff happens to be on the stack,
>>> causing a crash.
>>>
>>> The command recall bug sounds like a garden-variety buffer overflow. A
>>> certain size buffer is allocated in an automatic variable (on the stack)
>>> and the bounds aren't checked when the command line is stored there.
>>> Storing something larger than the buffer space allocated allows you to
>>> munch other things on the stack, like the return address.
>>>
>>> The difference being that the finger bug isn't corrupting the stack,
>>> just pulling unexpected data from it. The command recall bug is
>>> corrupting the stack.
>>> --
>>> roger ivie
>>> ri...@ridgenet.net
>>
>>You are wrong, writing to the stack is entirely possible (and oh yeah
>>we do have a working exploit for it too! :)) with a format string bug
>>vuln on most implementations including VMS. We have already
>>recommended a paper on format string vulnerabilities.  For more info
>>read http://linux.die.net/man/3/printf
>>
>>And here is an example for you:-
>>
>>$ type fmt.c
>>main()
>>{
>>        int i=3D0;
>>        printf("%.100d %n\n",1,&i);
>>        printf("wrote %i to \"i\" using nothing but printf!\n",i);
>>}
>>
>>$ run fmt
>>000000000000000000000000000000000000000000000000000000000000000000000000000=
>>00000
>>00000000000000000001
>>wrote 101 to "i" using nothing but printf!
>>
>>
>>If we can place the address of a saved return address, function
>>pointer, deconstructor etc on the stack, we then can "pop" enough
>>values of values using things like %x until we reach our target write
>>address. Obviously at this point it is game over controling the PC
>>register..
>>
>>
>>The remote finger bug is an overflow too and therefore somewhat
>>similar to the cmdline bug but a different bug... The other local
>>finger bug is just plain stupid and not related to any of the other
>>bugs.
>>
>I still don't see where the privilege escalation with this finger client bug
>comes from. Yes it's bad code but the finger client is not usually installed
>with any privileges it is just running with the user's privileges.
>
>
>The other bug though can be exercised within images such as Install which are
>installed with privileges ie
>
>INSTALL> list/full sys$system:install.exe
>
>DISK$ALPHASYS:<SYS0.SYSCOMMON.SYSEXE>.EXE
>   INSTALL;1        Open              Prv
>        Entry access count         = 462
>        Current / Maximum shared   = 3 / 2
>        Privileges = CMKRNL PRMGBL SYSGBL SHMEM AUDIT
>        Authorized = CMKRNL PRMGBL SYSGBL SHMEM AUDIT
>
>
>and are able to be run by anyone on the system.
>
>(Can anyone think of any reason why sys$system:install.exe should be set to 
>w:re ? )
>
Note.

This bug doesn't effect all images with embedded commandline commands for
instance SYSGEN seems to have been written to cope with it

$ mcr sysgen
SYSGEN> 
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
45678901234567890123456789012345678901234567890123456789012345678901234567890
%RMS-W-TNS, terminator not seen


It doesn't allow you to enter a long enough string and trying with the maximum
string it will allow + UP gives

$ mcr sysgen
SYSGEN> 
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
1234567890123456789012345678901234567890123456789012345678901234567890123456$
%SYSGEN-E-SYNTAX, syntax error:
'123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
0123456789012345678901231234567890123456789012345678901234567890123456789012345678901234567890123456'
SYSGEN>

Other images such as Authorize or SYSMAN won't allow you to run them without
having some privileges.

$ mcr sysman
%SYSMAN-F-NOOPER, SYSMAN requires OPER privilege
$
$ mcr authorize
%UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT)
-RMS-E-PRV, insufficient privilege or file protection violation


David Webb
Security team leader
CCSS
Middlesex University
0
david20
8/17/2008 10:46:21 AM
In article <de856455-c585-481d-bdba-929b3baba05b@k30g2000hse.googlegroups.com>, bugs@signedness.org writes:
>On Aug 17, 11:43 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> b...@signedness.org wrote:
>> > Well,  we are not the ones telling others to "fuck off", are we?
>> > So who is the ass around here?
>>
>> I don"t recall anyone telling you to fuck off.
>
>Perhaps you have not read the whole thread:
>
>On Aug 15, 9:24 pm, VAXman-  @SendSpamHere.ORG wrote:
>[...]
>> Yeah, I know nothing about VMS.  Please, oh great one, teach me your
>> weirding way.
>>
>> Fuck off!
>[...]
>
>Does that refresh your memory?
>Seems kind of hostile if you ask me.
>We expect an apology for this.
>
>> You came to a VMS
>> newsgroup, announced some vulnerability that you could not explain in
>> VMS terms.
>No, we came to an VMS group that already discussed the vulnerabilities
>that we found and claimed that they were lies and a hoax.
>So we provided you with videos of working PoC exploits to clarify that
>this
>for sure was a real thing. Unfortunately that did not help.
>
>We are sorry that we assumed that you guys
>knew what shellcode was, it is a common used description in SECURITY
>which obviously is not an area that you are interested of.
>It is laughable that there are still people working with security
>in IT that does not know what shellcode is.
>That imply that someone have buried is head in
>sand for the past 15 years.
>
This is NOT a security group. You have been receiving responses from both
people who know security terminology and people who don't.

David Webb
Security team leader
CCSS
Middlesex University





>> It is like you talking chinese to an american. You insisted
>> in using terms like "shellcode" even after people told you they didn't
>> understand what that meant.
>There was attempts to try to clarify this, for example by Simon
>Clubley:
>
>On Aug 15, 8:14 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
>(Simon Clubley) wrote:
>> I think that Brian may be thinking that shellcode is a series of DCL
>> commands instead of machine code. I think it's already been pointed
>> out on this thread already what the definition of shellcode is in the
>> context that you are using it, but Wikipedia has a writeup in case
>> Brian missed the earlier message:
>>
>>        http://en.wikipedia.org/wiki/Shellcode
>
>But people are obviously to stubborn
>to even attempt to understand or even try to look it up
>(google for shellcode +security would have been enough for anyone).
>[...]
>
>> If you had said:
>>
>> if you enter 511 bytes, add a couple of escape sequenmces (like 3
>> uparrows) followed by 4 bytes, then the application will branch to the
>> address indicated by those 4 bytes, this would have been understood very
>> quickly by everyone, even if they couldn't reproduce it.
>LOL
>That is exactly what we did, except that we used "address to jump to"
>and
>"return address" instead of "followed by four bytes". I'm not even
>going
>to quote that post.
>
>But that was obviously not clear enough, since we are not VMS-people,
>and theirfore can not be fully trusted:
>
>On Aug 15, 9:24 pm, VAXman-  @SendSpamHere.ORG wrote:
>[...]
>> Send me your so called "shellcode" and FILE.EXE then along with some
>> instuctions other than typing 511 characters and 3 up-arrows.
>[...]
>
>VAXman did not even bother to watch the videos, he continued to
>mess with DCL even though we nicely pointed out that the bug
>was located elsewhere. He also did not listen to us when we explained
>why FILE.EXE is used.
>
>> Your own binary code is irrelevant here. People here would understand
>> that if you can specify an address to branch, you could get the program
>> to branch to your own code.
>
>It is not irrelevant when trying to describe what the exploit actually
>does,
>obviously there are people that have a great trouble understanding the
>basics of the exploit since questions with trivial answers has been
>repeated
>all over the thread.
>
>With trivial we mean questions that could easily have been looked up
>using
>for example google. But that of course, requires a will to learn and
>understand
>new things, and that is probably not the main issue for some of you
>here.
>
>We are NOT VMS people, and we have never claimed to be that either.
>In fact, we know very little about the system itself, we find
>vulnerabilities and write PoC code to proof that the vulnerabilities
>exist.
>
>The reason for this is to make the digital world a little safer for
>everybody.
>Obviously that is not what everybody wants. Instead of taking a piss
>on
>people trying to secure your system you should perhaps be a bit humble
>and TRY to understand so that problems can be solved.
>Telling people to "fuck off" and call them liars is not the way to go
>when they actually try to HELP you SECURE YOUR SYSTEM.
0
david20
8/17/2008 10:54:16 AM
In article <g88vht$1b1$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:
>In article <g88tdg$t4$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:
>>In article <9994beaf-67aa-4ba7-9b77-e8614bd52813@k30g2000hse.googlegroups.com>, bugs@signedness.org writes:
>>>On Aug 17, 1:22=A0am, Roger Ivie <ri...@ridgenet.net> wrote:
>>>> On 2008-08-16, John Santos <j...@egh.com> wrote:
>>>>
>>>> > What I don't understand is do both the Finger bug and the 511-byte DCL
>>>> > command bug induce the same vulnerability, or are they two different
>>>> > things?
>>>>
>>>> From what it sounds like to me, no.
>>>>
>>>> The finger bug involves code somewhere doing something like
>>>>
>>>> =A0 =A0 printf( Plan );
>>>>
>>>> where Plan is an arbitrary string read from the .plan file. If it
>>>> contains things understood by printf (say, %d), printf will expect more
>>>> parameters to be passed. Since there aren't any, printf tries to fetch
>>>> the parameter using whatever random stuff happens to be on the stack,
>>>> causing a crash.
>>>>
>>>> The command recall bug sounds like a garden-variety buffer overflow. A
>>>> certain size buffer is allocated in an automatic variable (on the stack)
>>>> and the bounds aren't checked when the command line is stored there.
>>>> Storing something larger than the buffer space allocated allows you to
>>>> munch other things on the stack, like the return address.
>>>>
>>>> The difference being that the finger bug isn't corrupting the stack,
>>>> just pulling unexpected data from it. The command recall bug is
>>>> corrupting the stack.
>>>> --
>>>> roger ivie
>>>> ri...@ridgenet.net
>>>
>>>You are wrong, writing to the stack is entirely possible (and oh yeah
>>>we do have a working exploit for it too! :)) with a format string bug
>>>vuln on most implementations including VMS. We have already
>>>recommended a paper on format string vulnerabilities.  For more info
>>>read http://linux.die.net/man/3/printf
>>>
>>>And here is an example for you:-
>>>
>>>$ type fmt.c
>>>main()
>>>{
>>>        int i=3D0;
>>>        printf("%.100d %n\n",1,&i);
>>>        printf("wrote %i to \"i\" using nothing but printf!\n",i);
>>>}
>>>
>>>$ run fmt
>>>000000000000000000000000000000000000000000000000000000000000000000000000000=
>>>00000
>>>00000000000000000001
>>>wrote 101 to "i" using nothing but printf!
>>>
>>>
>>>If we can place the address of a saved return address, function
>>>pointer, deconstructor etc on the stack, we then can "pop" enough
>>>values of values using things like %x until we reach our target write
>>>address. Obviously at this point it is game over controling the PC
>>>register..
>>>
>>>
>>>The remote finger bug is an overflow too and therefore somewhat
>>>similar to the cmdline bug but a different bug... The other local
>>>finger bug is just plain stupid and not related to any of the other
>>>bugs.
>>>
>>I still don't see where the privilege escalation with this finger client bug
>>comes from. Yes it's bad code but the finger client is not usually installed
>>with any privileges it is just running with the user's privileges.
>>
>>
>>The other bug though can be exercised within images such as Install which are
>>installed with privileges ie
>>
>>INSTALL> list/full sys$system:install.exe
>>
>>DISK$ALPHASYS:<SYS0.SYSCOMMON.SYSEXE>.EXE
>>   INSTALL;1        Open              Prv
>>        Entry access count         = 462
>>        Current / Maximum shared   = 3 / 2
>>        Privileges = CMKRNL PRMGBL SYSGBL SHMEM AUDIT
>>        Authorized = CMKRNL PRMGBL SYSGBL SHMEM AUDIT
>>
>>
>>and are able to be run by anyone on the system.
>>
>>(Can anyone think of any reason why sys$system:install.exe should be set to 
>>w:re ? )
>>
>Note.
>
>This bug doesn't effect all images with embedded commandline commands for
>instance SYSGEN seems to have been written to cope with it
>
>$ mcr sysgen
>SYSGEN> 
>123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
>45678901234567890123456789012345678901234567890123456789012345678901234567890
>%RMS-W-TNS, terminator not seen
>
>
>It doesn't allow you to enter a long enough string and trying with the maximum
>string it will allow + UP gives
>
>$ mcr sysgen
>SYSGEN> 
>123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
>1234567890123456789012345678901234567890123456789012345678901234567890123456$
>%SYSGEN-E-SYNTAX, syntax error:
>'123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
>0123456789012345678901231234567890123456789012345678901234567890123456789012345678901234567890123456'
>SYSGEN>
>
>Other images such as Authorize or SYSMAN won't allow you to run them without
>having some privileges.
>
>$ mcr sysman
>%SYSMAN-F-NOOPER, SYSMAN requires OPER privilege
>$
>$ mcr authorize
>%UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT)
>-RMS-E-PRV, insufficient privilege or file protection violation
>
Clarification to the last - this assumes you have setup a SYSUAF logical.

David Webb
Security team leader
CCSS
Middlesex University
0
david20
8/17/2008 10:56:01 AM
david20@alpha2.mdx.ac.uk wrote:
> [...snip...]
> This bug doesn't effect all images with embedded commandline commands for
> instance SYSGEN seems to have been written to cope with it
> 
> $ mcr sysgen
> SYSGEN> 
> 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
> 45678901234567890123456789012345678901234567890123456789012345678901234567890
> %RMS-W-TNS, terminator not seen
> 
> 
> It doesn't allow you to enter a long enough string and trying with the maximum
> string it will allow + UP gives
> 
> $ mcr sysgen
> SYSGEN> 
> 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
> 1234567890123456789012345678901234567890123456789012345678901234567890123456$
> %SYSGEN-E-SYNTAX, syntax error:
> '123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
> 0123456789012345678901231234567890123456789012345678901234567890123456789012345678901234567890123456'
> SYSGEN>
> 
> Other images such as Authorize or SYSMAN won't allow you to run them without
> having some privileges.
> 
> $ mcr sysman
> %SYSMAN-F-NOOPER, SYSMAN requires OPER privilege
> $
> $ mcr authorize
> %UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT)
> -RMS-E-PRV, insufficient privilege or file protection violation

In my tests, the common factor seems to be any program linked against
SMGSHR, so it's looking like JF was correct.

And the fact that it *is* in this single shared image (if above is
indeed correct), should make fixing the problem much easier.

I'm going to grab the source for SMGSHR tomorrow and have a good look.
0
Roy.Omond (380)
8/17/2008 11:40:43 AM
On Aug 17, 11:54=A0am, davi...@alpha2.mdx.ac.uk wrote:
> In article <de856455-c585-481d-bdba-929b3baba...@k30g2000hse.googlegroups=
..com>, b...@signedness.org writes:
>
>
>
> >On Aug 17, 11:43 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> >> b...@signedness.org wrote:
> >> > Well, =A0we are not the ones telling others to "fuck off", are we?
> >> > So who is the ass around here?
>
> >> I don"t recall anyone telling you to fuck off.
>
> >Perhaps you have not read the whole thread:
>
> >On Aug 15, 9:24 pm, VAXman- =A0@SendSpamHere.ORG wrote:
> >[...]
> >> Yeah, I know nothing about VMS. =A0Please, oh great one, teach me your
> >> weirding way.
>
> >> Fuck off!
> >[...]
>
> >Does that refresh your memory?
> >Seems kind of hostile if you ask me.
> >We expect an apology for this.
>
> >> You came to a VMS
> >> newsgroup, announced some vulnerability that you could not explain in
> >> VMS terms.
> >No, we came to an VMS group that already discussed the vulnerabilities
> >that we found and claimed that they were lies and a hoax.
> >So we provided you with videos of working PoC exploits to clarify that
> >this
> >for sure was a real thing. Unfortunately that did not help.
>
> >We are sorry that we assumed that you guys
> >knew what shellcode was, it is a common used description in SECURITY
> >which obviously is not an area that you are interested of.
> >It is laughable that there are still people working with security
> >in IT that does not know what shellcode is.
> >That imply that someone have buried is head in
> >sand for the past 15 years.
>
> This is NOT a security group. You have been receiving responses from both
> people who know security terminology and people who don't.
>
> David Webb
> Security team leader
> CCSS
> Middlesex University
>
>
>
> >> It is like you talking chinese to an american. You insisted
> >> in using terms like "shellcode" even after people told you they didn't
> >> understand what that meant.
> >There was attempts to try to clarify this, for example by Simon
> >Clubley:
>
> >On Aug 15, 8:14 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
> >(Simon Clubley) wrote:
> >> I think that Brian may be thinking that shellcode is a series of DCL
> >> commands instead of machine code. I think it's already been pointed
> >> out on this thread already what the definition of shellcode is in the
> >> context that you are using it, but Wikipedia has a writeup in case
> >> Brian missed the earlier message:
>
> >> =A0 =A0 =A0 =A0http://en.wikipedia.org/wiki/Shellcode
>
> >But people are obviously to stubborn
> >to even attempt to understand or even try to look it up
> >(google for shellcode +security would have been enough for anyone).
> >[...]
>
> >> If you had said:
>
> >> if you enter 511 bytes, add a couple of escape sequenmces (like 3
> >> uparrows) followed by 4 bytes, then the application will branch to the
> >> address indicated by those 4 bytes, this would have been understood ve=
ry
> >> quickly by everyone, even if they couldn't reproduce it.
> >LOL
> >That is exactly what we did, except that we used "address to jump to"
> >and
> >"return address" instead of "followed by four bytes". I'm not even
> >going
> >to quote that post.
>
> >But that was obviously not clear enough, since we are not VMS-people,
> >and theirfore can not be fully trusted:
>
> >On Aug 15, 9:24 pm, VAXman- =A0@SendSpamHere.ORG wrote:
> >[...]
> >> Send me your so called "shellcode" and FILE.EXE then along with some
> >> instuctions other than typing 511 characters and 3 up-arrows.
> >[...]
>
> >VAXman did not even bother to watch the videos, he continued to
> >mess with DCL even though we nicely pointed out that the bug
> >was located elsewhere. He also did not listen to us when we explained
> >why FILE.EXE is used.
>
> >> Your own binary code is irrelevant here. People here would understand
> >> that if you can specify an address to branch, you could get the progra=
m
> >> to branch to your own code.
>
> >It is not irrelevant when trying to describe what the exploit actually
> >does,
> >obviously there are people that have a great trouble understanding the
> >basics of the exploit since questions with trivial answers has been
> >repeated
> >all over the thread.
>
> >With trivial we mean questions that could easily have been looked up
> >using
> >for example google. But that of course, requires a will to learn and
> >understand
> >new things, and that is probably not the main issue for some of you
> >here.
>
> >We are NOT VMS people, and we have never claimed to be that either.
> >In fact, we know very little about the system itself, we find
> >vulnerabilities and write PoC code to proof that the vulnerabilities
> >exist.
>
> >The reason for this is to make the digital world a little safer for
> >everybody.
> >Obviously that is not what everybody wants. Instead of taking a piss
> >on
> >people trying to secure your system you should perhaps be a bit humble
> >and TRY to understand so that problems can be solved.
> >Telling people to "fuck off" and call them liars is not the way to go
> >when they actually try to HELP you SECURE YOUR SYSTEM.- Hide quoted text=
 -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

We never thought it was a security group.. We DID however present some
of our VMS security findings at a SECURITY conference.. When we got
back home, someone pointed us to this thread, where people who had not
even seen the presentation or the materials were saying it was
bullshit, that it was probably a hoax, more or less calling us liars,
calling us assholes, and telling us to go fuck ourselves and
complaining about the use of "shellcode" (using SECURITY terminology
to describe a SECURITY vulnerability!!! how dare they?!).... Oh and
the fact that the group is not composed of security people or people
with the faintest idea about software exploitation did not stop them
from adding to the confusion (just read various writeups about it,
including hoffmanlabs...) AND accusing us of being bullshitting liars
did it?

FYI, We found the first few EXPLOITABLE bugs literally with only a few
hours of experience with VMS so we can't really understand what this
ELITISM among VMS users is about and would think you'd appreciate help
killing off a few painfully obvious bugs (AND THERE ARE STILL LOADS OF
THEM).


BTW out of curiousity on which installations have you seen finger
installed without privs? On my VAX 7.3 install it got WORLD and
SYSPRV, and I'm pretty sure 8.3 on Alpha at least installs it with
SYSPRV..


0
bugs6 (57)
8/17/2008 12:01:55 PM
In article <de856455-c585-481d-bdba-929b3baba05b@k30g2000hse.googlegroups.com>, bugs@signedness.org writes:
>On Aug 17, 11:43 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> b...@signedness.org wrote:
>> > Well,  we are not the ones telling others to "fuck off", are we?
>> > So who is the ass around here?
>>
>> I don"t recall anyone telling you to fuck off.
>
>Perhaps you have not read the whole thread:
>
>On Aug 15, 9:24 pm, VAXman-  @SendSpamHere.ORG wrote:
>[...]
>> Yeah, I know nothing about VMS.  Please, oh great one, teach me your
>> weirding way.
>>
>> Fuck off!
>[...]
>
>Does that refresh your memory?
>Seems kind of hostile if you ask me.
>We expect an apology for this.

Is the 1337 haxOrz offended?



>> You came to a VMS
>> newsgroup, announced some vulnerability that you could not explain in
>> VMS terms.
>No, we came to an VMS group that already discussed the vulnerabilities
>that we found and claimed that they were lies and a hoax.
>So we provided you with videos of working PoC exploits to clarify that
>this
>for sure was a real thing. Unfortunately that did not help.
>
>We are sorry that we assumed that you guys
>knew what shellcode was, it is a common used description in SECURITY
>which obviously is not an area that you are interested of.
>It is laughable that there are still people working with security
>in IT that does not know what shellcode is.
>That imply that someone have buried is head in
>sand for the past 15 years.
>
>> It is like you talking chinese to an american. You insisted
>> in using terms like "shellcode" even after people told you they didn't
>> understand what that meant.
>There was attempts to try to clarify this, for example by Simon
>Clubley:
>
>On Aug 15, 8:14 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
>(Simon Clubley) wrote:
>> I think that Brian may be thinking that shellcode is a series of DCL
>> commands instead of machine code. I think it's already been pointed
>> out on this thread already what the definition of shellcode is in the
>> context that you are using it, but Wikipedia has a writeup in case
>> Brian missed the earlier message:
>>
>>        http://en.wikipedia.org/wiki/Shellcode
>
>But people are obviously to stubborn
>to even attempt to understand or even try to look it up
>(google for shellcode +security would have been enough for anyone).
>[...]

We get unix folks here all the time referring to DCL "shells" and writing
shell code or scripts.  One of the initial reports was that typing in 511
characters followed by UP arrows at the DCL prompt caused a stack dump.



>> If you had said:
>>
>> if you enter 511 bytes, add a couple of escape sequenmces (like 3
>> uparrows) followed by 4 bytes, then the application will branch to the
>> address indicated by those 4 bytes, this would have been understood very
>> quickly by everyone, even if they couldn't reproduce it.
>LOL
>That is exactly what we did, except that we used "address to jump to"
>and
>"return address" instead of "followed by four bytes". I'm not even
>going
>to quote that post.
>
>But that was obviously not clear enough, since we are not VMS-people,
>and theirfore can not be fully trusted:
>
>On Aug 15, 9:24 pm, VAXman-  @SendSpamHere.ORG wrote:
>[...]
>> Send me your so called "shellcode" and FILE.EXE then along with some
>> instuctions other than typing 511 characters and 3 up-arrows.
>[...]
>
>VAXman did not even bother to watch the videos, he continued to
>mess with DCL even though we nicely pointed out that the bug
>was located elsewhere. He also did not listen to us when we explained
>why FILE.EXE is used.

Yes I did... to the point of point of a couple of characters in []s.
I'm not downloading software off the net because you instruct me due
to some codec your recording software uses.  If you were clearly in-
tersted in the goals of making systems more secure, you could have
converted your video to a common format that did NOT require that I
download some "quationable" software from the net.


>With trivial we mean questions that could easily have been looked up
>using
>for example google. But that of course, requires a will to learn and
>understand
>new things, and that is probably not the main issue for some of you
>here.

Leading one in the wrong direction with obfuscated terminology wouldn't
likely render a clearer understanding by Googling it.  In your defense,
Sampal's description and the lack of reproducability by others here was
clouding the view more than clarifying.



>We are NOT VMS people, and we have never claimed to be that either.
>In fact, we know very little about the system itself, we find
>vulnerabilities and write PoC code to proof that the vulnerabilities
>exist.
>
>The reason for this is to make the digital world a little safer for
>everybody.

A laudable goal.  Thanks.



>Obviously that is not what everybody wants. Instead of taking a piss
>on
>people trying to secure your system you should perhaps be a bit humble
>and TRY to understand so that problems can be solved.
>Telling people to "fuck off" and call them liars is not the way to go
>when they actually try to HELP you SECURE YOUR SYSTEM.

I never called you a liar.  The "fuck off" was in response to your
initiated insult.

The great many people here have systems and data on said systems that
they wish to secure and protect.  The first thing to do in such cases
it to know what exploits we need to secure ourselves and our systems
from.

Once I was able to actually get the 511 character stack dump to occur,
I had your "exploit" worked out.  And, I don't see why you couldn't use
SHOW PROC/PRIV... I did.

I am also aware of where, in the VMS source, this problem occurs now.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/17/2008 12:57:42 PM
In article <68f56a51-2532-4fc8-9965-4f95067031ac@a70g2000hsh.googlegroups.com>, bugs@signedness.org writes:
>On Aug 17, 11:54=A0am, davi...@alpha2.mdx.ac.uk wrote:
>> In article <de856455-c585-481d-bdba-929b3baba...@k30g2000hse.googlegroups=
>..com>, b...@signedness.org writes:
>>
>>
>>
>> >On Aug 17, 11:43 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> >> b...@signedness.org wrote:
>> >> > Well, =A0we are not the ones telling others to "fuck off", are we?
>> >> > So who is the ass around here?
>>
>> >> I don"t recall anyone telling you to fuck off.
>>
>> >Perhaps you have not read the whole thread:
>>
>> >On Aug 15, 9:24 pm, VAXman- =A0@SendSpamHere.ORG wrote:
>> >[...]
>> >> Yeah, I know nothing about VMS. =A0Please, oh great one, teach me your
>> >> weirding way.
>>
>> >> Fuck off!
>> >[...]
>>
>> >Does that refresh your memory?
>> >Seems kind of hostile if you ask me.
>> >We expect an apology for this.
>>
>> >> You came to a VMS
>> >> newsgroup, announced some vulnerability that you could not explain in
>> >> VMS terms.
>> >No, we came to an VMS group that already discussed the vulnerabilities
>> >that we found and claimed that they were lies and a hoax.
>> >So we provided you with videos of working PoC exploits to clarify that
>> >this
>> >for sure was a real thing. Unfortunately that did not help.
>>
>> >We are sorry that we assumed that you guys
>> >knew what shellcode was, it is a common used description in SECURITY
>> >which obviously is not an area that you are interested of.
>> >It is laughable that there are still people working with security
>> >in IT that does not know what shellcode is.
>> >That imply that someone have buried is head in
>> >sand for the past 15 years.
>>
>> This is NOT a security group. You have been receiving responses from both
>> people who know security terminology and people who don't.
>>
>> David Webb
>> Security team leader
>> CCSS
>> Middlesex University
>>
>>
>>
>> >> It is like you talking chinese to an american. You insisted
>> >> in using terms like "shellcode" even after people told you they didn't
>> >> understand what that meant.
>> >There was attempts to try to clarify this, for example by Simon
>> >Clubley:
>>
>> >On Aug 15, 8:14 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
>> >(Simon Clubley) wrote:
>> >> I think that Brian may be thinking that shellcode is a series of DCL
>> >> commands instead of machine code. I think it's already been pointed
>> >> out on this thread already what the definition of shellcode is in the
>> >> context that you are using it, but Wikipedia has a writeup in case
>> >> Brian missed the earlier message:
>>
>> >> =A0 =A0 =A0 =A0http://en.wikipedia.org/wiki/Shellcode
>>
>> >But people are obviously to stubborn
>> >to even attempt to understand or even try to look it up
>> >(google for shellcode +security would have been enough for anyone).
>> >[...]
>>
>> >> If you had said:
>>
>> >> if you enter 511 bytes, add a couple of escape sequenmces (like 3
>> >> uparrows) followed by 4 bytes, then the application will branch to the
>> >> address indicated by those 4 bytes, this would have been understood ve=
>ry
>> >> quickly by everyone, even if they couldn't reproduce it.
>> >LOL
>> >That is exactly what we did, except that we used "address to jump to"
>> >and
>> >"return address" instead of "followed by four bytes". I'm not even
>> >going
>> >to quote that post.
>>
>> >But that was obviously not clear enough, since we are not VMS-people,
>> >and theirfore can not be fully trusted:
>>
>> >On Aug 15, 9:24 pm, VAXman- =A0@SendSpamHere.ORG wrote:
>> >[...]
>> >> Send me your so called "shellcode" and FILE.EXE then along with some
>> >> instuctions other than typing 511 characters and 3 up-arrows.
>> >[...]
>>
>> >VAXman did not even bother to watch the videos, he continued to
>> >mess with DCL even though we nicely pointed out that the bug
>> >was located elsewhere. He also did not listen to us when we explained
>> >why FILE.EXE is used.
>>
>> >> Your own binary code is irrelevant here. People here would understand
>> >> that if you can specify an address to branch, you could get the progra=
>m
>> >> to branch to your own code.
>>
>> >It is not irrelevant when trying to describe what the exploit actually
>> >does,
>> >obviously there are people that have a great trouble understanding the
>> >basics of the exploit since questions with trivial answers has been
>> >repeated
>> >all over the thread.
>>
>> >With trivial we mean questions that could easily have been looked up
>> >using
>> >for example google. But that of course, requires a will to learn and
>> >understand
>> >new things, and that is probably not the main issue for some of you
>> >here.
>>
>> >We are NOT VMS people, and we have never claimed to be that either.
>> >In fact, we know very little about the system itself, we find
>> >vulnerabilities and write PoC code to proof that the vulnerabilities
>> >exist.
>>
>> >The reason for this is to make the digital world a little safer for
>> >everybody.
>> >Obviously that is not what everybody wants. Instead of taking a piss
>> >on
>> >people trying to secure your system you should perhaps be a bit humble
>> >and TRY to understand so that problems can be solved.
>> >Telling people to "fuck off" and call them liars is not the way to go
>> >when they actually try to HELP you SECURE YOUR SYSTEM.- Hide quoted text=
> -
>>
>> - Show quoted text -- Hide quoted text -
>>
>> - Show quoted text -
>
>We never thought it was a security group.. We DID however present some
>of our VMS security findings at a SECURITY conference.. When we got
>back home, someone pointed us to this thread, where people who had not
>even seen the presentation or the materials were saying it was
>bullshit, that it was probably a hoax, more or less calling us liars,
>calling us assholes, and telling us to go fuck ourselves and
>complaining about the use of "shellcode" (using SECURITY terminology
>to describe a SECURITY vulnerability!!! how dare they?!).... Oh and
>the fact that the group is not composed of security people or people
>with the faintest idea about software exploitation did not stop them
>from adding to the confusion (just read various writeups about it,
>including hoffmanlabs...) AND accusing us of being bullshitting liars
>did it?
>
Those who knew anything about security were simply asking for more details
since the description given by Sampsa, who was at that time the only person with
access to the slides from the security conference, was extremely vague.
With respect your subsequent descriptions although better still lacked enough
detail and the fact that the videos could not be viewed by many people when 
they first attempted to look at them didn't help.
However we have now reached the point where enough detail has been forthcoming
to replicate the access violations. So can I ask that both the denizens of
comp.os.vms and yourselves calm down and discuss the vulnerabilities rather
than engage in attacks against each other.




>FYI, We found the first few EXPLOITABLE bugs literally with only a few
>hours of experience with VMS so we can't really understand what this
>ELITISM among VMS users is about and would think you'd appreciate help
>killing off a few painfully obvious bugs (AND THERE ARE STILL LOADS OF
>THEM).
>
>
>BTW out of curiousity on which installations have you seen finger
>installed without privs? On my VAX 7.3 install it got WORLD and
>SYSPRV, and I'm pretty sure 8.3 on Alpha at least installs it with
>SYSPRV..
>
Sorry my mistake. On all my systems I have the finger server disabled and hence 
the finger client is also not installed with any privileges.
I just enabled the finger server and then the client is installed with
privileges

INSTALL> list/full sys$system:tcpip$finger.exe

DISK$ALPHASYS:<SYS0.SYSCOMMON.SYSEXE>.EXE
   TCPIP$FINGER;1   Open Hdr Shared   Prv
        Entry access count         = 0
        Current / Maximum shared   = 1 / 0
        Global section count       = 1
        Privileges = WORLD SYSPRV
        Authorized = WORLD SYSPRV


David Webb
Security team leader
CCSS
Middlesex University


>
0
david20
8/17/2008 12:58:32 PM
On Aug 17, 2:57 pm, VAXman-  @SendSpamHere.ORG wrote:

> Is the 1337 haxOrz offended?
We get offended by people telling us to fuck off, yes.
Especially when we secure their systems FOR FREE.

> I never called you a liar.  The "fuck off" was in response to your
> initiated insult.
It was not an insult, it was a recommendation for you to read up
on the topic. Even though you are "Mr VMS Kernel H4%0r" you still
lack
quite a bit of knowledge in the area of writing exploits. ;)

> Once I was able to actually get the 511 character stack dump to occur,
> I had your "exploit" worked out.  And, I don't see why you couldn't use
> SHOW PROC/PRIV... I did.
We never said that it was not possible, we just did not solve it that
way.
We just owned the system in a way that worked for a PoC.
After all, we are not VMS people and far from 31337 VMS Kernel H4%0rz.

> I am also aware of where, in the VMS source, this problem occurs now.
Cool.
Would be nice with a "thank you" since we obviously secured your
system (FOR FREE).

0
bugs6 (57)
8/17/2008 1:22:14 PM
On Aug 17, 1:58=A0pm, davi...@alpha2.mdx.ac.uk wrote:
> Those who knew anything about security were simply asking for more detail=
s
> since the description given by Sampsa, who was at that time the only pers=
on with
> access to the slides from the security conference, was extremely vague.

In my defense, I'd just like to say that my intention was never to
mislead anyone, merely relay the information that I'd seen in the
slides. I did not know what the copyright/distribution issues (if any)
were with the slides, so I didn't feel able to post them anywhere
public as they weren't mine to post.

I was just trying to let the guys here on comp.os.vms know (from a
very high level summary) what was shown at DEFCON. Sorry for any
trouble caused.

Sampsa

0
sampsal (134)
8/17/2008 1:28:57 PM
In article <9242f78b-9a87-44f3-a8ea-80ecebed5a36@25g2000hsx.googlegroups.com>, sampsal@gmail.com writes:
>On Aug 17, 1:58=A0pm, davi...@alpha2.mdx.ac.uk wrote:
>> Those who knew anything about security were simply asking for more detail=
>s
>> since the description given by Sampsa, who was at that time the only pers=
>on with
>> access to the slides from the security conference, was extremely vague.
>
>In my defense, I'd just like to say that my intention was never to
>mislead anyone, merely relay the information that I'd seen in the
>slides. I did not know what the copyright/distribution issues (if any)
>were with the slides, so I didn't feel able to post them anywhere
>public as they weren't mine to post.
>
>I was just trying to let the guys here on comp.os.vms know (from a
>very high level summary) what was shown at DEFCON. Sorry for any
>trouble caused.
>
>Sampsa
>
Sampsa,

I didn't mean any criticism of you personally and would like to thank you for 
passing on what information you felt you could.


David Webb
Security team leader
CCSS
Middlesex University
0
david20
8/17/2008 1:56:11 PM
In article 
<9242f78b-9a87-44f3-a8ea-80ecebed5a36@25g2000hsx.googlegroups.com>, 
sampsal@gmail.com wrote:
>On Aug 17, 1:58�pm, davi...@alpha2.mdx.ac.uk wrote:
>> Those who knew anything about security were simply asking for more details
>> since the description given by Sampsa, who was at that time the only person with
>> access to the slides from the security conference, was extremely vague.
>
>In my defense, I'd just like to say that my intention was never to
>mislead anyone, merely relay the information that I'd seen in the
>slides. I did not know what the copyright/distribution issues (if any)
>were with the slides, so I didn't feel able to post them anywhere
>public as they weren't mine to post.
>
>I was just trying to let the guys here on comp.os.vms know (from a
>very high level summary) what was shown at DEFCON. Sorry for any
>trouble caused.

FWIW - the fact that you raised the flag, and started the discussion does not
warrant an apology - rather, a note of thanks to you and all who have
contributed to this thread.  That thanks includes the primary antagonists as
well - although the attitudes can be ugly at times, the end results are worth
it.

Now can we all just shake hands and share in the satisfaction of a job well
done?

:-)
0
BRAD77 (76)
8/17/2008 1:56:16 PM
On Aug 17, 1:57=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <de856455-c585-481d-bdba-929b3baba...@k30g2000hse.googlegroups=
..com>, b...@signedness.org writes:
>
>
>
>
>
> >On Aug 17, 11:43 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> >> b...@signedness.org wrote:
> >> > Well, =A0we are not the ones telling others to "fuck off", are we?
> >> > So who is the ass around here?
>
> >> I don"t recall anyone telling you to fuck off.
>
> >Perhaps you have not read the whole thread:
>
> >On Aug 15, 9:24 pm, VAXman- =A0@SendSpamHere.ORG wrote:
> >[...]
> >> Yeah, I know nothing about VMS. =A0Please, oh great one, teach me your
> >> weirding way.
>
> >> Fuck off!
> >[...]
>
> >Does that refresh your memory?
> >Seems kind of hostile if you ask me.
> >We expect an apology for this.
>
> Is the 1337 haxOrz offended?
>
>
>
>
>
> >> You came to a VMS
> >> newsgroup, announced some vulnerability that you could not explain in
> >> VMS terms.
> >No, we came to an VMS group that already discussed the vulnerabilities
> >that we found and claimed that they were lies and a hoax.
> >So we provided you with videos of working PoC exploits to clarify that
> >this
> >for sure was a real thing. Unfortunately that did not help.
>
> >We are sorry that we assumed that you guys
> >knew what shellcode was, it is a common used description in SECURITY
> >which obviously is not an area that you are interested of.
> >It is laughable that there are still people working with security
> >in IT that does not know what shellcode is.
> >That imply that someone have buried is head in
> >sand for the past 15 years.
>
> >> It is like you talking chinese to an american. You insisted
> >> in using terms like "shellcode" even after people told you they didn't
> >> understand what that meant.
> >There was attempts to try to clarify this, for example by Simon
> >Clubley:
>
> >On Aug 15, 8:14 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
> >(Simon Clubley) wrote:
> >> I think that Brian may be thinking that shellcode is a series of DCL
> >> commands instead of machine code. I think it's already been pointed
> >> out on this thread already what the definition of shellcode is in the
> >> context that you are using it, but Wikipedia has a writeup in case
> >> Brian missed the earlier message:
>
> >> =A0 =A0 =A0 =A0http://en.wikipedia.org/wiki/Shellcode
>
> >But people are obviously to stubborn
> >to even attempt to understand or even try to look it up
> >(google for shellcode +security would have been enough for anyone).
> >[...]
>
> We get unix folks here all the time referring to DCL "shells" and writing
> shell code or scripts. =A0One of the initial reports was that typing in 5=
11
> characters followed by UP arrows at the DCL prompt caused a stack dump.
>
>
>
>
>
> >> If you had said:
>
> >> if you enter 511 bytes, add a couple of escape sequenmces (like 3
> >> uparrows) followed by 4 bytes, then the application will branch to the
> >> address indicated by those 4 bytes, this would have been understood ve=
ry
> >> quickly by everyone, even if they couldn't reproduce it.
> >LOL
> >That is exactly what we did, except that we used "address to jump to"
> >and
> >"return address" instead of "followed by four bytes". I'm not even
> >going
> >to quote that post.
>
> >But that was obviously not clear enough, since we are not VMS-people,
> >and theirfore can not be fully trusted:
>
> >On Aug 15, 9:24 pm, VAXman- =A0@SendSpamHere.ORG wrote:
> >[...]
> >> Send me your so called "shellcode" and FILE.EXE then along with some
> >> instuctions other than typing 511 characters and 3 up-arrows.
> >[...]
>
> >VAXman did not even bother to watch the videos, he continued to
> >mess with DCL even though we nicely pointed out that the bug
> >was located elsewhere. He also did not listen to us when we explained
> >why FILE.EXE is used.
>
> Yes I did... to the point of point of a couple of characters in []s.
> I'm not downloading software off the net because you instruct me due
> to some codec your recording software uses. =A0If you were clearly in-
> tersted in the goals of making systems more secure, you could have
> converted your video to a common format that did NOT require that I
> download some "quationable" software from the net.
>
> >With trivial we mean questions that could easily have been looked up
> >using
> >for example google. But that of course, requires a will to learn and
> >understand
> >new things, and that is probably not the main issue for some of you
> >here.
>
> Leading one in the wrong direction with obfuscated terminology wouldn't
> likely render a clearer understanding by Googling it. =A0In your defense,
> Sampal's description and the lack of reproducability by others here was
> clouding the view more than clarifying.
>
> >We are NOT VMS people, and we have never claimed to be that either.
> >In fact, we know very little about the system itself, we find
> >vulnerabilities and write PoC code to proof that the vulnerabilities
> >exist.
>
> >The reason for this is to make the digital world a little safer for
> >everybody.
>
> A laudable goal. =A0Thanks.
>
> >Obviously that is not what everybody wants. Instead of taking a piss
> >on
> >people trying to secure your system you should perhaps be a bit humble
> >and TRY to understand so that problems can be solved.
> >Telling people to "fuck off" and call them liars is not the way to go
> >when they actually try to HELP you SECURE YOUR SYSTEM.
>
> I never called you a liar. =A0The "fuck off" was in response to your
> initiated insult.
>
> The great many people here have systems and data on said systems that
> they wish to secure and protect. =A0The first thing to do in such cases
> it to know what exploits we need to secure ourselves and our systems
> from.
>
> Once I was able to actually get the 511 character stack dump to occur,
> I had your "exploit" worked out. =A0And, I don't see why you couldn't use
> SHOW PROC/PRIV... I did.
>
> I am also aware of where, in the VMS source, this problem occurs now.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME=
SIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional prote=
ction
> no matter how extreme, vituperous, or vigorously expressed they may be. (=
NJSC)
>
> Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article =
outside
> of usenet _must_ include its contents in its entirety including this copy=
right
> notice, disclaimer and quotations.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Is the 1337 haxOrz offended? 1337 haxOrz?? Is that an attempt to wind
us up? ;) As previously stated on multiple occasions we found it
trivial to break OpenVMS without any prior experience of the operating
system.. Maybe I'm reading this wrong and you think that finding
exploitable security bugs in VMS some sort of achievement, but then I
recommend you go look for some yourself and learn for yourself that it
is not. If people do this and don't blindly trust the myth of VMS
being damn near unbreakable, everybody will be better off and then
maybe we have achieved something with our exploits... And no we are
not the least bit offended, why would we be? We did what we set out to
do, got the exploits and hopefully made a point that old
"truths" (like VMS security being hard to break) should be
questioned.

The "questionable" software is from vmware, they are listed on the
NYSE under the VMW symbol http://finance.google.co.uk/finance?client=3Dob&q=
=3DNYSE:VMW
they also happen to be the leader in the virtualization market so they
are pretty ok I think...

The obfuscated terminology? Is that the "shellcode"? I just checked
and as far as I can see if you google "shellcode" every result from
the first 10 pages (I stopped after 10) uses shellcode to mean exploit
payload.

What is this insult you are talking about? One of the other presenters
suggesting you get a book on software exploitation? I fail to see how
thats an insult. I certainly would not be offended if you asked me to
get a book on VMS if I was serious about discussing anything else in
VMS than the vulnerabilities we found.

As previously mentioned, the reason we wrote the shellcode we did was
because it was easier to debug and a somewhat more generic approach
than say write code to modify sysuaf, since the
same code can be reused for vulnerabilities where you don't have privs
to modify sysuaf etc. Of course we could have spawned a new instance
of DCL and done a "show proc/priv" but we didn't, the code we have now
should be pretty reusable for remote exploitation without having to
write a full "bind shell shellcode" (yeah yeah I know terminology
again.. but its easy enough to google.) In the VAX exploit we used SYS
$SETUAI() and do a show proc/priv in the video btw.


We sincerely interested in what approch you took in your shellcode,
care to share that information?  Also if you have any good tricks to
share on how to determine the system services numbers at runtime from
your shellcode? That would be interesting.



0
bugs6 (57)
8/17/2008 2:03:44 PM
On Aug 17, 2:28=A0pm, samp...@gmail.com wrote:
> On Aug 17, 1:58=A0pm, davi...@alpha2.mdx.ac.uk wrote:
>
> > Those who knew anything about security were simply asking for more deta=
ils
> > since the description given by Sampsa, who was at that time the only pe=
rson with
> > access to the slides from the security conference, was extremely vague.
>
> In my defense, I'd just like to say that my intention was never to
> mislead anyone, merely relay the information that I'd seen in the
> slides. I did not know what the copyright/distribution issues (if any)
> were with the slides, so I didn't feel able to post them anywhere
> public as they weren't mine to post.
>
> I was just trying to let the guys here on comp.os.vms know (from a
> very high level summary) what was shown at DEFCON. Sorry for any
> trouble caused.
>
> Sampsa

I think I speak for all the presenters when I say we don't have a
problem with you posting the information you did. In fact I think you
were one of the first people here to "get it". Congratulations on that
and thanks for trying to explain it to others.

What annoys us are useless comments from other people such as:-

"I'm convinced bugs wouldn't recognize a VMS security flaw if it
danced naked on his head and sang "Happy Days Are Here Again""

and other thoroughly useless comments hinting at it all being fake and
bullshit and people spreading incorrect "facts" and adding to the
general confusion, for example saying only VAX is affected by
the .plan attack, or that memory can only be read with the format
string bug.

PS. To the person that made the comment quoted above, care to put you
money where your mouth is? ;)
0
bugs6 (57)
8/17/2008 3:18:14 PM
On Aug 17, 3:28 pm, samp...@gmail.com wrote:
> On Aug 17, 1:58 pm, davi...@alpha2.mdx.ac.uk wrote:
>
> > Those who knew anything about security were simply asking for more details
> > since the description given by Sampsa, who was at that time the only person with
> > access to the slides from the security conference, was extremely vague.
>
> In my defense, I'd just like to say that my intention was never to
> mislead anyone, merely relay the information that I'd seen in the
> slides. I did not know what the copyright/distribution issues (if any)
> were with the slides, so I didn't feel able to post them anywhere
> public as they weren't mine to post.
>
> I was just trying to let the guys here on comp.os.vms know (from a
> very high level summary) what was shown at DEFCON. Sorry for any
> trouble caused.
>
> Sampsa

Thank you for trying to share the knowledge.
And btw, the slides on the CD is a bit old, we will put the latest
ones on
the web when we have done the other talk.

>
0
bugs6 (57)
8/17/2008 3:21:21 PM
In article <48a80e40$0$90275$14726298@news.sunsite.dk>,
 "R.A.Omond" <Roy.Omond@BlueBubble.UK.Com> wrote:

> david20@alpha2.mdx.ac.uk wrote:
> > [...snip...]
> > This bug doesn't effect all images with embedded commandline commands for
> > instance SYSGEN seems to have been written to cope with it
> > 
> > $ mcr sysgen
> > SYSGEN> 
> > 1234567890123456789012345678901234567890123456789012345678901234567890123456
> > 78901234567890123456789012345678901234567890123
> > 4567890123456789012345678901234567890123456789012345678901234567890123456789
> > 0
> > %RMS-W-TNS, terminator not seen
> > 
> > 
> > It doesn't allow you to enter a long enough string and trying with the 
> > maximum
> > string it will allow + UP gives
> > 
> > $ mcr sysgen
> > SYSGEN> 
> > 1234567890123456789012345678901234567890123456789012345678901234567890123456
> > 78901234567890123456789012345678901234567890123
> > 1234567890123456789012345678901234567890123456789012345678901234567890123456
> > $
> > %SYSGEN-E-SYNTAX, syntax error:
> > '123456789012345678901234567890123456789012345678901234567890123456789012345
> > 678901234567890123456789
> > 0123456789012345678901231234567890123456789012345678901234567890123456789012
> > 345678901234567890123456'
> > SYSGEN>
> > 
> > Other images such as Authorize or SYSMAN won't allow you to run them 
> > without
> > having some privileges.
> > 
> > $ mcr sysman
> > %SYSMAN-F-NOOPER, SYSMAN requires OPER privilege
> > $
> > $ mcr authorize
> > %UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT)
> > -RMS-E-PRV, insufficient privilege or file protection violation
> 
> In my tests, the common factor seems to be any program linked against
> SMGSHR, so it's looking like JF was correct.
> 
> And the fact that it *is* in this single shared image (if above is
> indeed correct), should make fixing the problem much easier.
> 
> I'm going to grab the source for SMGSHR tomorrow and have a good look.

Indeed, SYSGEN is one of the few utilities which was not converted to 
use the recall functionality when that arrived. Even at V8.3, SYSGEN 
still only allows recall of the last command, (and also forces uppercase 
input).

When you consider that SYSGEN is the one program which needs to run
standalone, it makes sense that it doesn't depend on the common input
libraries.

-- 
Paul Sture
0
8/17/2008 5:47:27 PM
bugs@signedness.org wrote:

> No, we came to an VMS group that already discussed the vulnerabilities
> that we found and claimed that they were lies and a hoax.

Initially, you were unable to explain this issue in terms that were
credible because you spoke "chinese" with terms that are foreign to VMS.


> We are sorry that we assumed that you guys
> knew what shellcode was, it is a common used description in SECURITY

Your message sounded like you had found a Unix bug in VMS and knew
nothing of VMS, so it is perfectly normal that many doubted you were
legit since you were unable to give details we could understand
initially. It took a lot of discussion and a translator to give us a
clue on what the actual vulnerability was.

> It is laughable that there are still people working with security
> in IT that does not know what shellcode is.

VMS has not had many security hackers in the last couple of decades, so
you are correct that we don't know about all the terminology used by
hackers.

we don't use the term "shell" in VMS, and to us, it means someone coming
from Unixland, and it refers to the shell (in VMS terms, DCL, or in Unix
terms Bash etc). Shellcode would then be seen as shell scripts.


> There was attempts to try to clarify this, for example by Simon
> Clubley:

Correct. And after we were able to translate "shellcode" into something
meaningful like "machine code", then we could understand what you were
talking about. Had you begun with "machine code", then there would have
been less confusion.

Also, initially, it was assumed you were talking about DCL. But it is
only once it was revealed that you needed to be inside an application
that uses the CLI routines that things started to fall into place.




> That is exactly what we did, except that we used "address to jump to"
> and
> "return address" instead of "followed by four bytes". I'm not even
> going
> to quote that post.

YOu did not state it in those terms. You used terms like shellcode. And
you also mixed in the finger thing which confused a lot since it appears
to be a totally separate problem.


> But that was obviously not clear enough, since we are not VMS-people,
> and theirfore can not be fully trusted:

Please understand that this is a fairly small community and when some
newcomer comes in with some fantastic claims, there is to be some
serious questioning to establish the credibility of that person, and
since you did not know VMS terminology, it was hard to take you so
seriously.



> VAXman did not even bother to watch the videos, he continued to
> mess with DCL even though we nicely pointed out that the bug
> was located elsewhere. He also did not listen to us when we explained
> why FILE.EXE is used.

It was pointed to you that the codecs used in the videos are
non-standard and cannot be watched by everyone. I also didn't even
bother to download them.

Your introduction of FILE.EXE was absolutely confusing. This was not
necessary. And reduced your credibility because it put the focus on the
"file.exe" instead of on the actual vulnerability.

You should have stuck to "enter 511 bytes, up up up, and a 4 byte binary
value, and the application will then branch to that binary value, and
any code located there runs with whatever privileges the application had
enabled at that time.

Then, you could have introduced the concept of branching to some machine
code stored in memory via a logical name. And then the concept of that
machine code using SYS$CREPRC to create a suboprocess which has
inherited whatecer privileges were enabled inside of the main application.

The way you presented it initially appeared to be a mismash of various
random terms that didn't apply to VMS, and made us even doubt that when
you used "logical" you really meant a VMS logical name. Mentioning that
the logical was created in the process logical name table would have
assured us you knew what a logical name was. (this is a concept foreign
to unix and DOS/windows).



> It is not irrelevant when trying to describe what the exploit actually
> does,

Your implementation is not really necessary. Mentioning that an
installed image can be made to branch to any random location in memory
which can potentially execute your own code is sufficient to get most fo
the folks here to understand the real problem.

Also, I beleive that someone mentioned "crash the system".  But it is
really crash the application. Again, terminology that made the issue
lose credibility.



> obviously there are people that have a great trouble understanding the
> basics of the exploit since questions with trivial answers has been
> repeated
> all over the thread.

Now that it has been explained in terms we understand, we understand the
problem.

> In fact, we know very little about the system itself, we find
> vulnerabilities and write PoC code to proof that the vulnerabilities
> exist.

And this is why it was hard for many of us to take you seriously.
Remember that you barged into a small community with a "the theatre is
on fire" and then used language that made it look like you thought the
theratre was on fire because you saw a blinking light.

I think you assumed everyone knew your terminology and that is why
things turned sour. Just be aware of that next time you find a problem
with an OS with which you are not familiar.


> people trying to secure your system you should perhaps be a bit humble
> and TRY to understand so that problems can be solved.

The next step is for you to spill the beans on exactly whom you
contacted at HP so that we can try to find out if HP is taking thsi
seriously or not. Contrary to Linux, we can't fix bugs that are found
and depend on a dwindling supply of VMS engineers
 to fix them and depend on some not so great managemenet to decide to
release it or not.
0
8/17/2008 6:11:42 PM
I would still be interested to know what the up-arrow 3 times actually
does to trigger this issue.

Someone has started they are not echoed.

Does SMG use $QIO's terminal driver capabilities to read input (such as
detecting ansi sequences) or does it call $QIO for raw input and SMG
does all the interpretation itself ?

Consider the possibility that this would be a terminal driver problem:
with SET TERM/UNKNOWN, the $QIO might continue to add data to the buffer
even though $QIO was told to not write anything beyond 511 bytes. And
this writing would done at the driver level.
0
8/17/2008 6:26:54 PM
On Aug 17, 7:11=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> b...@signedness.org wrote:
> > No, we came to an VMS group that already discussed the vulnerabilities
> > that we found and claimed that they were lies and a hoax.
>
> Initially, you were unable to explain this issue in terms that were
> credible because you spoke "chinese" with terms that are foreign to VMS.
>
> > We are sorry that we assumed that you guys
> > knew what shellcode was, it is a common used description in SECURITY
>
> Your message sounded like you had found a Unix bug in VMS and knew
> nothing of VMS, so it is perfectly normal that many doubted you were
> legit since you were unable to give details we could understand
> initially. It took a lot of discussion and a translator to give us a
> clue on what the actual vulnerability was.
>
> > It is laughable that there are still people working with security
> > in IT that does not know what shellcode is.
>
> VMS has not had many security hackers in the last couple of decades, so
> you are correct that we don't know about all the terminology used by
> hackers.
>
> we don't use the term "shell" in VMS, and to us, it means someone coming
> from Unixland, and it refers to the shell (in VMS terms, DCL, or in Unix
> terms Bash etc). Shellcode would then be seen as shell scripts.
>
> > There was attempts to try to clarify this, for example by Simon
> > Clubley:
>
> Correct. And after we were able to translate "shellcode" into something
> meaningful like "machine code", then we could understand what you were
> talking about. Had you begun with "machine code", then there would have
> been less confusion.
>
> Also, initially, it was assumed you were talking about DCL. But it is
> only once it was revealed that you needed to be inside an application
> that uses the CLI routines that things started to fall into place.
>
> > That is exactly what we did, except that we used "address to jump to"
> > and
> > "return address" instead of "followed by four bytes". I'm not even
> > going
> > to quote that post.
>
> YOu did not state it in those terms. You used terms like shellcode. And
> you also mixed in the finger thing which confused a lot since it appears
> to be a totally separate problem.
>
> > But that was obviously not clear enough, since we are not VMS-people,
> > and theirfore can not be fully trusted:
>
> Please understand that this is a fairly small community and when some
> newcomer comes in with some fantastic claims, there is to be some
> serious questioning to establish the credibility of that person, and
> since you did not know VMS terminology, it was hard to take you so
> seriously.
>
> > VAXman did not even bother to watch the videos, he continued to
> > mess with DCL even though we nicely pointed out that the bug
> > was located elsewhere. He also did not listen to us when we explained
> > why FILE.EXE is used.
>
> It was pointed to you that the codecs used in the videos are
> non-standard and cannot be watched by everyone. I also didn't even
> bother to download them.
>
> Your introduction of FILE.EXE was absolutely confusing. This was not
> necessary. And reduced your credibility because it put the focus on the
> "file.exe" instead of on the actual vulnerability.
>
> You should have stuck to "enter 511 bytes, up up up, and a 4 byte binary
> value, and the application will then branch to that binary value, and
> any code located there runs with whatever privileges the application had
> enabled at that time.
>
> Then, you could have introduced the concept of branching to some machine
> code stored in memory via a logical name. And then the concept of that
> machine code using SYS$CREPRC to create a suboprocess which has
> inherited whatecer privileges were enabled inside of the main application=
..
>
> The way you presented it initially appeared to be a mismash of various
> random terms that didn't apply to VMS, and made us even doubt that when
> you used "logical" you really meant a VMS logical name. Mentioning that
> the logical was created in the process logical name table would have
> assured us you knew what a logical name was. (this is a concept foreign
> to unix and DOS/windows).
>
> > It is not irrelevant when trying to describe what the exploit actually
> > does,
>
> Your implementation is not really necessary. Mentioning that an
> installed image can be made to branch to any random location in memory
> which can potentially execute your own code is sufficient to get most fo
> the folks here to understand the real problem.
>
> Also, I beleive that someone mentioned "crash the system". =A0But it is
> really crash the application. Again, terminology that made the issue
> lose credibility.
>
> > obviously there are people that have a great trouble understanding the
> > basics of the exploit since questions with trivial answers has been
> > repeated
> > all over the thread.
>
> Now that it has been explained in terms we understand, we understand the
> problem.
>
> > In fact, we know very little about the system itself, we find
> > vulnerabilities and write PoC code to proof that the vulnerabilities
> > exist.
>
> And this is why it was hard for many of us to take you seriously.
> Remember that you barged into a small community with a "the theatre is
> on fire" and then used language that made it look like you thought the
> theratre was on fire because you saw a blinking light.
>
> I think you assumed everyone knew your terminology and that is why
> things turned sour. Just be aware of that next time you find a problem
> with an OS with which you are not familiar.
>
> > people trying to secure your system you should perhaps be a bit humble
> > and TRY to understand so that problems can be solved.
>
> The next step is for you to spill the beans on exactly whom you
> contacted at HP so that we can try to find out if HP is taking thsi
> seriously or not. Contrary to Linux, we can't fix bugs that are found
> and depend on a dwindling supply of VMS engineers
> =A0to fix them and depend on some not so great managemenet to decide to
> release it or not.

Ok, well again..

1) We didn't come in here with "fantastic claims". Someone showed us
this thread, and we replied because people were insinuated that we
were full of shit.. We presented a couple of vulnerabilities we found
in VMS at security conference that ~8500 people attended. We gave you
videos demonstrating one of the bugs (let us know if someone wants the
finger exploit vid btw), we also offered to demonstrate the exploit
live. Shouldn't that at least give us SOME credibility??

2) Again with the terminology... When talking about security it make
sense to use security terminology, if you don't understand something,
then either google it or ask rather than assume..

3) We brought up finger because people were talking about it and
getting that wrong too

4) Someone may have mention "crash the system" but it wasn't us

5) We didn't barge in screaming the theatre is on fire.. We talked
about a few vulnerabilities at a conference and gave a few demos.
People that didn't see the presentation or even the material assumed
we were idiots and/or bullshitting about the vulnerabilities..

Fair enough, VMS users may not be used to receiving bug reports or
deal with security vulnerabilities, the rest I don't buy... I
recommend you change your attitudes though, and don't put people off
from reporting them because there are LOTS of them..

We contacted security-alert@hp.com , as far as I can understand they
assigned a person to the case and at least one other HP person was
cc'd in on the communication until they stopped replying (I don't
think it is necessary to out their names)..



0
bugs6 (57)
8/17/2008 7:30:23 PM
In article <48a86aca$0$1835$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>bugs@signedness.org wrote:
>{...snip...}
>> We are sorry that we assumed that you guys
>> knew what shellcode was, it is a common used description in SECURITY
>
>Your message sounded like you had found a Unix bug in VMS and knew
>nothing of VMS, so it is perfectly normal that many doubted you were
>legit since you were unable to give details we could understand
>initially. It took a lot of discussion and a translator to give us a
>clue on what the actual vulnerability was.
> 
>{...snip...}
>
>we don't use the term "shell" in VMS, and to us, it means someone coming
>from Unixland, and it refers to the shell (in VMS terms, DCL, or in Unix
>terms Bash etc). Shellcode would then be seen as shell scripts.
>
>{...snip...}
>
>Correct. And after we were able to translate "shellcode" into something
>meaningful like "machine code", then we could understand what you were
>talking about. Had you begun with "machine code", then there would have
>been less confusion.
>
>Also, initially, it was assumed you were talking about DCL. But it is
>only once it was revealed that you needed to be inside an application
>that uses the CLI routines that things started to fall into place.

All I wanted to do was replicate the so called CLI stack dump.  Shellcode
aside, there was a claim it could be easily created by simply entering the
characters, escapes, etc.  That did NOT produce what they claimed.  There
was a miss-communication of where this stack dump occurred too.  In fact,
we now know it is NOT the CLI.  It also occurs in an image and not at the
DCL prompt.


>> VAXman did not even bother to watch the videos, he continued to
>> mess with DCL even though we nicely pointed out that the bug
>> was located elsewhere. He also did not listen to us when we explained
>> why FILE.EXE is used.
>
>It was pointed to you that the codecs used in the videos are
>non-standard and cannot be watched by everyone. I also didn't even
>bother to download them.

A cohesive explaination of reproducing the stack dump would have been
better than some video of a terminal session.  There was also a report
of no audio explaining what was happening in the video.
 


>Your introduction of FILE.EXE was absolutely confusing. This was not
>necessary. And reduced your credibility because it put the focus on the
>"file.exe" instead of on the actual vulnerability.

Another valid point.



>You should have stuck to "enter 511 bytes, up up up, and a 4 byte binary
>value, and the application will then branch to that binary value, and
>any code located there runs with whatever privileges the application had
>enabled at that time.
>
>Then, you could have introduced the concept of branching to some machine
>code stored in memory via a logical name. And then the concept of that
>machine code using SYS$CREPRC to create a suboprocess which has
>inherited whatecer privileges were enabled inside of the main application.
>
>The way you presented it initially appeared to be a mismash of various
>random terms that didn't apply to VMS, and made us even doubt that when
>you used "logical" you really meant a VMS logical name. Mentioning that
>the logical was created in the process logical name table would have
>assured us you knew what a logical name was. (this is a concept foreign
>to unix and DOS/windows).

FWIW, 4 Alpha instructions (Macro64 code) and I was able to jump to code
written in a HLL. (Macro32 in this case.)  This code was loaded using a
supported mechanism in the LIB RTL into P1 space at an address defined
in SYS$SYSTEM:SYS$BASE_IMAGE.MAP.  Using MAIL and the 511 character over-
flow, I printed "Hello World".  I then modified the same routine to invoke
$SETPRV.  Simple.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/17/2008 8:09:17 PM
On Aug 17, 2:26=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> I would still be interested to know what the up-arrow 3 times actually
> does to trigger this issue.

Nothing much. It's just a convenient way to enter a since escape
followed by some more characters. But any 'other' escape will do. The
up-arrow is irrelevant.

> Does SMG use $QIO's terminal driver capabilities to read input (such as
> detecting ansi sequences) or does it call $QIO for raw input and SMG
> does all the interpretation itself ?

Both. It uses the IO$M_ENTEND functionality for some input, plani QIOs
for other.  In the trouble zone highlighted here it is doing simple
single character IOs with a 3 second timeout. They are there for all
to see using System Service Login. You can use MAIL or anything else
using SMG, but a simple test program is preferred to minimize the
clutter.
Having CMEXEC or better is recommended for a full view but not
critical.

$SPAWN ! Easy cleanup
$SET PROC/SSL=3D(STAT=3DON,FLAG=3DARG)
$RUN smg_test
$TYPE something ! Easy reference in log
$SET PROC/SSL=3DSTAT=3DUN
$LOGOUT
$ANAL/SSL/SELECT=3DACCES=3DUSER

---- smg_test.c ----
#include <descrip>
int     smg$create_virtual_keyboard(), smg$read_composed_line();
int     s,i,keyboard_id;
struct dsc$descriptor_d result =3D { 0, DSC$K_DTYPE_T, DSC$K_CLASS_D,
0 };
$DESCRIPTOR(prompt,"Test:");
main() {
    s =3D  smg$create_virtual_keyboard(&keyboard_id);
    while (s & 1) {
       s =3D  smg$read_composed_line(&keyboard_id,0,&result,&prompt);
    }
return(s);
}


>
> Consider the possibility that this would be a terminal driver problem:

I did. And came to the conclusion it is not.

> with SET TERM/UNKNOWN, the $QIO might continue to add data to the buffer
> even though $QIO was told to not write anything beyond 511 bytes. And
> this writing would done at the driver level.

That would be scary huh?
But that's not something we expect from OpenVMS.


Hein.

0
8/17/2008 8:36:31 PM
In article <9cb196c9-0f59-4b87-b9d4-6a1ad73db2e8@w7g2000hsa.googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>On Aug 17, 2:26=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> I would still be interested to know what the up-arrow 3 times actually
>> does to trigger this issue.
>
>Nothing much. It's just a convenient way to enter a since escape
>followed by some more characters. But any 'other' escape will do. The
>up-arrow is irrelevant.
>
>> Does SMG use $QIO's terminal driver capabilities to read input (such as
>> detecting ansi sequences) or does it call $QIO for raw input and SMG
>> does all the interpretation itself ?
>
>Both. It uses the IO$M_ENTEND functionality for some input, plani QIOs
>for other.  In the trouble zone highlighted here it is doing simple
>single character IOs with a 3 second timeout. They are there for all
>to see using System Service Login. You can use MAIL or anything else
>using SMG, but a simple test program is preferred to minimize the
>clutter.
>Having CMEXEC or better is recommended for a full view but not
>critical.
>
>$SPAWN ! Easy cleanup
>$SET PROC/SSL=3D(STAT=3DON,FLAG=3DARG)
>$RUN smg_test
>$TYPE something ! Easy reference in log
>$SET PROC/SSL=3DSTAT=3DUN
>$LOGOUT
>$ANAL/SSL/SELECT=3DACCES=3DUSER
>
>---- smg_test.c ----
>#include <descrip>
>int     smg$create_virtual_keyboard(), smg$read_composed_line();
>int     s,i,keyboard_id;
>struct dsc$descriptor_d result =3D { 0, DSC$K_DTYPE_T, DSC$K_CLASS_D,
>0 };
>$DESCRIPTOR(prompt,"Test:");
>main() {
>    s =3D  smg$create_virtual_keyboard(&keyboard_id);
>    while (s & 1) {
>       s =3D  smg$read_composed_line(&keyboard_id,0,&result,&prompt);
>    }
>return(s);
>}
>
>
>>
>> Consider the possibility that this would be a terminal driver problem:
>
>I did. And came to the conclusion it is not.
>
>> with SET TERM/UNKNOWN, the $QIO might continue to add data to the buffer
>> even though $QIO was told to not write anything beyond 511 bytes. And
>> this writing would done at the driver level.
>
>That would be scary huh?
>But that's not something we expect from OpenVMS.
>
>
>Hein.

I have coded up a demo of this exploit.  Macro64 (less than 10 instructions)
and a loader (Macro less than 10 lines).  It's way way way too easy assuming
you can get the stack dump.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/17/2008 9:05:06 PM
On Sun, 17 Aug 2008 12:30:23 -0700, <bugs@signedness.org> wrote:

> On Aug 17, 7:11�pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> b...@signedness.org wrote:
>> > No, we came to an VMS group that already discussed the vulnerabilities
>> > that we found and claimed that they were lies and a hoax.
>>
>> Initially, you were unable to explain this issue in terms that were
>> credible because you spoke "chinese" with terms that are foreign to VMS.
>>
>> > We are sorry that we assumed that you guys
>> > knew what shellcode was, it is a common used description in SECURITY
>>
>> Your message sounded like you had found a Unix bug in VMS and knew
>> nothing of VMS, so it is perfectly normal that many doubted you were
>> legit since you were unable to give details we could understand
>> initially. It took a lot of discussion and a translator to give us a
>> clue on what the actual vulnerability was.
>>
>> > It is laughable that there are still people working with security
>> > in IT that does not know what shellcode is.
>>
>> VMS has not had many security hackers in the last couple of decades, so
>> you are correct that we don't know about all the terminology used by
>> hackers.
>>
>> we don't use the term "shell" in VMS, and to us, it means someone coming
>> from Unixland, and it refers to the shell (in VMS terms, DCL, or in Unix
>> terms Bash etc). Shellcode would then be seen as shell scripts.
>>
>> > There was attempts to try to clarify this, for example by Simon
>> > Clubley:
>>
>> Correct. And after we were able to translate "shellcode" into something
>> meaningful like "machine code", then we could understand what you were
>> talking about. Had you begun with "machine code", then there would have
>> been less confusion.
>>
>> Also, initially, it was assumed you were talking about DCL. But it is
>> only once it was revealed that you needed to be inside an application
>> that uses the CLI routines that things started to fall into place.
>>
>> > That is exactly what we did, except that we used "address to jump to"
>> > and
>> > "return address" instead of "followed by four bytes". I'm not even
>> > going
>> > to quote that post.
>>
>> YOu did not state it in those terms. You used terms like shellcode. And
>> you also mixed in the finger thing which confused a lot since it appears
>> to be a totally separate problem.
>>
>> > But that was obviously not clear enough, since we are not VMS-people,
>> > and theirfore can not be fully trusted:
>>
>> Please understand that this is a fairly small community and when some
>> newcomer comes in with some fantastic claims, there is to be some
>> serious questioning to establish the credibility of that person, and
>> since you did not know VMS terminology, it was hard to take you so
>> seriously.
>>
>> > VAXman did not even bother to watch the videos, he continued to
>> > mess with DCL even though we nicely pointed out that the bug
>> > was located elsewhere. He also did not listen to us when we explained
>> > why FILE.EXE is used.
>>
>> It was pointed to you that the codecs used in the videos are
>> non-standard and cannot be watched by everyone. I also didn't even
>> bother to download them.
>>
>> Your introduction of FILE.EXE was absolutely confusing. This was not
>> necessary. And reduced your credibility because it put the focus on the
>> "file.exe" instead of on the actual vulnerability.
>>
>> You should have stuck to "enter 511 bytes, up up up, and a 4 byte binary
>> value, and the application will then branch to that binary value, and
>> any code located there runs with whatever privileges the application had
>> enabled at that time.
>>
>> Then, you could have introduced the concept of branching to some machine
>> code stored in memory via a logical name. And then the concept of that
>> machine code using SYS$CREPRC to create a suboprocess which has
>> inherited whatecer privileges were enabled inside of the main  
>> application.
>>
>> The way you presented it initially appeared to be a mismash of various
>> random terms that didn't apply to VMS, and made us even doubt that when
>> you used "logical" you really meant a VMS logical name. Mentioning that
>> the logical was created in the process logical name table would have
>> assured us you knew what a logical name was. (this is a concept foreign
>> to unix and DOS/windows).
>>
>> > It is not irrelevant when trying to describe what the exploit actually
>> > does,
>>
>> Your implementation is not really necessary. Mentioning that an
>> installed image can be made to branch to any random location in memory
>> which can potentially execute your own code is sufficient to get most fo
>> the folks here to understand the real problem.
>>
>> Also, I beleive that someone mentioned "crash the system". �But it is
>> really crash the application. Again, terminology that made the issue
>> lose credibility.
>>
>> > obviously there are people that have a great trouble understanding the
>> > basics of the exploit since questions with trivial answers has been
>> > repeated
>> > all over the thread.
>>
>> Now that it has been explained in terms we understand, we understand the
>> problem.
>>
>> > In fact, we know very little about the system itself, we find
>> > vulnerabilities and write PoC code to proof that the vulnerabilities
>> > exist.
>>
>> And this is why it was hard for many of us to take you seriously.
>> Remember that you barged into a small community with a "the theatre is
>> on fire" and then used language that made it look like you thought the
>> theratre was on fire because you saw a blinking light.
>>
>> I think you assumed everyone knew your terminology and that is why
>> things turned sour. Just be aware of that next time you find a problem
>> with an OS with which you are not familiar.
>>
>> > people trying to secure your system you should perhaps be a bit humble
>> > and TRY to understand so that problems can be solved.
>>
>> The next step is for you to spill the beans on exactly whom you
>> contacted at HP so that we can try to find out if HP is taking thsi
>> seriously or not. Contrary to Linux, we can't fix bugs that are found
>> and depend on a dwindling supply of VMS engineers
>> �to fix them and depend on some not so great managemenet to decide to
>> release it or not.
>
> Ok, well again..
>
> 1) We didn't come in here with "fantastic claims". Someone showed us
> this thread, and we replied because people were insinuated that we
> were full of shit.. We presented a couple of vulnerabilities we found
> in VMS at security conference that ~8500 people attended. We gave you
> videos demonstrating one of the bugs (let us know if someone wants the
> finger exploit vid btw), we also offered to demonstrate the exploit
> live. Shouldn't that at least give us SOME credibility??
>
> 2) Again with the terminology... When talking about security it make
> sense to use security terminology, if you don't understand something,
> then either google it or ask rather than assume..
>
> 3) We brought up finger because people were talking about it and
> getting that wrong too
>
> 4) Someone may have mention "crash the system" but it wasn't us
>
> 5) We didn't barge in screaming the theatre is on fire.. We talked
> about a few vulnerabilities at a conference and gave a few demos.
> People that didn't see the presentation or even the material assumed
> we were idiots and/or bullshitting about the vulnerabilities..
>
> Fair enough, VMS users may not be used to receiving bug reports or
> deal with security vulnerabilities, the rest I don't buy... I
> recommend you change your attitudes though, and don't put people off
> from reporting them because there are LOTS of them..
>
> We contacted security-alert@hp.com , as far as I can understand they
> assigned a person to the case and at least one other HP person was
> cc'd in on the communication until they stopped replying (I don't
> think it is necessary to out their names)..
>
I have been following this discussion a bit.  Is it correct to assume that
what is going on is overflowing a presumed 512 byte buffer with a presumed
null-terminated string as the first step in the exploit, and this is in  
SMG?

As for terminology, payload is certainly better than shellcode.



-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/17/2008 10:16:11 PM
On Aug 16, 12:01 pm, b...@signedness.org wrote:
> On Aug 16, 4:26 am, Hein RMS van den Heuvel
>
>
>
> <heinvandenheu...@gmail.com> wrote:
> > On Aug 15, 8:37 pm, VAXman-  @SendSpamHere.ORG wrote:
>
> > > In article <g855hs$d4...@charm.magnus.acs.ohio-state.edu>, JON...@ecr=
6.ohio-state.edu (David Jones) writes:
>
> > > >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegr=
oups.com>,
> > > >  b...@signedness.org writes:
> > > >>To find the address of a logical you can write a small program that
> > :
> > > I fail to see why this code, if it can be executed, must be stored in=
 a
> > > logical name block's translation region which may be somewhat arduous=
 to
> > > locate
>
> > Best I understand this, the hack needs any address which can be
> > expressed with a series of ASCII expressable address mappings and
> > survives image activation.
> > Logical names are stored in Process Allocation Region (P1 Pool) which
> > typically starts at (sysgen param dependend) 7Fxxxxxx. So you would
> > use a '~' for a first char. When I tried one, it started at
> > "7FF565A0". That F5 would be hard to express. So you would need many
> > more logicals to eat up space.
> > An other good zone could be the the Process I/O Segment (PIO). A first
> > test showed a buffer at 07B0B4400 ($open x login.com $read x y...
> > $ANAL/SYS... SHOW PROC/RMS=3D(BDBSUM,PIO). If you open a relative fiel
> > with bucket size of 60 or so, then you can make the system read 30KB
> > of 'stuff' into p1 space.
>
> > For a quick address overview: SDA> CLUE PROC/LAYOUT
>
> > fwiw,
> > Hein.
>
> Still fighting jetlag but I'm back to comment on a few things... (some
> things another presenter already pointed out but they are worth saying
> again)..
>
> 1) People complaining about our terminology.. Well here is the thing,
> our material was presented at a SECURITY conference so it  makes sense
> to use recognised security terminology, don't you think?
>
> 2) Insinuations that we are bullshitting.. Well thats just hilarious
> coming from people by their own admission triggered one of the bugs
> (R.A.Omond you may want to read the teso paper on exploiting format
> string vulnerabilities to understand the output you are getting from
> finger)
>
> 3) Sampsa and johnwalla...@yahoo.co.uk seems to have gotten it mostly
> right.
>
> To johnwalla...@yahoo.co.uk and Jan-Erik S=F6derholm, the reason why you
> see the access violation in the exploit video is not that the exploit
> isn't working, the shellcode is executed and executes FILE.EXE.
> However since we have trashed the stackframe it crashes when it tries
> to return from the already executed shellcode. The reason you don't
> often see similar behavior in UNIX exploits is that they often use a
> shellcode that executes a shell with the execve() system call.
> execve() replaces the process image and never returns if sucessful.. I
> hope that clears that up.
>
> 4) "There is no such thing as "shellcode" in VMS".. Well shellcode is
> platform neutral terminology, and while there might not be any public
> VMS shellcodes we certainly have a few..
>
> 5) JF Mezei, yes we know about the exit() function.. But it would have
> to be called from the shellcode written in assembler, and as already
> mentioned it would only be a cosmetic thing since the injected code
> already been executed. Do YOU know the openvms calling standard on the
> affected platforms? We just didn't think it was worth the effort.. IF
> YOU feel it is worth the effort, then you are free to write you own
> exploit... We never claimed to be VMS experts, infact one of the first
> thing we mention in the talk is that we are NOT.. However exploiting
> these bugs are hardly rocket science (again at some point I believe we
> mentioned that we found it interesting/surprising that such simple
> bugs still existed in a supposedly secure OS)... For your complaint
> about our terminology see 1)...
> =A8
> The comment that fair amount of experience with OpenVMS is required to
> find these bugs is laughable, we had absolutely none when we started
> looking for bugs. Fair enough there were some obstacles to overcome,
> like pretty poor debugging environments, tools not working the way we
> are used to, having to read up on VAX and Alpha asm etc. But in the
> end an overflow is still an overflow and a format string bug is still
> a format string bug and if you exploited things like that for the last
> 10 year or so its not terribly hard to adapt to a new environment. I
> think your comment says more about the attitudes in the VMS community
> than it says about our lack of experience with VMS.
>
> 6) Bradhamilton, yes we contacted the right people. Had a short dialog
> with them and then they stopped replying. The two finger bugs we
> exploited are local priv escalation bugs (well the format string bug
> anyway). The remote fingerd bug reported by someone at NGS we have not
> looked at so I can not really comment on that one.. At least on VAX it
> most likely depends on the C function causing the overflow and the
> ability of writing NULL bytes, and on alpha I'd assume there would be
> some interesting problem to solve too..
>
> 7) Hein RMS van den Heuvel. Don't know if you seen the video, but the
> problem with typing in return address composed of "weird" characters
> is why we use a homebrewed telnet client.
>
> 8) FrankS. Congrats on reproducing it!
>
> 9) Wilm Boerhout, well buddy.. We already stated that we won't release
> any exploits at least until HP released a fix and people had a chance
> to patch. The finger bug several people here managed to reproduce, in
> some cases even without realising themselves! See 2).
>
> How is that for not being able to recognise a naked, dancing security
> bug on your head?
>
> The cmdline stuff have now been reproduced by FrankS. On top of that
> we are offering to DEMO the exploit LIVE for anyone that is able to
> meet up with us.... Maybe you rather want us to release a working
> exploit before patches are out.. We will keep that in mind for the
> next set of bugs, maybe you also like to share the IP addresses of
> your VMS boxes so we can include them in the exploit code for demo
> purposes? </sarcasm>
>
> 10) For the naysayers... We already stated that we are not releasing
> an exploit for this issue at least not until HP patched it and people
> had a chance to patch. Judging from some email address, there are
> people from the UK here.. You are all welcome to visit a dc4420
> meeting and I'll DEMO the exploit for you LIVE (no video)... Also we
> are visiting Stockholm in September so assuming he can make it, We'd
> be happy to show Jan-Erik S=F6derholm or any other Swedish naysayers a
> live demo.
>
> 11) Finally... It is pretty interesting to see peoples reaction to
> this.. 2 out of 3 PRESENTED issues seems to have been independently
> verified now. Yet, we are not believed, told to go fuck ourselves,
> doubted and more or less called liars.. I can understand some healthy
> scepticism, but maybe you also have some of that to spare for claims
> of OpenVMS "superior security"...but if you rather take the
> comfortable "head in sand" position then thats fine by me as long as
> you don't host any of my data.

Been away over the weekend, just catching up, not going to comment on
the techy stuff as you now seem to have convinced those here who
needed convincing, which is good, and the details are now clear enough
(which is arguably not so good, but hey). Hopefully those in HP who
needed convincing already were convinced and are suitably motivated to
be in the process of fixing it.

Which just leaves me to add...

> "I think your comment says more about the attitudes in the VMS community
> than it says about our lack of experience with VMS."

Does any of this discussion say anything worthwhile about attitudes in
the broader VMS community (ie including the invisible ones, not just
contributors here)? Not sure it does. But thank you (from me at least)
for the wake up call.
0
8/17/2008 10:31:32 PM
In message <op.uf1xg90bhv4qyg@murphus.hsd1.ca.comcast.net>
  "Tom Linden" <tom@kednos.company> writes:
>I have been following this discussion a bit.  Is it correct to assume that
>what is going on is overflowing a presumed 512 byte buffer with a presumed
>null-terminated string as the first step in the exploit, and this is in
>SMG?

SMG is written in BLISS. and the code in question (if I've analyzed it
correctly) is not overflowing the buffer because a null is missing.  It
reserved space for a 5 character escape sequence and doesn't do ANY limit
check (though possibly wrapping at 65K).  The bug has probably been in the
code longer than DEFCONs have been around.



David L. Jones               |      Phone:    (614) 271-6718
Ohio State University        |      Internet:
140 W. 19th St.              |               jonesd@ecr6.ohio-state.edu
Columbus, OH 43210           |               vman+@osu.edu

Disclaimer: I'm looking for marbles all day long.
0
JONESD2 (40)
8/17/2008 11:18:58 PM
Hi "bugs",

>>>>>>>>>>>>>>>>>>
11) Finally... It is pretty interesting to see peoples reaction to
this.. 2 out of 3 PRESENTED issues seems to have been independently
verified now. Yet, we are not believed, told to go fuck ourselves,
doubted and more or less called liars.. I can understand some healthy
scepticism, but maybe you also have some of that to spare for claims
of OpenVMS "superior security"...but if you rather take the
comfortable "head in sand" position then thats fine by me as long as
you don't host any of my data.
<<<<<<<<<<<<<<<<<<<<

Being realtively new to VMS you're probably also new to comp.os.vms. You
must understand that you're presentation skills, grammer, spelling and color
choices are evryting here, and the substance you post often deemed
irrelevant. (Just lucky you didn't top-post or you would've been kill-filed
on principle :-)

There are pecking-orders, mutual-admiration societies, and
poisonous-cliques, to be maintained and etiquette is paramount. (A
philosophy, organizational-structure, and attitude based soley on VMS
Middle-management's own.)

Science and technology are rarely discussed in this forum anymore and
certainly not with the same passion reserved for global-warming,
us-politics, or "the good ol' days". In fact, any discussion of "the outside
world" tends to unsettle the residents so it'd be really helpful if you
could keep such loose-talk to a minimum.

Ousiders, tall-poppies, in fact anyone who doesn't share the same 95% of
chromosomes and has been kissing the usual Digital arses for 25 years will
be treated with the same distain from the royal order of xenophobic
banjo-pluckers. This vulnerability was clearly for one of The Annointed to
discover and one really must know one's place :-(

Anyway, if nothing else, I for one am grateful for the interest this has
once again generated in VMS! (And please continue *your* interest
in what, I sure you'll discover, is still the best server os on the market.)
And if there are more vulnerabilities and exploits out there then please
throw them up so that someone can swat them.

Well done!

Regards Richard Maher

PS. Is the latest that this bug is being put down to smg$ and that any smg$
RTL-using image installed with privs in vulnerable? Yikes! How long d'ya
reakon that hole has been open?

<bugs@signedness.org> wrote in message
news:ad17ec3e-cab9-476f-ba1e-34118a632598@c58g2000hsc.googlegroups.com...
On Aug 16, 4:26 am, Hein RMS van den Heuvel
<heinvandenheu...@gmail.com> wrote:
> On Aug 15, 8:37 pm, VAXman- @SendSpamHere.ORG wrote:
>
> > In article <g855hs$d4...@charm.magnus.acs.ohio-state.edu>,
JON...@ecr6.ohio-state.edu (David Jones) writes:
>
> > >In message
<850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegroups.com>,
> > > b...@signedness.org writes:
> > >>To find the address of a logical you can write a small program that
> :
> > I fail to see why this code, if it can be executed, must be stored in a
> > logical name block's translation region which may be somewhat arduous to
> > locate
>
> Best I understand this, the hack needs any address which can be
> expressed with a series of ASCII expressable address mappings and
> survives image activation.
> Logical names are stored in Process Allocation Region (P1 Pool) which
> typically starts at (sysgen param dependend) 7Fxxxxxx. So you would
> use a '~' for a first char. When I tried one, it started at
> "7FF565A0". That F5 would be hard to express. So you would need many
> more logicals to eat up space.
> An other good zone could be the the Process I/O Segment (PIO). A first
> test showed a buffer at 07B0B4400 ($open x login.com $read x y...
> $ANAL/SYS... SHOW PROC/RMS=(BDBSUM,PIO). If you open a relative fiel
> with bucket size of 60 or so, then you can make the system read 30KB
> of 'stuff' into p1 space.
>
> For a quick address overview: SDA> CLUE PROC/LAYOUT
>
> fwiw,
> Hein.

Still fighting jetlag but I'm back to comment on a few things... (some
things another presenter already pointed out but they are worth saying
again)..

1) People complaining about our terminology.. Well here is the thing,
our material was presented at a SECURITY conference so it  makes sense
to use recognised security terminology, don't you think?

2) Insinuations that we are bullshitting.. Well thats just hilarious
coming from people by their own admission triggered one of the bugs
(R.A.Omond you may want to read the teso paper on exploiting format
string vulnerabilities to understand the output you are getting from
finger)

3) Sampsa and johnwalla...@yahoo.co.uk seems to have gotten it mostly
right.

To johnwalla...@yahoo.co.uk and Jan-Erik S�derholm, the reason why you
see the access violation in the exploit video is not that the exploit
isn't working, the shellcode is executed and executes FILE.EXE.
However since we have trashed the stackframe it crashes when it tries
to return from the already executed shellcode. The reason you don't
often see similar behavior in UNIX exploits is that they often use a
shellcode that executes a shell with the execve() system call.
execve() replaces the process image and never returns if sucessful.. I
hope that clears that up.

4) "There is no such thing as "shellcode" in VMS".. Well shellcode is
platform neutral terminology, and while there might not be any public
VMS shellcodes we certainly have a few..

5) JF Mezei, yes we know about the exit() function.. But it would have
to be called from the shellcode written in assembler, and as already
mentioned it would only be a cosmetic thing since the injected code
already been executed. Do YOU know the openvms calling standard on the
affected platforms? We just didn't think it was worth the effort.. IF
YOU feel it is worth the effort, then you are free to write you own
exploit... We never claimed to be VMS experts, infact one of the first
thing we mention in the talk is that we are NOT.. However exploiting
these bugs are hardly rocket science (again at some point I believe we
mentioned that we found it interesting/surprising that such simple
bugs still existed in a supposedly secure OS)... For your complaint
about our terminology see 1)...
�
The comment that fair amount of experience with OpenVMS is required to
find these bugs is laughable, we had absolutely none when we started
looking for bugs. Fair enough there were some obstacles to overcome,
like pretty poor debugging environments, tools not working the way we
are used to, having to read up on VAX and Alpha asm etc. But in the
end an overflow is still an overflow and a format string bug is still
a format string bug and if you exploited things like that for the last
10 year or so its not terribly hard to adapt to a new environment. I
think your comment says more about the attitudes in the VMS community
than it says about our lack of experience with VMS.

6) Bradhamilton, yes we contacted the right people. Had a short dialog
with them and then they stopped replying. The two finger bugs we
exploited are local priv escalation bugs (well the format string bug
anyway). The remote fingerd bug reported by someone at NGS we have not
looked at so I can not really comment on that one.. At least on VAX it
most likely depends on the C function causing the overflow and the
ability of writing NULL bytes, and on alpha I'd assume there would be
some interesting problem to solve too..

7) Hein RMS van den Heuvel. Don't know if you seen the video, but the
problem with typing in return address composed of "weird" characters
is why we use a homebrewed telnet client.

8) FrankS. Congrats on reproducing it!


9) Wilm Boerhout, well buddy.. We already stated that we won't release
any exploits at least until HP released a fix and people had a chance
to patch. The finger bug several people here managed to reproduce, in
some cases even without realising themselves! See 2).

How is that for not being able to recognise a naked, dancing security
bug on your head?

The cmdline stuff have now been reproduced by FrankS. On top of that
we are offering to DEMO the exploit LIVE for anyone that is able to
meet up with us.... Maybe you rather want us to release a working
exploit before patches are out.. We will keep that in mind for the
next set of bugs, maybe you also like to share the IP addresses of
your VMS boxes so we can include them in the exploit code for demo
purposes? </sarcasm>


10) For the naysayers... We already stated that we are not releasing
an exploit for this issue at least not until HP patched it and people
had a chance to patch. Judging from some email address, there are
people from the UK here.. You are all welcome to visit a dc4420
meeting and I'll DEMO the exploit for you LIVE (no video)... Also we
are visiting Stockholm in September so assuming he can make it, We'd
be happy to show Jan-Erik S�derholm or any other Swedish naysayers a
live demo.

11) Finally... It is pretty interesting to see peoples reaction to
this.. 2 out of 3 PRESENTED issues seems to have been independently
verified now. Yet, we are not believed, told to go fuck ourselves,
doubted and more or less called liars.. I can understand some healthy
scepticism, but maybe you also have some of that to spare for claims
of OpenVMS "superior security"...but if you rather take the
comfortable "head in sand" position then thats fine by me as long as
you don't host any of my data.


0
maher_rj (1626)
8/17/2008 11:19:47 PM
Hi

<<<<<<<<<<<<<<<<<<<
We contacted security-alert@hp.com , as far as I can understand they
assigned a person to the case and at least one other HP person was
cc'd in on the communication until they stopped replying (I don't
think it is necessary to out their names)..
>>>>>>>>>>>>>>>>>>>

I'm guessing patches, regression-testing,  and kitting take time, but if you
have seen a legitimate security hole report ignored or fobbed-off then I
think it is absolutely necessary that you out their names! God knows
something has to change in that place; every little helps.

Regards Richard Maher

PS. I think just a little more boastfulness and triumphalism might really
help things :-)

<bugs@signedness.org> wrote in message
news:94b9759b-b765-47ff-8d40-72509fee0bed@a70g2000hsh.googlegroups.com...
On Aug 17, 7:11 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> b...@signedness.org wrote:
> > No, we came to an VMS group that already discussed the vulnerabilities
> > that we found and claimed that they were lies and a hoax.
>
> Initially, you were unable to explain this issue in terms that were
> credible because you spoke "chinese" with terms that are foreign to VMS.
>
> > We are sorry that we assumed that you guys
> > knew what shellcode was, it is a common used description in SECURITY
>
> Your message sounded like you had found a Unix bug in VMS and knew
> nothing of VMS, so it is perfectly normal that many doubted you were
> legit since you were unable to give details we could understand
> initially. It took a lot of discussion and a translator to give us a
> clue on what the actual vulnerability was.
>
> > It is laughable that there are still people working with security
> > in IT that does not know what shellcode is.
>
> VMS has not had many security hackers in the last couple of decades, so
> you are correct that we don't know about all the terminology used by
> hackers.
>
> we don't use the term "shell" in VMS, and to us, it means someone coming
> from Unixland, and it refers to the shell (in VMS terms, DCL, or in Unix
> terms Bash etc). Shellcode would then be seen as shell scripts.
>
> > There was attempts to try to clarify this, for example by Simon
> > Clubley:
>
> Correct. And after we were able to translate "shellcode" into something
> meaningful like "machine code", then we could understand what you were
> talking about. Had you begun with "machine code", then there would have
> been less confusion.
>
> Also, initially, it was assumed you were talking about DCL. But it is
> only once it was revealed that you needed to be inside an application
> that uses the CLI routines that things started to fall into place.
>
> > That is exactly what we did, except that we used "address to jump to"
> > and
> > "return address" instead of "followed by four bytes". I'm not even
> > going
> > to quote that post.
>
> YOu did not state it in those terms. You used terms like shellcode. And
> you also mixed in the finger thing which confused a lot since it appears
> to be a totally separate problem.
>
> > But that was obviously not clear enough, since we are not VMS-people,
> > and theirfore can not be fully trusted:
>
> Please understand that this is a fairly small community and when some
> newcomer comes in with some fantastic claims, there is to be some
> serious questioning to establish the credibility of that person, and
> since you did not know VMS terminology, it was hard to take you so
> seriously.
>
> > VAXman did not even bother to watch the videos, he continued to
> > mess with DCL even though we nicely pointed out that the bug
> > was located elsewhere. He also did not listen to us when we explained
> > why FILE.EXE is used.
>
> It was pointed to you that the codecs used in the videos are
> non-standard and cannot be watched by everyone. I also didn't even
> bother to download them.
>
> Your introduction of FILE.EXE was absolutely confusing. This was not
> necessary. And reduced your credibility because it put the focus on the
> "file.exe" instead of on the actual vulnerability.
>
> You should have stuck to "enter 511 bytes, up up up, and a 4 byte binary
> value, and the application will then branch to that binary value, and
> any code located there runs with whatever privileges the application had
> enabled at that time.
>
> Then, you could have introduced the concept of branching to some machine
> code stored in memory via a logical name. And then the concept of that
> machine code using SYS$CREPRC to create a suboprocess which has
> inherited whatecer privileges were enabled inside of the main application.
>
> The way you presented it initially appeared to be a mismash of various
> random terms that didn't apply to VMS, and made us even doubt that when
> you used "logical" you really meant a VMS logical name. Mentioning that
> the logical was created in the process logical name table would have
> assured us you knew what a logical name was. (this is a concept foreign
> to unix and DOS/windows).
>
> > It is not irrelevant when trying to describe what the exploit actually
> > does,
>
> Your implementation is not really necessary. Mentioning that an
> installed image can be made to branch to any random location in memory
> which can potentially execute your own code is sufficient to get most fo
> the folks here to understand the real problem.
>
> Also, I beleive that someone mentioned "crash the system". But it is
> really crash the application. Again, terminology that made the issue
> lose credibility.
>
> > obviously there are people that have a great trouble understanding the
> > basics of the exploit since questions with trivial answers has been
> > repeated
> > all over the thread.
>
> Now that it has been explained in terms we understand, we understand the
> problem.
>
> > In fact, we know very little about the system itself, we find
> > vulnerabilities and write PoC code to proof that the vulnerabilities
> > exist.
>
> And this is why it was hard for many of us to take you seriously.
> Remember that you barged into a small community with a "the theatre is
> on fire" and then used language that made it look like you thought the
> theratre was on fire because you saw a blinking light.
>
> I think you assumed everyone knew your terminology and that is why
> things turned sour. Just be aware of that next time you find a problem
> with an OS with which you are not familiar.
>
> > people trying to secure your system you should perhaps be a bit humble
> > and TRY to understand so that problems can be solved.
>
> The next step is for you to spill the beans on exactly whom you
> contacted at HP so that we can try to find out if HP is taking thsi
> seriously or not. Contrary to Linux, we can't fix bugs that are found
> and depend on a dwindling supply of VMS engineers
> to fix them and depend on some not so great managemenet to decide to
> release it or not.

Ok, well again..

1) We didn't come in here with "fantastic claims". Someone showed us
this thread, and we replied because people were insinuated that we
were full of shit.. We presented a couple of vulnerabilities we found
in VMS at security conference that ~8500 people attended. We gave you
videos demonstrating one of the bugs (let us know if someone wants the
finger exploit vid btw), we also offered to demonstrate the exploit
live. Shouldn't that at least give us SOME credibility??

2) Again with the terminology... When talking about security it make
sense to use security terminology, if you don't understand something,
then either google it or ask rather than assume..

3) We brought up finger because people were talking about it and
getting that wrong too

4) Someone may have mention "crash the system" but it wasn't us

5) We didn't barge in screaming the theatre is on fire.. We talked
about a few vulnerabilities at a conference and gave a few demos.
People that didn't see the presentation or even the material assumed
we were idiots and/or bullshitting about the vulnerabilities..

Fair enough, VMS users may not be used to receiving bug reports or
deal with security vulnerabilities, the rest I don't buy... I
recommend you change your attitudes though, and don't put people off
from reporting them because there are LOTS of them..

We contacted security-alert@hp.com , as far as I can understand they
assigned a person to the case and at least one other HP person was
cc'd in on the communication until they stopped replying (I don't
think it is necessary to out their names)..




0
maher_rj (1626)
8/17/2008 11:25:06 PM
%%%%%%%%%%%%%Message from Opcom

It makes no sense to be pissin' off the hackers over credentials, 
terminology, and the vernacular. If something has been found that needs 
attention, and they're decent enough to try to get HP to fix it and in 
the same sentence don't want to reveal the naughty details publicly 
until a patch has been released, then what's the beef with them? One 
does not have to be a car mechanic to put a skunk in the trunk, nor a 
plumber to hide an opossum in the potty. One just has to figure out a 
way to do it and then stand back and watch the youtube moment. Ok bad 
analogies.

This whole discussion is extremely interesting and the contributors are 
too diverse to waste storage and bandwidth making negative comments over 
the many specific credentials, words, and grammar.
0
eccm (54)
8/18/2008 12:17:32 AM
On Sun, 17 Aug 2008 16:18:58 -0700, David Jones  
<JONESD@ecr6.ohio-state.edu> wrote:

> SMG is written in BLISS. and the code in question (if I've analyzed it
> correctly) is not overflowing the buffer because a null is missing.  It
> reserved space for a 5 character escape sequence and doesn't do ANY limit
> check (though possibly wrapping at 65K).  The bug has probably been in  
> the
> code longer than DEFCONs have been around.

Which module and line number in the listings?

-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/18/2008 12:35:38 AM
On Aug 18, 12:25=A0am, "Richard Maher" <maher...@hotspamnotmail.com>
wrote:
> Hi
>
> <<<<<<<<<<<<<<<<<<<
> We contacted security-al...@hp.com , as far as I can understand they
> assigned a person to the case and at least one other HP person was
> cc'd in on the communication until they stopped replying (I don't
> think it is necessary to out their names)..
>
>
>
> I'm guessing patches, regression-testing, =A0and kitting take time, but i=
f you
> have seen a legitimate security hole report ignored or fobbed-off then I
> think it is absolutely necessary that you out their names! God knows
> something has to change in that place; every little helps.
>
> Regards Richard Maher
>
> PS. I think just a little more boastfulness and triumphalism might really
> help things :-)
>
> <b...@signedness.org> wrote in message
>
> news:94b9759b-b765-47ff-8d40-72509fee0bed@a70g2000hsh.googlegroups.com...
> On Aug 17, 7:11 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
>
>
> > b...@signedness.org wrote:
> > > No, we came to an VMS group that already discussed the vulnerabilitie=
s
> > > that we found and claimed that they were lies and a hoax.
>
> > Initially, you were unable to explain this issue in terms that were
> > credible because you spoke "chinese" with terms that are foreign to VMS=
..
>
> > > We are sorry that we assumed that you guys
> > > knew what shellcode was, it is a common used description in SECURITY
>
> > Your message sounded like you had found a Unix bug in VMS and knew
> > nothing of VMS, so it is perfectly normal that many doubted you were
> > legit since you were unable to give details we could understand
> > initially. It took a lot of discussion and a translator to give us a
> > clue on what the actual vulnerability was.
>
> > > It is laughable that there are still people working with security
> > > in IT that does not know what shellcode is.
>
> > VMS has not had many security hackers in the last couple of decades, so
> > you are correct that we don't know about all the terminology used by
> > hackers.
>
> > we don't use the term "shell" in VMS, and to us, it means someone comin=
g
> > from Unixland, and it refers to the shell (in VMS terms, DCL, or in Uni=
x
> > terms Bash etc). Shellcode would then be seen as shell scripts.
>
> > > There was attempts to try to clarify this, for example by Simon
> > > Clubley:
>
> > Correct. And after we were able to translate "shellcode" into something
> > meaningful like "machine code", then we could understand what you were
> > talking about. Had you begun with "machine code", then there would have
> > been less confusion.
>
> > Also, initially, it was assumed you were talking about DCL. But it is
> > only once it was revealed that you needed to be inside an application
> > that uses the CLI routines that things started to fall into place.
>
> > > That is exactly what we did, except that we used "address to jump to"
> > > and
> > > "return address" instead of "followed by four bytes". I'm not even
> > > going
> > > to quote that post.
>
> > YOu did not state it in those terms. You used terms like shellcode. And
> > you also mixed in the finger thing which confused a lot since it appear=
s
> > to be a totally separate problem.
>
> > > But that was obviously not clear enough, since we are not VMS-people,
> > > and theirfore can not be fully trusted:
>
> > Please understand that this is a fairly small community and when some
> > newcomer comes in with some fantastic claims, there is to be some
> > serious questioning to establish the credibility of that person, and
> > since you did not know VMS terminology, it was hard to take you so
> > seriously.
>
> > > VAXman did not even bother to watch the videos, he continued to
> > > mess with DCL even though we nicely pointed out that the bug
> > > was located elsewhere. He also did not listen to us when we explained
> > > why FILE.EXE is used.
>
> > It was pointed to you that the codecs used in the videos are
> > non-standard and cannot be watched by everyone. I also didn't even
> > bother to download them.
>
> > Your introduction of FILE.EXE was absolutely confusing. This was not
> > necessary. And reduced your credibility because it put the focus on the
> > "file.exe" instead of on the actual vulnerability.
>
> > You should have stuck to "enter 511 bytes, up up up, and a 4 byte binar=
y
> > value, and the application will then branch to that binary value, and
> > any code located there runs with whatever privileges the application ha=
d
> > enabled at that time.
>
> > Then, you could have introduced the concept of branching to some machin=
e
> > code stored in memory via a logical name. And then the concept of that
> > machine code using SYS$CREPRC to create a suboprocess which has
> > inherited whatecer privileges were enabled inside of the main applicati=
on.
>
> > The way you presented it initially appeared to be a mismash of various
> > random terms that didn't apply to VMS, and made us even doubt that when
> > you used "logical" you really meant a VMS logical name. Mentioning that
> > the logical was created in the process logical name table would have
> > assured us you knew what a logical name was. (this is a concept foreign
> > to unix and DOS/windows).
>
> > > It is not irrelevant when trying to describe what the exploit actuall=
y
> > > does,
>
> > Your implementation is not really necessary. Mentioning that an
> > installed image can be made to branch to any random location in memory
> > which can potentially execute your own code is sufficient to get most f=
o
> > the folks here to understand the real problem.
>
> > Also, I beleive that someone mentioned "crash the system". But it is
> > really crash the application. Again, terminology that made the issue
> > lose credibility.
>
> > > obviously there are people that have a great trouble understanding th=
e
> > > basics of the exploit since questions with trivial answers has been
> > > repeated
> > > all over the thread.
>
> > Now that it has been explained in terms we understand, we understand th=
e
> > problem.
>
> > > In fact, we know very little about the system itself, we find
> > > vulnerabilities and write PoC code to proof that the vulnerabilities
> > > exist.
>
> > And this is why it was hard for many of us to take you seriously.
> > Remember that you barged into a small community with a "the theatre is
> > on fire" and then used language that made it look like you thought the
> > theratre was on fire because you saw a blinking light.
>
> > I think you assumed everyone knew your terminology and that is why
> > things turned sour. Just be aware of that next time you find a problem
> > with an OS with which you are not familiar.
>
> > > people trying to secure your system you should perhaps be a bit humbl=
e
> > > and TRY to understand so that problems can be solved.
>
> > The next step is for you to spill the beans on exactly whom you
> > contacted at HP so that we can try to find out if HP is taking thsi
> > seriously or not. Contrary to Linux, we can't fix bugs that are found
> > and depend on a dwindling supply of VMS engineers
> > to fix them and depend on some not so great managemenet to decide to
> > release it or not.
>
> Ok, well again..
>
> 1) We didn't come in here with "fantastic claims". Someone showed us
> this thread, and we replied because people were insinuated that we
> were full of shit.. We presented a couple of vulnerabilities we found
> in VMS at security conference that ~8500 people attended. We gave you
> videos demonstrating one of the bugs (let us know if someone wants the
> finger exploit vid btw), we also offered to demonstrate the exploit
> live. Shouldn't that at least give us SOME credibility??
>
> 2) Again with the terminology... When talking about security it make
> sense to use security terminology, if you don't understand something,
> then either google it or ask rather than assume..
>
> 3) We brought up finger because people were talking about it and
> getting that wrong too
>
> 4) Someone may have mention "crash the system" but it wasn't us
>
> 5) We didn't barge in screaming the theatre is on fire.. We talked
> about a few vulnerabilities at a conference and gave a few demos.
> People that didn't see the presentation or even the material assumed
> we were idiots and/or bullshitting about the vulnerabilities..
>
> Fair enough, VMS users may not be used to receiving bug reports or
> deal with security vulnerabilities, the rest I don't buy... I
> recommend you change your attitudes though, and don't put people off
> from reporting them because there are LOTS of them..
>
> We contacted security-al...@hp.com , as far as I can understand they
> assigned a person to the case and at least one other HP person was
> cc'd in on the communication until they stopped replying (I don't
> think it is necessary to out their names)..

Hi, thanks for your your support.. :) I don't think we have to be more
boastful. Seems that people starting to accept that even VMS have
really simple bugs and I'm sure this will lead to more people looking
at VMS security. If that doesn't happen, well then we may have to
"come out of retirement" with more bugs..






0
bugs6 (57)
8/18/2008 12:49:31 AM
bugs@signedness.org wrote:

> boastful. Seems that people starting to accept that even VMS have
> really simple bugs and I'm sure this will lead to more people looking
> at VMS security. 

VMS has had plenty of bugs, especially with the TCPIP Services software.
 Some of this would require code changes to use different system
services to log authentication failures (which for some services isn't
done and allows brute force attacks to bypass the breakin evasion
systems on VMS.

One problem is that the people who get such reports don't have authority
to allocate whatever few resources are left to maintain VMS to get the
fixes done and released quickly.

My guess is that by bringing the issue here in the open, you may get a
few HP employees to ask their boss "what about that issue, have you
allocated any resources to fix it ?" and this may get something done.
0
8/18/2008 2:07:10 AM
On Aug 17, 10:09 pm, VAXman-  @SendSpamHere.ORG wrote:

> >It was pointed to you that the codecs used in the videos are
> >non-standard and cannot be watched by everyone. I also didn't even
> >bother to download them.
It is a VMWare recording for heavens sake (http://www.vmware.com)!
If you have bothered to download the videos you would probably not
have
played around with DCL commands and asked about FILE.EXE in the first
place.

> A cohesive explaination of reproducing the stack dump would have been
> better than some video of a terminal session.  There was also a report
> of no audio explaining what was happening in the video.
It is a VMWare recording (http://www.vmware.com/), it has no sound.
We used the videos in our presentation (and yes, we did actually
talk while playing them).

> >Your introduction of FILE.EXE was absolutely confusing. This was not
> >necessary. And reduced your credibility because it put the focus on the
> >"file.exe" instead of on the actual vulnerability.
>
> Another valid point.
Again, you did not watch the videos, i.e. you did not input all data
before computing.

You continue to claim that we have done things wrong when trying to
explain the vulnerability that you tried to wave away as a hoax. Your
attitude strongly imply that this has nothing to do with terminology
and codecs, but that your ego got bumped really hard, and you can not
handle it.
There is a bug for you to analyze.



0
bugs6 (57)
8/18/2008 2:58:10 AM
On Aug 17, 7:18=A0pm, JON...@ecr6.ohio-state.edu (David Jones) wrote:
>The bug has probably been in the
> code longer than DEFCONs have been around.

I just reproduced the problem on VMS v6.2 (VAX).

Anybody got a v5.5-2 or earlier running?
0
sapienza (410)
8/18/2008 3:03:51 AM
bugs@signedness.org wrote:

> played around with DCL commands and asked about FILE.EXE in the first
> place.

While battling headwids today on my bike, I was thinking about this.

You had machine code being executed as part of a utility like INSTALL.
This would be running inside that process and inherit all of the
process' profile. You mentioned that this machine code created a
subprocess with SYS$CREPRC, and that subprocess ran that FILE.EXE, correct ?


Now, if that subprocess was created to run FILE.EXE, it means that it
would not have a DCL environment below it, and not have access to many
functions.

What you could have done is create a subprocess that runs
SYS$SYSTEM:LOGINOUT.EXE with input being the current terminal device,
and output being the currnet terminal device (you would have then had
access to the $ sign and any DCL commands).

Alternatively, you could have had the input set to a file containing DCL
command (a command procedure (aka: unix shell script) and that command
procedure would have had full access to SHOW PROCESS/OUTPUT=xxx or RUN
FILE.EXE.

Finally, the machine code stub that you had "embedded" into the utility
in the mother process (via a logical name) would need to know a bit more
about how it is being called.

If the utility simply branches to your code, then your code would have
no way of knowing where to branch back once it has completed its work.
If the utility calls your code as a subroutine, then you could do all
you want inside your subroutine and return to the caller cleanly and let
the utility continue it merry way.

However, the utility might expect some results from that subroutine and
if your covert code-in-a-logical doesn't provide those results, the
mainline code from the utility might barf with some invalid data.

AKA: it would be pretty hard to make it appear totally transparent so
that the user would have no knowledge that something untowards was done
behind the scenes.


0
8/18/2008 3:19:06 AM
On Aug 18, 5:19 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> b...@signedness.org wrote:
> > played around with DCL commands and asked about FILE.EXE in the first
> > place.
>
> While battling headwids today on my bike, I was thinking about this.
>
> You had machine code being executed as part of a utility like INSTALL.
> This would be running inside that process and inherit all of the
> process' profile. You mentioned that this machine code created a
> subprocess with SYS$CREPRC, and that subprocess ran that FILE.EXE, correct ?
Yeah, correct.

> Now, if that subprocess was created to run FILE.EXE, it means that it
> would not have a DCL environment below it, and not have access to many
> functions.
>
> What you could have done is create a subprocess that runs
> SYS$SYSTEM:LOGINOUT.EXE with input being the current terminal device,
> and output being the currnet terminal device (you would have then had
> access to the $ sign and any DCL commands).
>
> Alternatively, you could have had the input set to a file containing DCL
> command (a command procedure (aka: unix shell script) and that command
> procedure would have had full access to SHOW PROCESS/OUTPUT=xxx or RUN
> FILE.EXE.
>
> Finally, the machine code stub that you had "embedded" into the utility
> in the mother process (via a logical name) would need to know a bit more
> about how it is being called.
>
> If the utility simply branches to your code, then your code would have
> no way of knowing where to branch back once it has completed its work.
> If the utility calls your code as a subroutine, then you could do all
> you want inside your subroutine and return to the caller cleanly and let
> the utility continue it merry way.
>
> However, the utility might expect some results from that subroutine and
> if your covert code-in-a-logical doesn't provide those results, the
> mainline code from the utility might barf with some invalid data.
>
> AKA: it would be pretty hard to make it appear totally transparent so
> that the user would have no knowledge that something untowards was done
> behind the scenes.

Interesting ideas, thanks a lot.
The calling standard for sub routines are not totally clear to us, but
it could be worth looking into further for a better exploit, thanks
again.

Btw, any suggestions on how to trigger this automatically without
using a custom telnet/ssh client?
Using popen() or an input file with lib$spawn does not work (popen()
is probably implemented using lib$spawn), because the input is not a
terminal why the vulnerable code is not used.
Is there a way to control another process locally like the expect
program does on Unix?
0
bugs6 (57)
8/18/2008 3:53:27 AM
In message <eb7f5d29-3975-440e-8359-61fc9ef25d68@l64g2000hse.googlegroups.com>,
   bugs@signedness.org writes:
>Btw, any suggestions on how to trigger this automatically without
>using a custom telnet/ssh client?

So your goal is to create a trojan horse program that secretly breaks in
when a non-privileged user runs it?

>Using popen() or an input file with lib$spawn does not work (popen()
>is probably implemented using lib$spawn), because the input is not a
>terminal why the vulnerable code is not used.

If SMG  doesn't think input is from an interactive terminal, there is no
editting so there is no need to try to interpret escape characters.

You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED
process to it.  The parent process controlling the terminal doesn't need to
supply a password and none of the dialog needs to be displayed.  Use the
exploit to grant that spawned process privileges and then just use that session
to do other things with the empowered process.


David L. Jones               |      Phone:    (614) 271-6718
Ohio State University        |      Internet:
140 W. 19th St.              |               jonesd@ecr6.ohio-state.edu
Columbus, OH 43210           |               vman+@osu.edu

Disclaimer: I'm looking for marbles all day long.
0
JONESD2 (40)
8/18/2008 5:10:19 AM
On Aug 16, 11:19=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> >Thanks for that important additional piece of information. I can now
> >reproduce it on my Alpha VMS 8.3 home system.
>
> Save that after further investigation, it's not DCL... it's in a shareabl=
e
> image. =A0The shareable and code has been identified.

I believe to have a full patch for this for Open Alpha VMS 8.3.
Caveat... this has had but 5 minutes of testing!

Patches for other versions should be much similar.
This is not just a workaround, like extending the buffer.
The patch  limits the max number of characters after an escape to 3
(or however many you like... which should be less than the 4 bytes
allocated).
It replaces a NOP, and some broken code, and with that an idle
register, to do its modest job.

$ dump/block=3D(count=3D1,start=3D124) sys$library:smgshr.exe;/
out=3Dsmgshr_original.dmp
$ copy/log sys$library:smgshr.exe; smgshr_patched.exe
$ patch  smgshr_patched.exe
define base=3D07c*200-200
deposit base+044 =3D 47E07401
deposit base+0ac =3D 40203121
deposit base+0b4 =3D 2FFE0000
deposit base+0d8 =3D 0E4200017
update
exit
$  dump/block=3D(count=3D1,start=3D124) smgshr_patched.exe; /
out=3Dsmgshr_patched.dmp

This should report:


old: 0000F644:  2FFE0000
new: 0000F644:  47E07401
old: 0000F6AC:  2020FDD4
new: 0000F6AC:  40203121
old: 0000F6B4:  441F0281
new: 0000F6B4:  2FFE0000
old: 0000F6D8:  0F4200017
new: 0000F6D8:  0E4200017

Now try your reproducer, or at least define smgshr to this patch image
and make sure it still work, with say MAIL, type/page, or pretty much
anything else.
When comfident move to SYS$LIBRARY.

hth,

Hein.
0
8/18/2008 5:17:53 AM
On Aug 18, 7:10 am, JON...@ecr6.ohio-state.edu (David Jones) wrote:
> In message <eb7f5d29-3975-440e-8359-61fc9ef25...@l64g2000hse.googlegroups.com>,
>    b...@signedness.org writes:
>
> >Btw, any suggestions on how to trigger this automatically without
> >using a custom telnet/ssh client?
>
> So your goal is to create a trojan horse program that secretly breaks in
> when a non-privileged user runs it?
Nah, we just want to make the exploit a little better.
If the intention was to create malicious software we would probably
have greater success if we did not report this vulnerability. :)

> You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED
> process to it.  The parent process controlling the terminal doesn't need to
> supply a password and none of the dialog needs to be displayed.  Use the
> exploit to grant that spawned process privileges and then just use that session
> to do other things with the empowered process.

Thank you!
We will look into this.
0
bugs6 (57)
8/18/2008 5:25:37 AM
On Aug 18, 4:19=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> b...@signedness.org wrote:
> > played around with DCL commands and asked about FILE.EXE in the first
> > place.
>
> While battling headwids today on my bike, I was thinking about this.
>
> You had machine code being executed as part of a utility like INSTALL.
> This would be running inside that process and inherit all of the
> process' profile. You mentioned that this machine code created a
> subprocess with SYS$CREPRC, and that subprocess ran that FILE.EXE, correc=
t ?
>
Correct.

> Now, if that subprocess was created to run FILE.EXE, it means that it
> would not have a DCL environment below it, and not have access to many
> functions.
>
> What you could have done is create a subprocess that runs
> SYS$SYSTEM:LOGINOUT.EXE with input being the current terminal device,
> and output being the currnet terminal device (you would have then had
> access to the $ sign and any DCL commands).
>
> Alternatively, you could have had the input set to a file containing DCL
> command (a command procedure (aka: unix shell script) and that command
> procedure would have had full access to SHOW PROCESS/OUTPUT=3Dxxx or RUN
> FILE.EXE.
>

Yes.. we were a bit lazy but the shellcode is easy to modify for
remote exploitation (just replace file.exe with suitable command to
run) without having to worry about input/output streams. For local
exploitation I suppose a new instance of DCL with privs would be
cleaner.

> Finally, the machine code stub that you had "embedded" into the utility
> in the mother process (via a logical name) would need to know a bit more
> about how it is being called.
>
> If the utility simply branches to your code, then your code would have
> no way of knowing where to branch back once it has completed its work.
> If the utility calls your code as a subroutine, then you could do all
> you want inside your subroutine and return to the caller cleanly and let
> the utility continue it merry way.
>
> However, the utility might expect some results from that subroutine and
> if your covert code-in-a-logical doesn't provide those results, the
> mainline code from the utility might barf with some invalid data.
>
> AKA: it would be pretty hard to make it appear totally transparent so
> that the user would have no knowledge that something untowards was done
> behind the scenes.

Things are done "in reverse" here, we are not calling our code we are
"returning to it". So we don't really have the option to choose how it
is going to be called. As you point out we also overwritten the
original return address for the function.. There may be enough
information intact to intelligently recalculate the return address and
return (not had my morning coffee yet and alpha isn't exactly my
favorite platform so don't hold me to it), or at the very least scan
memory for the right address to return to. We used these techniques in
the past in kernel exploits where it really is game over for you if
you don't clean your own mess up.

Here it isn't really a problem. You are not relying on another user to
execute the code for you so you don't really have to hide it. I
suppose someone could log the access violation and that it could give
you away, but then would be easier to terminate the process cleanly
from the shellcode rather than repairing the stack.




0
bugs6 (57)
8/18/2008 8:10:47 AM
Hi Heine,

Well done!

Regards Richard Maher

PS. Not that it is important, but what I am sceptical about is how "bugs"
found/stumbled-across/zeroed-in on this vulnerability! Can someone post the
analogous equivalent on *nix? I mean a 20 year-old privilege vulnerability
that occurs everyday in Windows/*nix yet no-one has found on VMS before,
without the help of a few days "generic" hacking, or perhaps the help of a
disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, wave a
dead-chicken over your head and howl at the moon - standard stuff for
hackers?)

PPS. I think the "LOTS" claims are premature (and disrespectful given VMS's
credentials) even if "bugs" has the runs on the board (and the Aussies are
still beating the poms :-) VMS *is* architected to be extremely secure! But
as you know, obviously better than me, it's only as secure as it's weakest
link (or RTL) or layered product. And thanks to to the "Industry Standard"
drones that run the current mess that is VMS middle-management, who knows
how deep this canker runs.

PPPS. But ol' Ann industry-standard MacQuaid can still keep the Andy
Goldsteins down in the dungeon doing *nix semaphores while this shit is
going on? Is there anyone accountable in this den of vipers? Where does the
fucking buck stop?

"Hein RMS van den Heuvel" <heinvandenheuvel@gmail.com> wrote in message
news:41c28c10-2d7a-49df-b984-2f89dff6f6a9@c65g2000hsa.googlegroups.com...
On Aug 16, 11:19 pm, VAXman-  @SendSpamHere.ORG wrote:
> >Thanks for that important additional piece of information. I can now
> >reproduce it on my Alpha VMS 8.3 home system.
>
> Save that after further investigation, it's not DCL... it's in a shareable
> image. The shareable and code has been identified.

I believe to have a full patch for this for Open Alpha VMS 8.3.
Caveat... this has had but 5 minutes of testing!

Patches for other versions should be much similar.
This is not just a workaround, like extending the buffer.
The patch  limits the max number of characters after an escape to 3
(or however many you like... which should be less than the 4 bytes
allocated).
It replaces a NOP, and some broken code, and with that an idle
register, to do its modest job.

$ dump/block=(count=1,start=124) sys$library:smgshr.exe;/
out=smgshr_original.dmp
$ copy/log sys$library:smgshr.exe; smgshr_patched.exe
$ patch  smgshr_patched.exe
define base=07c*200-200
deposit base+044 = 47E07401
deposit base+0ac = 40203121
deposit base+0b4 = 2FFE0000
deposit base+0d8 = 0E4200017
update
exit
$  dump/block=(count=1,start=124) smgshr_patched.exe; /
out=smgshr_patched.dmp

This should report:


old: 0000F644:  2FFE0000
new: 0000F644:  47E07401
old: 0000F6AC:  2020FDD4
new: 0000F6AC:  40203121
old: 0000F6B4:  441F0281
new: 0000F6B4:  2FFE0000
old: 0000F6D8:  0F4200017
new: 0000F6D8:  0E4200017

Now try your reproducer, or at least define smgshr to this patch image
and make sure it still work, with say MAIL, type/page, or pretty much
anything else.
When comfident move to SYS$LIBRARY.

hth,

Hein.


0
maher_rj (1626)
8/18/2008 11:09:27 AM
In article <op.uf1xg90bhv4qyg@murphus.hsd1.ca.comcast.net>,
 "Tom Linden" <tom@kednos.company> wrote:

> As for terminology, payload is certainly better than shellcode.

'tis worth looking at the Wiki entry here:

http://en.wikipedia.org/wiki/Shellcode

"Shellcode
From Wikipedia, the free encyclopedia

In computer security, a shellcode is a small piece of code used as the 
payload in the exploitation of a software vulnerability. It is called 
"shellcode" because it typically starts a command shell from which the 
attacker can control the compromised machine. Shellcode is commonly 
written in machine code, but any piece of code that performs a similar 
task can be called shellcode. Because the function of a payload is not 
limited to merely spawning a shell, some have suggested that the name 
shellcode is insufficient.[1] However, attempts at replacing the term 
have not gained wide acceptance."

The last couple of sentences do indicate that the name shellcode has 
shortcomings. For the sake of completeness, footnote [1] above 
references the following  book:

"Sockets, Shellcode, Porting, & Coding: Reverse Engineering Exploits and 
Tool Coding for Security Professionals. by James C. Foster and Stuart 
McClure (April 12, 2005). ISBN 1-59749-005-9"

-- 
Paul Sture
0
8/18/2008 11:40:31 AM
In article <fd91dcfd-933d-495b-8f35-f4d3aaccb064@26g2000hsk.googlegroups.com>, bugs@signedness.org writes:
>On Aug 17, 10:09 pm, VAXman-  @SendSpamHere.ORG wrote:
>
>> >It was pointed to you that the codecs used in the videos are
>> >non-standard and cannot be watched by everyone. I also didn't even
>> >bother to download them.
>It is a VMWare recording for heavens sake (http://www.vmware.com)!
>If you have bothered to download the videos you would probably not
>have
>played around with DCL commands and asked about FILE.EXE in the first
>place.
>
>> A cohesive explaination of reproducing the stack dump would have been
>> better than some video of a terminal session.  There was also a report
>> of no audio explaining what was happening in the video.
>It is a VMWare recording (http://www.vmware.com/), it has no sound.
>We used the videos in our presentation (and yes, we did actually
>talk while playing them).
>
>> >Your introduction of FILE.EXE was absolutely confusing. This was not
>> >necessary. And reduced your credibility because it put the focus on the
>> >"file.exe" instead of on the actual vulnerability.
>>
>> Another valid point.
>Again, you did not watch the videos, i.e. you did not input all data
>before computing.
>
>You continue to claim that we have done things wrong when trying to
>explain the vulnerability that you tried to wave away as a hoax. Your
>attitude strongly imply that this has nothing to do with terminology
>and codecs, but that your ego got bumped really hard, and you can not
>handle it.

There's no need for you to be so condescending.

It's not about ego.  I, and others here, were trying to determine if
this truly was a vulnerability.  The first reports were that this was
a vulnerability in the DCL CLI easily exploited with a buffer over-
flow.  The published instructions to cause the overflow did NOT pro-
duce the results reported.  _Your_ terminology was misleading -- not
the 'shellcode' thing either!

As for your VIDEO...  I did, this past weekend, view the one called:
openvms_local_install_exploit.avi.  

1. You telnet into a VMS system. 
   (this command sting alone is confusing)
2. delete PRIVS.TXT
3. run FILE.EXE
4. type PRIVS.TXT 
   (privs output)
5. delete PRIVS.TXT
6. then you run LOADCODE leaving a prompt SHELLCODE>> 
7. from this point you execute INSTALL... etc., etc., etc.

To me, it looks like you wrote your own CLI which is being used in 
the spawned subprocess.  Again, this obfuscates the reality.


>There is a bug for you to analyze.

One the missing bits were properly explained, I was able to produce the
stack dump.

I've written my OWN 'shellcode' now.  I load about 150 bytes of code to
P1 via a supported and documented user invokable mechanism!  This code
sets the AUTHPRIVs in the PHD and it returns cleanly via a SYS$EXIT with
SS$_NORMAL.  All of this executed in a normal DECwindows terminal.

NOW, had you, perhaps:

1. not changed your prompt
2. executed INSTALL from DCL
3. not returned the BADPARAM stack
4. explained, after the long string of AAAs, about the unseen I/O

there would have been more and immediate credence placed in your claim.

My question still is *WHY* FILE.EXE when SHOW PROCESS/PRIVILEGES would
have sufficed???  Your claim was something about output capturing.  I
fail to see why you can capture normal terminal I/O from a TYPE command
but not from SHOW PROCESS/PRIVILEGES.  This is the type of thing that's
caused much of the confusion, doubt and distrust here.  I have no issue
invoking my SHOW PROCESS/PRIVILEGES before and after loading my code to
P1.  I don't need to SPAWN a sub-process; albeit, for testing, I did to
allow quick cleanup of P1 space with a logout.

And, for the record, I did not proclaim this to be a hoax.  However, in
light of your, and others, instuctions which were muddled, incomplete,
and riddled with misleading jargon, I would expect that the good folks
of comp.os.vms would be dubious.

FWIW, I have been in contact with a number of people working independ-
ently on patches to thwart this attack.  Interim fixes until a patch or
fix is released by HP.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/18/2008 12:21:57 PM
In article <g8b07r$62a$1@charm.magnus.acs.ohio-state.edu>, JONESD@ecr6.ohio-state.edu (David Jones) writes:
>In message <eb7f5d29-3975-440e-8359-61fc9ef25d68@l64g2000hse.googlegroups.com>,
>   bugs@signedness.org writes:
>>Btw, any suggestions on how to trigger this automatically without
>>using a custom telnet/ssh client?
>
>So your goal is to create a trojan horse program that secretly breaks in
>when a non-privileged user runs it?
>
>>Using popen() or an input file with lib$spawn does not work (popen()
>>is probably implemented using lib$spawn), because the input is not a
>>terminal why the vulnerable code is not used.
>
>If SMG  doesn't think input is from an interactive terminal, there is no
>editting so there is no need to try to interpret escape characters.
>
>You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED
>process to it.  The parent process controlling the terminal doesn't need to
>supply a password and none of the dialog needs to be displayed.  Use the
>exploit to grant that spawned process privileges and then just use that session
>to do other things with the empowered process.

I don't believe that discussing how to "weaponize" this exploit is a good
idea for public discussion here in c.o.v.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/18/2008 12:26:00 PM
In article <1NednSR2u45CEDjVnZ2dnUVZ_oHinZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> Ten years ago, the code base was FULL of those little mistakes.  DEC 
> could have saved a lot of money and pain by buying a WORKING TCP/IP 
> stack from TGV or Wollongong.

   If DEC bought their "working stack" from Wollongong I would have
   been in a much greater hurry to upgrade from UCX to Multinet.

0
koehler2 (8314)
8/18/2008 12:29:27 PM
In article <48a5dea9$0$1847$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Since there is no such thing as "shellcode" in VMS, it would greatly
> help if you use terminology native to VMS so we could understand it.

   Guess again.  In the fiche (OK, I'm using my wayback), there is a
   "shell" in VMS.  Its part of the code used to map and start the CLI.
   IIRC it isn't DCL specific, it would be the same shell starting DCL,
   MCR, or DECshell.

   But that is not what the OP was discussing.  He was using the term
   "shellcode" in a more generic sense, a sense documented on Wiki, as
   he has cited.

   I haven't had time to test these exploits on my 8.3 systems, or my
   finger clients.  I am convinced that sufficient evidence has been
   produced that I should expect them to work if I haven't already
   installed the patches, which might be the case on one of my hobbyist
   systems.

   It's not clear to me how the finger exploit reaches arbitrary code,
   but it doesn't look out of the realm of possibility.  I'm satisfied
   that the DCL exploit did demonstrate execution of code with elevated
   priviliges.

   Now lets all get to work and patch our systems.

   VMS: 4, UNIX 2.E8, Windows 2.E99, live with it.  (No, I'm not going
   to dig up the other 2 VMS exploits I knew about, but be carefull if
   you're still running 1.x on your 11/780.)


0
koehler2 (8314)
8/18/2008 12:42:58 PM
In article <48a623a0$0$18525$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> VAXman- @SendSpamHere.ORG wrote:
> 
>> Memory is readable-only or read-write on Alpha.  There's nothing in the
>> PTE on VMS to indicate that it is or is not executable instruction code.
> 
> Oh wow. I was way off then. Was this the case for VAX where memory would
> be tagged as executable or not ?

   On both VAX and Alpha, executable vs. non-executable PSECTS are just
   notes to the linker because programs page more efficiently if you 
   keep the executable code together.  VAX and Alpha do not enforce 
   noexe at runtime.

   Alpha's Macro-32 (and I think Macro-64) does complain if you put code
   in a noexe PSECT, or data in an exe PSECT, but you are at liberty to
   ignore it.  It just slows your program down.

   IA-64 does have the ability to enforce noexe at runtime, and VMS does
   make use of it.

0
koehler2 (8314)
8/18/2008 12:48:43 PM
In article <ig3$X$Cl37gO@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <1NednSR2u45CEDjVnZ2dnUVZ_oHinZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>> Ten years ago, the code base was FULL of those little mistakes.  DEC 
>> could have saved a lot of money and pain by buying a WORKING TCP/IP 
>> stack from TGV or Wollongong.
>
>   If DEC bought their "working stack" from Wollongong I would have
>   been in a much greater hurry to upgrade from UCX to Multinet.

:)  I can appreciate that!

I recall when TGV offered a SIGNIFICANT discount on their product if 
you already had a TCP/IP product and switched to MultiNet.  In fact,
IIRC, they also offer a period of free maintenance.  That was all *I*
needed to purchase and install MultiNet and toss out, what we in the
labs at the time called, All-Is-Wrong.  The near daily system crashes
ceased with MultiNet's installation.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/18/2008 12:50:35 PM
It's amazing how many people can *now* get the egg to stand on its end once
they've been shown how :-( Oh, but your egg stands so much prouder.

Regards Richard Maher

<VAXman- @SendSpamHere.ORG> wrote in message
news:00A7E493.F1C14444@SendSpamHere.ORG...
> In article
<fd91dcfd-933d-495b-8f35-f4d3aaccb064@26g2000hsk.googlegroups.com>,
bugs@signedness.org writes:
> >On Aug 17, 10:09 pm, VAXman-  @SendSpamHere.ORG wrote:
> >
> >> >It was pointed to you that the codecs used in the videos are
> >> >non-standard and cannot be watched by everyone. I also didn't even
> >> >bother to download them.
> >It is a VMWare recording for heavens sake (http://www.vmware.com)!
> >If you have bothered to download the videos you would probably not
> >have
> >played around with DCL commands and asked about FILE.EXE in the first
> >place.
> >
> >> A cohesive explaination of reproducing the stack dump would have been
> >> better than some video of a terminal session.  There was also a report
> >> of no audio explaining what was happening in the video.
> >It is a VMWare recording (http://www.vmware.com/), it has no sound.
> >We used the videos in our presentation (and yes, we did actually
> >talk while playing them).
> >
> >> >Your introduction of FILE.EXE was absolutely confusing. This was not
> >> >necessary. And reduced your credibility because it put the focus on
the
> >> >"file.exe" instead of on the actual vulnerability.
> >>
> >> Another valid point.
> >Again, you did not watch the videos, i.e. you did not input all data
> >before computing.
> >
> >You continue to claim that we have done things wrong when trying to
> >explain the vulnerability that you tried to wave away as a hoax. Your
> >attitude strongly imply that this has nothing to do with terminology
> >and codecs, but that your ego got bumped really hard, and you can not
> >handle it.
>
> There's no need for you to be so condescending.
>
> It's not about ego.  I, and others here, were trying to determine if
> this truly was a vulnerability.  The first reports were that this was
> a vulnerability in the DCL CLI easily exploited with a buffer over-
> flow.  The published instructions to cause the overflow did NOT pro-
> duce the results reported.  _Your_ terminology was misleading -- not
> the 'shellcode' thing either!
>
> As for your VIDEO...  I did, this past weekend, view the one called:
> openvms_local_install_exploit.avi.
>
> 1. You telnet into a VMS system.
>    (this command sting alone is confusing)
> 2. delete PRIVS.TXT
> 3. run FILE.EXE
> 4. type PRIVS.TXT
>    (privs output)
> 5. delete PRIVS.TXT
> 6. then you run LOADCODE leaving a prompt SHELLCODE>>
> 7. from this point you execute INSTALL... etc., etc., etc.
>
> To me, it looks like you wrote your own CLI which is being used in
> the spawned subprocess.  Again, this obfuscates the reality.
>
>
> >There is a bug for you to analyze.
>
> One the missing bits were properly explained, I was able to produce the
> stack dump.
>
> I've written my OWN 'shellcode' now.  I load about 150 bytes of code to
> P1 via a supported and documented user invokable mechanism!  This code
> sets the AUTHPRIVs in the PHD and it returns cleanly via a SYS$EXIT with
> SS$_NORMAL.  All of this executed in a normal DECwindows terminal.
>
> NOW, had you, perhaps:
>
> 1. not changed your prompt
> 2. executed INSTALL from DCL
> 3. not returned the BADPARAM stack
> 4. explained, after the long string of AAAs, about the unseen I/O
>
> there would have been more and immediate credence placed in your claim.
>
> My question still is *WHY* FILE.EXE when SHOW PROCESS/PRIVILEGES would
> have sufficed???  Your claim was something about output capturing.  I
> fail to see why you can capture normal terminal I/O from a TYPE command
> but not from SHOW PROCESS/PRIVILEGES.  This is the type of thing that's
> caused much of the confusion, doubt and distrust here.  I have no issue
> invoking my SHOW PROCESS/PRIVILEGES before and after loading my code to
> P1.  I don't need to SPAWN a sub-process; albeit, for testing, I did to
> allow quick cleanup of P1 space with a logout.
>
> And, for the record, I did not proclaim this to be a hoax.  However, in
> light of your, and others, instuctions which were muddled, incomplete,
> and riddled with misleading jargon, I would expect that the good folks
> of comp.os.vms would be dubious.
>
> FWIW, I have been in contact with a number of people working independ-
> ently on patches to thwart this attack.  Interim fixes until a patch or
> fix is released by HP.
>
> -- 
> VAXman- A Bored Certified VMS Kernel Mode Hacker
VAXman(at)TMESIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional
protection
> no matter how extreme, vituperous, or vigorously expressed they may be.
(NJSC)
>
> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article
outside
> of usenet _must_ include its contents in its entirety including this
copyright
> notice, disclaimer and quotations.


0
maher_rj (1626)
8/18/2008 12:56:06 PM
Bob Koehler wrote:
> In article <1NednSR2u45CEDjVnZ2dnUVZ_oHinZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Ten years ago, the code base was FULL of those little mistakes.  DEC 
>> could have saved a lot of money and pain by buying a WORKING TCP/IP 
>> stack from TGV or Wollongong.
> 
>    If DEC bought their "working stack" from Wollongong I would have
>    been in a much greater hurry to upgrade from UCX to Multinet.
> 

Sorry if I chose a poor example.  I've never used Wollongong, nor 
Multinet.  My experience is limited to the CMU-TEK tcp/ip package, UCX, 
and one other third party package whose name I have forgotten.  The 
virtue of the CMU-TEK package was that it was free.  The downside was 
that you didn't get much more that you paid for.  It usually worked to 
some extent but it had a lot of small but annoying problems. I'm talking 
about the late 1980s and early 90s; I've had no experience with the 
package since then.  The DEC package had problems of its own in versions 
2.7 through 4.x.  UCX 5.1 or 5.2 was beginning to look like a real 
TCP/IP package instead of a quick and dirty port of the Berkeley code.

0
rgilbert88 (4439)
8/18/2008 1:05:07 PM
On Aug 18, 12:09=A0pm, "Richard Maher" <maher...@hotspamnotmail.com>
wrote:
> Hi Heine,
>
> Well done!
>
> Regards Richard Maher
>
> PS. Not that it is important, but what I am sceptical about is how "bugs"
> found/stumbled-across/zeroed-in on this vulnerability! Can someone post t=
he
> analogous equivalent on *nix? I mean a 20 year-old privilege vulnerabilit=
y
> that occurs everyday in Windows/*nix yet no-one has found on VMS before,
> without the help of a few days "generic" hacking, or perhaps the help of =
a
> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, wave a
> dead-chicken over your head and howl at the moon - standard stuff for
> hackers?)
>

No disgruntled deap-throat, no dead chickens or magic wands... The
simple truth is very few people have bothered looking at VMS because
it is "secure". If nobody is looking for bugs then no bugs are found.
How many times have we heard "many eyes makes all bugs shallow"? Well
still we see really dumb bugs popping up in some of the most popular
open source applications so it is really that surprising that simple
bugs are found in an operating system that I would assume very few
have looked for bugs in since the 80s? (that being said, still a nice
find by cmn :))

The finger client bugs are good examples, more or less anyone would
have found them if they bothered looking for security bugs. The
seriousness of format string vulnerabilities has been widely known for
almost 10 years and still there it is (of course it was probably +15
years since anybody had a serious go at owning VMS).. Speaking of 20
year old vulns, what about Shaun Colley's fingerd bug? Anyone remember
Morris worm? Almost exactly 20 year old bug...



> PPS. I think the "LOTS" claims are premature (and disrespectful given VMS=
's
> credentials) even if "bugs" has the runs on the board (and the Aussies ar=
e
> still beating the poms :-) VMS *is* architected to be extremely secure! B=
ut
> as you know, obviously better than me, it's only as secure as it's weakes=
t
> link (or RTL) or layered product. And thanks to to the "Industry Standard=
"
> drones that run the current mess that is VMS middle-management, who knows
> how deep this canker runs.
>

We'll see hopefully more people start looking for bugs.. And not only
memory corruption bugs, there are quite a few things in documentation
that should make you think.. For example what about debugging? I read
privileged images need to be linked with /NODEBUG to be installed, I
think everybody understands why it is undersirable to let users debug
a privileged program. But how is this actually implemented? Is
"limitation" actually enforced by the kernel? Maybe, I have no idea,
but the way I read it, it could just as well mean that it is enforced
by INSTALL / DEBUG. And there are many many more little things like
that someone should look into.  Not to mention what would probably be
found if someone did a proper source audit........


> PPPS. But ol' Ann industry-standard MacQuaid can still keep the Andy
> Goldsteins down in the dungeon doing *nix semaphores while this shit is
> going on? Is there anyone accountable in this den of vipers? Where does t=
he
> fucking buck stop?
>
> "Hein RMS van den Heuvel" <heinvandenheu...@gmail.com> wrote in messagene=
ws:41c28c10-2d7a-49df-b984-2f89dff6f6a9@c65g2000hsa.googlegroups.com...
> On Aug 16, 11:19 pm, VAXman- =A0@SendSpamHere.ORG wrote:
>
> > >Thanks for that important additional piece of information. I can now
> > >reproduce it on my Alpha VMS 8.3 home system.
>
> > Save that after further investigation, it's not DCL... it's in a sharea=
ble
> > image. The shareable and code has been identified.
>
> I believe to have a full patch for this for Open Alpha VMS 8.3.
> Caveat... this has had but 5 minutes of testing!
>
> Patches for other versions should be much similar.
> This is not just a workaround, like extending the buffer.
> The patch =A0limits the max number of characters after an escape to 3
> (or however many you like... which should be less than the 4 bytes
> allocated).
> It replaces a NOP, and some broken code, and with that an idle
> register, to do its modest job.
>
> $ dump/block=3D(count=3D1,start=3D124) sys$library:smgshr.exe;/
> out=3Dsmgshr_original.dmp
> $ copy/log sys$library:smgshr.exe; smgshr_patched.exe
> $ patch =A0smgshr_patched.exe
> define base=3D07c*200-200
> deposit base+044 =3D 47E07401
> deposit base+0ac =3D 40203121
> deposit base+0b4 =3D 2FFE0000
> deposit base+0d8 =3D 0E4200017
> update
> exit
> $ =A0dump/block=3D(count=3D1,start=3D124) smgshr_patched.exe; /
> out=3Dsmgshr_patched.dmp
>
> This should report:
>
> old: 0000F644: =A02FFE0000
> new: 0000F644: =A047E07401
> old: 0000F6AC: =A02020FDD4
> new: 0000F6AC: =A040203121
> old: 0000F6B4: =A0441F0281
> new: 0000F6B4: =A02FFE0000
> old: 0000F6D8: =A00F4200017
> new: 0000F6D8: =A00E4200017
>
> Now try your reproducer, or at least define smgshr to this patch image
> and make sure it still work, with say MAIL, type/page, or pretty much
> anything else.
> When comfident move to SYS$LIBRARY.
>
> hth,
>
> Hein.

0
bugs6 (57)
8/18/2008 1:37:21 PM
In article <op.ufzg61t8hv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:
> 
> How would you go about this on a remote machine to which you do not
> have login priveleges?

   Both of these exploits are useable only to people who already have
   access, although unprivileged.  That's enough to get my attention.

0
koehler2 (8314)
8/18/2008 1:42:13 PM
In article <op.ufzkzzlkhv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:
> 
> Well I have always disabled fingerd whether on Unix or VMS, but there
> may well be other avenues.  Such exploits would not be possible had the  
> code
> been written using a safe language like PL/I or Ada with apporpriate
> ON conditions.

   If I understand correctly, the exploit is not through the finger
   server (fingerd), but the finger client.  Is your finger client
   disabled?

0
koehler2 (8314)
8/18/2008 1:44:19 PM
In article <g88vht$1b1$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:
> 
> This bug doesn't effect all images with embedded commandline commands for
> instance SYSGEN seems to have been written to cope with it
> 

   SYSGEN does it's own terminal I/O, it's been around much longer than
   other utilities and the code needs to execute in the limited
   environment provided when stopping during the boot process.

0
koehler2 (8314)
8/18/2008 1:48:26 PM
On Aug 18, 2:26 pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <g8b07r$62...@charm.magnus.acs.ohio-state.edu>, JON...@ecr6.ohio-state.edu (David Jones) writes:
>
>
>
> >In message <eb7f5d29-3975-440e-8359-61fc9ef25...@l64g2000hse.googlegroups.com>,
> >   b...@signedness.org writes:
> >>Btw, any suggestions on how to trigger this automatically without
> >>using a custom telnet/ssh client?
>
> >So your goal is to create a trojan horse program that secretly breaks in
> >when a non-privileged user runs it?
>
> >>Using popen() or an input file with lib$spawn does not work (popen()
> >>is probably implemented using lib$spawn), because the input is not a
> >>terminal why the vulnerable code is not used.
>
> >If SMG  doesn't think input is from an interactive terminal, there is no
> >editting so there is no need to try to interpret escape characters.
>
> >You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED
> >process to it.  The parent process controlling the terminal doesn't need to
> >supply a password and none of the dialog needs to be displayed.  Use the
> >exploit to grant that spawned process privileges and then just use that session
> >to do other things with the empowered process.
>
> I don't believe that discussing how to "weaponize" this exploit is a good
> idea for public discussion here in c.o.v.

If it was up to you to decide what should be in this group it would
only be
a maximum of two posts in every thread, the first post with a question
and a second post with a correct answer from you.

>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional protection
> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>
> Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
> of usenet _must_ include its contents in its entirety including this copyright
> notice, disclaimer and quotations.

0
bugs6 (57)
8/18/2008 1:56:25 PM
bugs@signedness.org wrote:
> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
> wrote:
>> Hi Heine,
>>
>> Well done!
>>
>> Regards Richard Maher
>>
>> PS. Not that it is important, but what I am sceptical about is how "bugs"
>> found/stumbled-across/zeroed-in on this vulnerability! Can someone post the
>> analogous equivalent on *nix? I mean a 20 year-old privilege vulnerability
>> that occurs everyday in Windows/*nix yet no-one has found on VMS before,
>> without the help of a few days "generic" hacking, or perhaps the help of a
>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, wave a
>> dead-chicken over your head and howl at the moon - standard stuff for
>> hackers?)
>>
> 
> No disgruntled deap-throat, no dead chickens or magic wands... The
> simple truth is very few people have bothered looking at VMS because
> it is "secure". If nobody is looking for bugs then no bugs are found.
> How many times have we heard "many eyes makes all bugs shallow"? Well
> still we see really dumb bugs popping up in some of the most popular
> open source applications so it is really that surprising that simple
> bugs are found in an operating system that I would assume very few
> have looked for bugs in since the 80s? (that being said, still a nice
> find by cmn :))
> 
> The finger client bugs are good examples, more or less anyone would
> have found them if they bothered looking for security bugs. The
> seriousness of format string vulnerabilities has been widely known for
> almost 10 years and still there it is (of course it was probably +15
> years since anybody had a serious go at owning VMS).. Speaking of 20
> year old vulns, what about Shaun Colley's fingerd bug? Anyone remember
> Morris worm? Almost exactly 20 year old bug...
> 

Hell, yes!  There may be some newbies around who haven't heard of it but 
I was there while it was happening.  Fortunately, I was responsible only 
for some VMS systems which were not affected.  Most of the Unix systems 
in the world were affected.  For those newbies who missed it, Clifford 
Stoll wrote a very readable book, "The Cuckoo's Egg", that touches the 
subject briefly.  I'd say it's a "must read" for anyone interested in 
system security.  It's the only first person account that I know of but 
there may be others.

VMS System Managers are probably aware of a list of forbidden passwords 
maintained by the system.  500 or so of the entries are Robert Morris' 
list of commonly used passwords!  His worm used them to attempt to log 
on to his target systems.  He also abused a buffer overflow 
vulnerability in the finger daemon.  The systems the worm penetrated 
promptly started trying to subvert other systems. . . .  It was an 
interesting two or three days for the Unix system administrators.  VMS
systems were largely unaffected.

Difficult as it may be to believe, hackers are STILL exploiting buffer 
overflows.  There is still a lot of code around that will cheerfully 
attempt to put ten pounds of shit in a five pound bag!
0
rgilbert88 (4439)
8/18/2008 2:09:11 PM
On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert  
<rgilbert88@comcast.net> wrote:

> bugs@signedness.org wrote:
>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
>> wrote:
>>> Hi Heine,
>>>
>>> Well done!
>>>
>>> Regards Richard Maher
>>>
>>> PS. Not that it is important, but what I am sceptical about is how  
>>> "bugs"
>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone  
>>> post the
>>> analogous equivalent on *nix? I mean a 20 year-old privilege  
>>> vulnerability
>>> that occurs everyday in Windows/*nix yet no-one has found on VMS  
>>> before,
>>> without the help of a few days "generic" hacking, or perhaps the help  
>>> of a
>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, wave a
>>> dead-chicken over your head and howl at the moon - standard stuff for
>>> hackers?)
>>>
>>  No disgruntled deap-throat, no dead chickens or magic wands... The
>> simple truth is very few people have bothered looking at VMS because
>> it is "secure". If nobody is looking for bugs then no bugs are found.
>> How many times have we heard "many eyes makes all bugs shallow"? Well
>> still we see really dumb bugs popping up in some of the most popular
>> open source applications so it is really that surprising that simple
>> bugs are found in an operating system that I would assume very few
>> have looked for bugs in since the 80s? (that being said, still a nice
>> find by cmn :))
>>  The finger client bugs are good examples, more or less anyone would
>> have found them if they bothered looking for security bugs. The
>> seriousness of format string vulnerabilities has been widely known for
>> almost 10 years and still there it is (of course it was probably +15
>> years since anybody had a serious go at owning VMS).. Speaking of 20
>> year old vulns, what about Shaun Colley's fingerd bug? Anyone remember
>> Morris worm? Almost exactly 20 year old bug...
>>
>
> Hell, yes!  There may be some newbies around who haven't heard of it but  
> I was there while it was happening.  Fortunately, I was responsible only  
> for some VMS systems which were not affected.  Most of the Unix systems  
> in the world were affected.  For those newbies who missed it, Clifford  
> Stoll wrote a very readable book, "The Cuckoo's Egg", that touches the  
> subject briefly.  I'd say it's a "must read" for anyone interested in  
> system security.  It's the only first person account that I know of but  
> there may be others.
>
> VMS System Managers are probably aware of a list of forbidden passwords  
> maintained by the system.  500 or so of the entries are Robert Morris'  
> list of commonly used passwords!  His worm used them to attempt to log  
> on to his target systems.  He also abused a buffer overflow  
> vulnerability in the finger daemon.  The systems the worm penetrated  
> promptly started trying to subvert other systems. . . .  It was an  
> interesting two or three days for the Unix system administrators.  VMS
> systems were largely unaffected.
>
> Difficult as it may be to believe, hackers are STILL exploiting buffer  
> overflows.  There is still a lot of code around that will cheerfully  
> attempt to put ten pounds of shit in a five pound bag!

Just curious, have you looked at z/os?

-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/18/2008 2:24:14 PM
On Mon, 18 Aug 2008 06:44:19 -0700, Bob Koehler  
<koehler@eisner.nospam.encompasserve.org> wrote:

> In article <op.ufzkzzlkhv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden"  
> <tom@kednos.company> writes:
>>
>> Well I have always disabled fingerd whether on Unix or VMS, but there
>> may well be other avenues.  Such exploits would not be possible had the
>> code
>> been written using a safe language like PL/I or Ada with apporpriate
>> ON conditions.
>
>    If I understand correctly, the exploit is not through the finger
>    server (fingerd), but the finger client.  Is your finger client
>    disabled?
>
Yes.


-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/18/2008 2:26:36 PM
In article 
<ad4e4896-6f62-450c-958f-7be16eafffb4@i76g2000hsf.googlegroups.com>,
 bugs@signedness.org wrote:

> The finger client bugs are good examples, more or less anyone would
> have found them if they bothered looking for security bugs. The
> seriousness of format string vulnerabilities has been widely known for
> almost 10 years and still there it is (of course it was probably +15
> years since anybody had a serious go at owning VMS).. 

I think the key to this mystery is that a lot of us simply haven't used 
finger on VMS. I know I have never enabled it on a VMS system, and 
suspect that I am not alone.

-- 
Paul Sture
0
8/18/2008 2:35:39 PM
In article <PoUhmmu+N1SO@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <48a623a0$0$18525$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>> VAXman- @SendSpamHere.ORG wrote:
>> 
>>> Memory is readable-only or read-write on Alpha.  There's nothing in the
>>> PTE on VMS to indicate that it is or is not executable instruction code.
>> 
>> Oh wow. I was way off then. Was this the case for VAX where memory would
>> be tagged as executable or not ?
>
>   On both VAX and Alpha, executable vs. non-executable PSECTS are just
>   notes to the linker because programs page more efficiently if you 
>   keep the executable code together.  VAX and Alpha do not enforce 
>   noexe at runtime.
>
>   Alpha's Macro-32 (and I think Macro-64) does complain if you put code
>   in a noexe PSECT, or data in an exe PSECT, but you are at liberty to
>   ignore it.  It just slows your program down.

There is a MIXED attribute in Macro64.  I've used this extensively. ;)

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/18/2008 3:07:52 PM
Tom Linden wrote:
> On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert 
> <rgilbert88@comcast.net> wrote:
> 
>> bugs@signedness.org wrote:
>>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
>>> wrote:
>>>> Hi Heine,
>>>>
>>>> Well done!
>>>>
>>>> Regards Richard Maher
>>>>
>>>> PS. Not that it is important, but what I am sceptical about is how 
>>>> "bugs"
>>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone 
>>>> post the
>>>> analogous equivalent on *nix? I mean a 20 year-old privilege 
>>>> vulnerability
>>>> that occurs everyday in Windows/*nix yet no-one has found on VMS 
>>>> before,
>>>> without the help of a few days "generic" hacking, or perhaps the 
>>>> help of a
>>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, wave a
>>>> dead-chicken over your head and howl at the moon - standard stuff for
>>>> hackers?)
>>>>
>>>  No disgruntled deap-throat, no dead chickens or magic wands... The
>>> simple truth is very few people have bothered looking at VMS because
>>> it is "secure". If nobody is looking for bugs then no bugs are found.
>>> How many times have we heard "many eyes makes all bugs shallow"? Well
>>> still we see really dumb bugs popping up in some of the most popular
>>> open source applications so it is really that surprising that simple
>>> bugs are found in an operating system that I would assume very few
>>> have looked for bugs in since the 80s? (that being said, still a nice
>>> find by cmn :))
>>>  The finger client bugs are good examples, more or less anyone would
>>> have found them if they bothered looking for security bugs. The
>>> seriousness of format string vulnerabilities has been widely known for
>>> almost 10 years and still there it is (of course it was probably +15
>>> years since anybody had a serious go at owning VMS).. Speaking of 20
>>> year old vulns, what about Shaun Colley's fingerd bug? Anyone remember
>>> Morris worm? Almost exactly 20 year old bug...
>>>
>>
>> Hell, yes!  There may be some newbies around who haven't heard of it 
>> but I was there while it was happening.  Fortunately, I was 
>> responsible only for some VMS systems which were not affected.  Most 
>> of the Unix systems in the world were affected.  For those newbies who 
>> missed it, Clifford Stoll wrote a very readable book, "The Cuckoo's 
>> Egg", that touches the subject briefly.  I'd say it's a "must read" 
>> for anyone interested in system security.  It's the only first person 
>> account that I know of but there may be others.
>>
>> VMS System Managers are probably aware of a list of forbidden 
>> passwords maintained by the system.  500 or so of the entries are 
>> Robert Morris' list of commonly used passwords!  His worm used them to 
>> attempt to log on to his target systems.  He also abused a buffer 
>> overflow vulnerability in the finger daemon.  The systems the worm 
>> penetrated promptly started trying to subvert other systems. . . .  It 
>> was an interesting two or three days for the Unix system 
>> administrators.  VMS
>> systems were largely unaffected.
>>
>> Difficult as it may be to believe, hackers are STILL exploiting buffer 
>> overflows.  There is still a lot of code around that will cheerfully 
>> attempt to put ten pounds of shit in a five pound bag!
> 
> Just curious, have you looked at z/os?
> 

No, isn't that the IBM mainframe O/S these days?  It has been many long 
years since I last used one.
0
rgilbert88 (4439)
8/18/2008 3:12:53 PM
In message <paul.sture.nospam-D38990.16353918082008@mac.sture.ch>,
  "P. Sture" <paul.sture.nospam@hispeed.ch> writes:
>I think the key to this mystery is that a lot of us simply haven't used
>finger on VMS. I know I have never enabled it on a VMS system, and
>suspect that I am not alone.

The really anal security types consider the mere fact that finger discloses
valid usernames (and other information) a risk and discourage it being enabled
on any system.  I have a finger available locally, but not as a network
service.

When it comes to security holes, finger is definitely a 'usual suspect'.  It
seems everyone who creates a finger makes the same naive mistakes.  I use a
finger written in FORTRAN a long time ago.


David L. Jones               |      Phone:    (614) 271-6718
Ohio State University        |      Internet:
140 W. 19th St.              |               jonesd@ecr6.ohio-state.edu
Columbus, OH 43210           |               vman+@osu.edu

Disclaimer: I'm looking for marbles all day long.
0
JONESD2 (40)
8/18/2008 3:13:58 PM
On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <tom@kednos.company> wrote:

> On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert  
> <rgilbert88@comcast.net> wrote:
>
>> bugs@signedness.org wrote:
>>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
>>> wrote:
>>>> Hi Heine,
>>>>
>>>> Well done!
>>>>
>>>> Regards Richard Maher
>>>>
>>>> PS. Not that it is important, but what I am sceptical about is how  
>>>> "bugs"
>>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone  
>>>> post the
>>>> analogous equivalent on *nix? I mean a 20 year-old privilege  
>>>> vulnerability
>>>> that occurs everyday in Windows/*nix yet no-one has found on VMS  
>>>> before,
>>>> without the help of a few days "generic" hacking, or perhaps the help  
>>>> of a
>>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, wave a
>>>> dead-chicken over your head and howl at the moon - standard stuff for
>>>> hackers?)
>>>>
>>>  No disgruntled deap-throat, no dead chickens or magic wands... The
>>> simple truth is very few people have bothered looking at VMS because
>>> it is "secure". If nobody is looking for bugs then no bugs are found.
>>> How many times have we heard "many eyes makes all bugs shallow"? Well
>>> still we see really dumb bugs popping up in some of the most popular
>>> open source applications so it is really that surprising that simple
>>> bugs are found in an operating system that I would assume very few
>>> have looked for bugs in since the 80s? (that being said, still a nice
>>> find by cmn :))
>>>  The finger client bugs are good examples, more or less anyone would
>>> have found them if they bothered looking for security bugs. The
>>> seriousness of format string vulnerabilities has been widely known for
>>> almost 10 years and still there it is (of course it was probably +15
>>> years since anybody had a serious go at owning VMS).. Speaking of 20
>>> year old vulns, what about Shaun Colley's fingerd bug? Anyone remember
>>> Morris worm? Almost exactly 20 year old bug...
>>>
>>
>> Hell, yes!  There may be some newbies around who haven't heard of it  
>> but I was there while it was happening.  Fortunately, I was responsible  
>> only for some VMS systems which were not affected.  Most of the Unix  
>> systems in the world were affected.  For those newbies who missed it,  
>> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg", that  
>> touches the subject briefly.  I'd say it's a "must read" for anyone  
>> interested in system security.  It's the only first person account that  
>> I know of but there may be others.
>>
>> VMS System Managers are probably aware of a list of forbidden passwords  
>> maintained by the system.  500 or so of the entries are Robert Morris'  
>> list of commonly used passwords!  His worm used them to attempt to log  
>> on to his target systems.  He also abused a buffer overflow  
>> vulnerability in the finger daemon.  The systems the worm penetrated  
>> promptly started trying to subvert other systems. . . .  It was an  
>> interesting two or three days for the Unix system administrators.  VMS
>> systems were largely unaffected.
>>
>> Difficult as it may be to believe, hackers are STILL exploiting buffer  
>> overflows.  There is still a lot of code around that will cheerfully  
>> attempt to put ten pounds of shit in a five pound bag!
>
> Just curious, have you looked at z/os?
>

That was meant to be asked of Bugs, got out of sync.

-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/18/2008 3:23:16 PM
In article <mvMzXfvhiNg0@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <op.ufzkzzlkhv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:
>> 
>> Well I have always disabled fingerd whether on Unix or VMS, but there
>> may well be other avenues.  Such exploits would not be possible had the  
>> code
>> been written using a safe language like PL/I or Ada with apporpriate
>> ON conditions.
>
>   If I understand correctly, the exploit is not through the finger
>   server (fingerd), but the finger client.  Is your finger client
>   disabled?
>
If the finger server is disabled then the finger client isn't installed with
any privileges.



David Webb
Security team leader
CCSS
Middlesex University
0
david20
8/18/2008 3:37:04 PM
In article <H4udnb5NmbzuHjTVnZ2dnUVZ_rXinZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>bugs@signedness.org wrote:
>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
>> wrote:
>> Speaking of 20
>> year old vulns, what about Shaun Colley's fingerd bug? Anyone remember
>> Morris worm? Almost exactly 20 year old bug...
>> 
>
>Hell, yes!  There may be some newbies around who haven't heard of it but 
>I was there while it was happening.  Fortunately, I was responsible only 
>for some VMS systems which were not affected.  Most of the Unix systems 
>in the world were affected.  For those newbies who missed it, Clifford 
>Stoll wrote a very readable book, "The Cuckoo's Egg", that touches the 
>subject briefly.  I'd say it's a "must read" for anyone interested in 
>system security.  It's the only first person account that I know of but 
>there may be others.
>
>VMS System Managers are probably aware of a list of forbidden passwords 
>maintained by the system.  500 or so of the entries are Robert Morris' 
>list of commonly used passwords!  His worm used them to attempt to log 
>on to his target systems.  He also abused a buffer overflow 
>vulnerability in the finger daemon.  The systems the worm penetrated 
>promptly started trying to subvert other systems. . . .  It was an 
>interesting two or three days for the Unix system administrators.  VMS
>systems were largely unaffected.
>
But of course VAX/VMS systems of that era had their own worms remember

the Father XMAS worm

see

http://www.users.qwest.net/~eballen1/father_xmas.txt

and of course WANK

see

http://en.wikipedia.org/wiki/WANK_(computer_worm)


these relied on DECNET task and weak password vulnerabilities.


David Webb
Security team leader
CCSS
Middlesex University



>Difficult as it may be to believe, hackers are STILL exploiting buffer 
>overflows.  There is still a lot of code around that will cheerfully 
>attempt to put ten pounds of shit in a five pound bag!
0
david20
8/18/2008 3:56:41 PM
On Aug 18, 1:21=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <fd91dcfd-933d-495b-8f35-f4d3aaccb...@26g2000hsk.googlegroups.=
com>, b...@signedness.org writes:
>
>
>
> >On Aug 17, 10:09 pm, VAXman- =A0@SendSpamHere.ORG wrote:
>
> >> >It was pointed to you that the codecs used in the videos are
> >> >non-standard and cannot be watched by everyone. I also didn't even
> >> >bother to download them.
> >It is a VMWare recording for heavens sake (http://www.vmware.com)!
> >If you have bothered to download the videos you would probably not
> >have
> >played around with DCL commands and asked about FILE.EXE in the first
> >place.
>
> >> A cohesive explaination of reproducing the stack dump would have been
> >> better than some video of a terminal session. =A0There was also a repo=
rt
> >> of no audio explaining what was happening in the video.
> >It is a VMWare recording (http://www.vmware.com/), it has no sound.
> >We used the videos in our presentation (and yes, we did actually
> >talk while playing them).
>
> >> >Your introduction of FILE.EXE was absolutely confusing. This was not
> >> >necessary. And reduced your credibility because it put the focus on t=
he
> >> >"file.exe" instead of on the actual vulnerability.
>
> >> Another valid point.
> >Again, you did not watch the videos, i.e. you did not input all data
> >before computing.
>
> >You continue to claim that we have done things wrong when trying to
> >explain the vulnerability that you tried to wave away as a hoax. Your
> >attitude strongly imply that this has nothing to do with terminology
> >and codecs, but that your ego got bumped really hard, and you can not
> >handle it.
>
> There's no need for you to be so condescending.
>
> It's not about ego. =A0I, and others here, were trying to determine if
> this truly was a vulnerability. =A0The first reports were that this was
> a vulnerability in the DCL CLI easily exploited with a buffer over-
> flow. =A0The published instructions to cause the overflow did NOT pro-
> duce the results reported. =A0_Your_ terminology was misleading -- not
> the 'shellcode' thing either!
>
> As for your VIDEO... =A0I did, this past weekend, view the one called:
> openvms_local_install_exploit.avi. =A0
>
> 1. You telnet into a VMS system.
> =A0 =A0(this command sting alone is confusing)
> 2. delete PRIVS.TXT
> 3. run FILE.EXE
> 4. type PRIVS.TXT
> =A0 =A0(privs output)
> 5. delete PRIVS.TXT
> 6. then you run LOADCODE leaving a prompt SHELLCODE>>
> 7. from this point you execute INSTALL... etc., etc., etc.
>
> To me, it looks like you wrote your own CLI which is being used in
> the spawned subprocess. =A0Again, this obfuscates the reality.
>
> >There is a bug for you to analyze.
>
> One the missing bits were properly explained, I was able to produce the
> stack dump.
>
> I've written my OWN 'shellcode' now. =A0I load about 150 bytes of code to
> P1 via a supported and documented user invokable mechanism! =A0This code
> sets the AUTHPRIVs in the PHD and it returns cleanly via a SYS$EXIT with
> SS$_NORMAL. =A0All of this executed in a normal DECwindows terminal.
>
> NOW, had you, perhaps:
>
> 1. not changed your prompt
> 2. executed INSTALL from DCL
> 3. not returned the BADPARAM stack
> 4. explained, after the long string of AAAs, about the unseen I/O
>
> there would have been more and immediate credence placed in your claim.
>
> My question still is *WHY* FILE.EXE when SHOW PROCESS/PRIVILEGES would
> have sufficed??? =A0Your claim was something about output capturing. =A0I
> fail to see why you can capture normal terminal I/O from a TYPE command
> but not from SHOW PROCESS/PRIVILEGES. =A0This is the type of thing that's
> caused much of the confusion, doubt and distrust here. =A0I have no issue
> invoking my SHOW PROCESS/PRIVILEGES before and after loading my code to
> P1. =A0I don't need to SPAWN a sub-process; albeit, for testing, I did to
> allow quick cleanup of P1 space with a logout.
>
> And, for the record, I did not proclaim this to be a hoax. =A0However, in
> light of your, and others, instuctions which were muddled, incomplete,
> and riddled with misleading jargon, I would expect that the good folks
> of comp.os.vms would be dubious.
>
> FWIW, I have been in contact with a number of people working independ-
> ently on patches to thwart this attack. =A0Interim fixes until a patch or
> fix is released by HP.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME=
SIS(dot)COM
>
> ... pejorative statements of opinion are entitled to constitutional prote=
ction
> no matter how extreme, vituperous, or vigorously expressed they may be. (=
NJSC)
>
> Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article =
outside
> of usenet _must_ include its contents in its entirety including this copy=
right
> notice, disclaimer and quotations.

Well congratulations, now you pissed me off too and not just cmn..

WE said nothing about DCL.. Our terminology misleading? Funny..
because it is a security issue, it was presented at a security
conference, everyone there seemed to get it, and other people in this
group got it too... If you don't understand what shellcode means,
don't google it, or ask and then make the wrong assumptions that is
hardly our fucking fault now is it?


OH AND CONDESCENDING????? GIVE ME A FUCKING BREAK! Remember the "1337
haxOrz" Comment? What do you call that? Yeah we may not be old enough
to remember the dinosaurs or having written code on punch cards...
Well guess what, we still found and exploited multiple vulnerabilities
in VMS.. even if we are not in the right little click of superior
beings such as yourself..

Then you say discussing how to "weaponize" this exploit is not a good
idea for public discussion.... We seem to recall demands that we
release our exploit.... Double standards??? Oh and talking about your
shellcode is ok? oh wait... it can't be that you still are trying to
prove that you are superior to us for using a different method, can
it?

Or as another poster so elegantly put it:-

"It's amazing how many people can *now* get the egg to stand on its
end once they've been shown how :-( Oh, but your egg stands so much
prouder."


0
bugs6 (57)
8/18/2008 4:05:19 PM
On Aug 18, 4:23=A0pm, "Tom Linden" <t...@kednos.company> wrote:
> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <t...@kednos.company> wrot=
e:
> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert =A0
> > <rgilber...@comcast.net> wrote:
>
> >> b...@signedness.org wrote:
> >>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
> >>> wrote:
> >>>> Hi Heine,
>
> >>>> Well done!
>
> >>>> Regards Richard Maher
>
> >>>> PS. Not that it is important, but what I am sceptical about is how =
=A0
> >>>> "bugs"
> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone =
=A0
> >>>> post the
> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege =A0
> >>>> vulnerability
> >>>> that occurs everyday in Windows/*nix yet no-one has found on VMS =A0
> >>>> before,
> >>>> without the help of a few days "generic" hacking, or perhaps the hel=
p =A0
> >>>> of a
> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, wave =
a
> >>>> dead-chicken over your head and howl at the moon - standard stuff fo=
r
> >>>> hackers?)
>
> >>> =A0No disgruntled deap-throat, no dead chickens or magic wands... The
> >>> simple truth is very few people have bothered looking at VMS because
> >>> it is "secure". If nobody is looking for bugs then no bugs are found.
> >>> How many times have we heard "many eyes makes all bugs shallow"? Well
> >>> still we see really dumb bugs popping up in some of the most popular
> >>> open source applications so it is really that surprising that simple
> >>> bugs are found in an operating system that I would assume very few
> >>> have looked for bugs in since the 80s? (that being said, still a nice
> >>> find by cmn :))
> >>> =A0The finger client bugs are good examples, more or less anyone woul=
d
> >>> have found them if they bothered looking for security bugs. The
> >>> seriousness of format string vulnerabilities has been widely known fo=
r
> >>> almost 10 years and still there it is (of course it was probably +15
> >>> years since anybody had a serious go at owning VMS).. Speaking of 20
> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone remembe=
r
> >>> Morris worm? Almost exactly 20 year old bug...
>
> >> Hell, yes! =A0There may be some newbies around who haven't heard of it=
 =A0
> >> but I was there while it was happening. =A0Fortunately, I was responsi=
ble =A0
> >> only for some VMS systems which were not affected. =A0Most of the Unix=
 =A0
> >> systems in the world were affected. =A0For those newbies who missed it=
, =A0
> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg", that =
=A0
> >> touches the subject briefly. =A0I'd say it's a "must read" for anyone =
=A0
> >> interested in system security. =A0It's the only first person account t=
hat =A0
> >> I know of but there may be others.
>
> >> VMS System Managers are probably aware of a list of forbidden password=
s =A0
> >> maintained by the system. =A0500 or so of the entries are Robert Morri=
s' =A0
> >> list of commonly used passwords! =A0His worm used them to attempt to l=
og =A0
> >> on to his target systems. =A0He also abused a buffer overflow =A0
> >> vulnerability in the finger daemon. =A0The systems the worm penetrated=
 =A0
> >> promptly started trying to subvert other systems. . . . =A0It was an =
=A0
> >> interesting two or three days for the Unix system administrators. =A0V=
MS
> >> systems were largely unaffected.
>
> >> Difficult as it may be to believe, hackers are STILL exploiting buffer=
 =A0
> >> overflows. =A0There is still a lot of code around that will cheerfully=
 =A0
> >> attempt to put ten pounds of shit in a five pound bag!
>
> > Just curious, have you looked at z/os?
>
> That was meant to be asked of Bugs, got out of sync.
>
> --
> PL/I for OpenVMSwww.kednos.com

No, nobody asked us to look at it yet. Buying our own system to find
bugs just for the fun of doing it would probably be a bit too
expensive. It would be fun to try, so if someone got a spare machine
let us know....



0
bugs6 (57)
8/18/2008 4:20:19 PM
In article <04770cca-13df-4103-9fc5-7f5b728f62e7@34g2000hsh.googlegroups.com>, bugs@signedness.org writes:
>{...snip...}
>Well congratulations, now you pissed me off too and not just cmn..

I _was_ going to comment a few posts ago when your last slight begging
for a second "fuck off!" was posted but, and even moreso now, this one
speaks _volumes_ to your claims that you brought this to light to make
VMS more secure.  It comes across more as a "thumb to the nose" wag at
VMS, VMS security, and the people who have worked on it for 3 decades.  



>WE said nothing about DCL.. Our terminology misleading? Funny..
>because it is a security issue, it was presented at a security
>conference, everyone there seemed to get it, and other people in this
>group got it too... If you don't understand what shellcode means,
>don't google it, or ask and then make the wrong assumptions that is
>hardly our fucking fault now is it?

You're reading in things into this.  We were fed piecemeal about the
sordid detail of what was exploitable.  One of your comments was mis-
leading...  

Bugs:
  "Since the PC is controlled in the CLI bug we simply jump to the
   address of a logical that contains the shellcode we want to run."



>OH AND CONDESCENDING????? GIVE ME A FUCKING BREAK! Remember the "1337
>haxOrz" Comment? What do you call that? Yeah we may not be old enough
>to remember the dinosaurs or having written code on punch cards...

Counter to your slight.  I should know your "standard" security jargon
but you wont' use "standard" VMS jargon.



>Well guess what, we still found and exploited multiple vulnerabilities
>in VMS.. even if we are not in the right little click of superior
>beings such as yourself..

Again, volumes...  you should have included a link to this:

http://bestsmileys.com/tongs/21.gif



>Then you say discussing how to "weaponize" this exploit is not a good
>idea for public discussion.... We seem to recall demands that we
>release our exploit.... Double standards??? Oh and talking about your

I asked to have you release the exploit?  Not!  



>shellcode is ok? oh wait... it can't be that you still are trying to
>prove that you are superior to us for using a different method, can
>it?

You are warped.  I used a simple scheme to prove that could be and IS
realizable.  I could care less about superiority; especially, with re-
gards to what has proven to be a snot-nosed twit.



>Or as another poster so elegantly put it:-
>
>"It's amazing how many people can *now* get the egg to stand on its
>end once they've been shown how :-( Oh, but your egg stands so much
>prouder."

Who showed me how?  Oh, I get it, that elided bit of information that
Mr. Jones so kindly provided me.  Really, all I wanted to see is how
you elicited the initial crash dump.  The report was: do this and it
will crash.  Well, it didn't.  Oh, Carl would have enjoyed this...

What I don't see is why you've taken to attacking me save for that 1
or more of the quotations you attributed to me was misquoted in some
prior post.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/18/2008 5:24:11 PM
In article <g8c4v0$s5q$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:

> If the finger server is disabled then the finger client isn't installed with
> any privileges.

   On which stack?  It seems odd to tie the client to the server in that
   way.

0
koehler2 (8314)
8/18/2008 5:48:01 PM
In article <ad4e4896-6f62-450c-958f-7be16eafffb4@i76g2000hsf.googlegroups.com>,
	bugs@signedness.org writes:
> 
> No disgruntled deap-throat, no dead chickens or magic wands... The
> simple truth is very few people have bothered looking at VMS because
> it is "secure".

I think you mis-spelled that.  It's "obscure", not "secure".

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
8/18/2008 5:54:25 PM
In article <abSXhgQ1awuR@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <g8c4v0$s5q$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:
>
>> If the finger server is disabled then the finger client isn't installed with
>> any privileges.
>
>   On which stack?  It seems odd to tie the client to the server in that
>   way.
>
$ ucx sh ver

  HP TCP/IP Services for OpenVMS Alpha Version V5.6
  on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V8.3

There isn't a separate option for enabling the finger client in
TCPIP$CONFIG


        HP TCP/IP Services for OpenVMS Client Components Configuration Menu

        Configuration options:

                 1  -  DHCP Client      Disabled Stopped
                 2  -  FTP Client       Enabled  Started
                 3  -  NFS Client       Disabled Stopped
                 4  -  REXEC and RSH    Disabled Stopped
                 5  -  RLOGIN           Disabled Stopped
                 6  -  SMTP             Disabled Stopped
                 7  -  SSH Client       Enabled  Started
                 8  -  TELNET           Enabled  Started
                 9  -  TELNETSYM        Disabled Stopped

                 A  -  Configure options 1 - 9
                [E] -  Exit menu


There is only the option to enable the FINGER SERVER


  HP TCP/IP Services for OpenVMS Server Components Configuration Menu

  Configuration options:

    1 - BIND         Disabled Stopped      12 - NTP          Enabled  Started
    2 - BOOTP        Disabled Stopped      13 - PC-NFS       Disabled Stopped
    3 - DHCP         Disabled Stopped      14 - POP          Disabled Stopped
    4 - FINGER       Disabled Stopped      15 - PORTMAPPER   Disabled Stopped
    5 - FTP          Enabled  Started      16 - RLOGIN       Enabled  Started
    6 - IMAP         Disabled Stopped      17 - RMT          Disabled Stopped
    7 - LBROKER      Disabled Stopped      18 - SNMP         Disabled Stopped
    8 - LPR/LPD      Disabled Stopped      19 - SSH          Enabled  Started
    9 - METRIC       Disabled Stopped      20 - TELNET       Enabled  Started
   10 - NFS          Disabled Stopped      21 - TFTP         Disabled Stopped
   11 - LOCKD/STATD  Disabled Stopped      22 - XDM          Disabled Stopped


$ sh sym finger
  FINGER == "$SYS$SYSTEM:TCPIP$FINGER.EXE"
$ install
INSTALL> list/full SYS$SYSTEM:TCPIP$FINGER.EXE
%INSTALL-W-FAIL, failed to LIST entry for
DISK$ALPHASYS:<SYS0.SYSCOMMON.SYSEXE>TCPIP$FINGER.EXE
-INSTALL-E-NOKFEFND, Known File Entry not found
INSTALL>

If you 

enable & start the finger server service

FINGER Configuration

Service is defined in the SYSUAF.
Service is defined in the TCPIP$SERVICE database.
Service is not enabled.
Service is stopped.

        FINGER configuration options:

                 1 - Enable service on this node

                 2 - Enable & Start service on this node

                [E] - Exit FINGER configuration

Enter configuration option: 2
%TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$FINGER.EXE installed
%TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$FINGER_SERVER.EXE installed
%TCPIP-I-INFO, service enabled
%TCPIP-S-STARTDONE, TCPIP$FINGER startup completed
Press <ENTER> key to continue ...

Then the finger client is installed with privileges

$ install
INSTALL> list/full sys$system:tcpip$finger.exe

DISK$ALPHASYS:<SYS0.SYSCOMMON.SYSEXE>.EXE
   TCPIP$FINGER;1   Open Hdr Shared   Prv
        Entry access count         = 0
        Current / Maximum shared   = 1 / 0
        Global section count       = 1
        Privileges = WORLD SYSPRV
        Authorized = WORLD SYSPRV


I haven't checked but suspect this has been true for all previous versions of 
UCX/DEC TCPIP services



David Webb
Security team leader
CCSS
Middlesex University
0
david20
8/18/2008 6:20:22 PM
On Aug 18, 6:54 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <ad4e4896-6f62-450c-958f-7be16eaff...@i76g2000hsf.googlegroups.com>,
>         b...@signedness.org writes:
>
>
>
> > No disgruntled deap-throat, no dead chickens or magic wands... The
> > simple truth is very few people have bothered looking at VMS because
> > it is "secure".
>
> I think you mis-spelled that.  It's "obscure", not "secure".
>
> bill
>
> --
> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
> billg...@cs.scranton.edu |  and a sheep voting on what's for dinner.
> University of Scranton   |
> Scranton, Pennsylvania   |         #include <std.disclaimer.h>

VMS these days may be obscure vs its heyday, but traditionally VMS
*is* also relatively secure, especially when managed properly (default
passwords and similar daftness taken as read). Things like
descriptors, STR$ and $FAO and their friends when used properly make
it harder for programs to do daft things which are relatively common
in non-VMS environments, and some of these daft things can clearly be
exploited.

Other OSes could presumably have descriptors etc instead of whatever
they use today (mostly MACRO-11 .ASCIZ relics???), but they mostly
chose other options. Other OSes could also choose to have multiple
classes of privileges and quotas, a proper event log and a proper
audit log and a proper alarm log, but again mostly they choose not to
(and yes I am moderately aware of SE Linux and think lots more people
should be looking at it, but although it's way ahead of Windows, it
still won't get near many of VMS's capabilities, and Windows will
still outship it by the truckload).

There's probably some significance to the fact that the code used in
(one of) the current exploit(s) was derived from non-VMS code, the
tool in the picture is rarely used in classic VMS environments, and
the engineering group which owns the tool has been moved from
continent to continent over the years (which in this case perhaps
indicates a lack of upper-level "ownership" or understanding of the
importance of the IP world, or to put it another way, it wasn't
properly "integrated" (assimilated) into The VMS Engineering Way Of
Things).

Just because something is popular, or big in the market, doesn't mean
it's *right* (just ask your sheep, or a selection of Vista users).

My 2c.
0
8/18/2008 6:40:51 PM
On Mon, 18 Aug 2008 09:20:19 -0700, <bugs@signedness.org> wrote:

> On Aug 18, 4:23�pm, "Tom Linden" <t...@kednos.company> wrote:
>> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <t...@kednos.company>  
>> wrote:
>> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert �
>> > <rgilber...@comcast.net> wrote:
>>
>> >> b...@signedness.org wrote:
>> >>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
>> >>> wrote:
>> >>>> Hi Heine,
>>
>> >>>> Well done!
>>
>> >>>> Regards Richard Maher
>>
>> >>>> PS. Not that it is important, but what I am sceptical about is how  
>> �
>> >>>> "bugs"
>> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone  
>> �
>> >>>> post the
>> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege �
>> >>>> vulnerability
>> >>>> that occurs everyday in Windows/*nix yet no-one has found on VMS �
>> >>>> before,
>> >>>> without the help of a few days "generic" hacking, or perhaps the  
>> help �
>> >>>> of a
>> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times,  
>> wave a
>> >>>> dead-chicken over your head and howl at the moon - standard stuff  
>> for
>> >>>> hackers?)
>>
>> >>> �No disgruntled deap-throat, no dead chickens or magic wands... The
>> >>> simple truth is very few people have bothered looking at VMS because
>> >>> it is "secure". If nobody is looking for bugs then no bugs are  
>> found.
>> >>> How many times have we heard "many eyes makes all bugs shallow"?  
>> Well
>> >>> still we see really dumb bugs popping up in some of the most popular
>> >>> open source applications so it is really that surprising that simple
>> >>> bugs are found in an operating system that I would assume very few
>> >>> have looked for bugs in since the 80s? (that being said, still a  
>> nice
>> >>> find by cmn :))
>> >>> �The finger client bugs are good examples, more or less anyone would
>> >>> have found them if they bothered looking for security bugs. The
>> >>> seriousness of format string vulnerabilities has been widely known  
>> for
>> >>> almost 10 years and still there it is (of course it was probably +15
>> >>> years since anybody had a serious go at owning VMS).. Speaking of 20
>> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone  
>> remember
>> >>> Morris worm? Almost exactly 20 year old bug...
>>
>> >> Hell, yes! �There may be some newbies around who haven't heard of it  
>> �
>> >> but I was there while it was happening. �Fortunately, I was  
>> responsible �
>> >> only for some VMS systems which were not affected. �Most of the Unix  
>> �
>> >> systems in the world were affected. �For those newbies who missed  
>> it, �
>> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg", that �
>> >> touches the subject briefly. �I'd say it's a "must read" for anyone �
>> >> interested in system security. �It's the only first person account  
>> that �
>> >> I know of but there may be others.
>>
>> >> VMS System Managers are probably aware of a list of forbidden  
>> passwords �
>> >> maintained by the system. �500 or so of the entries are Robert  
>> Morris' �
>> >> list of commonly used passwords! �His worm used them to attempt to  
>> log �
>> >> on to his target systems. �He also abused a buffer overflow �
>> >> vulnerability in the finger daemon. �The systems the worm penetrated  
>> �
>> >> promptly started trying to subvert other systems. . . . �It was an �
>> >> interesting two or three days for the Unix system administrators.  
>> �VMS
>> >> systems were largely unaffected.
>>
>> >> Difficult as it may be to believe, hackers are STILL exploiting  
>> buffer �
>> >> overflows. �There is still a lot of code around that will cheerfully  
>> �
>> >> attempt to put ten pounds of shit in a five pound bag!
>>
>> > Just curious, have you looked at z/os?
>>
>> That was meant to be asked of Bugs, got out of sync.
>>
>> --
>> PL/I for OpenVMSwww.kednos.com
>
> No, nobody asked us to look at it yet. Buying our own system to find
> bugs just for the fun of doing it would probably be a bit too
> expensive. It would be fun to try, so if someone got a spare machine
> let us know....
>
>
>
You could run the Hercules emulator, I bet you might even get IBM to loan
you a copy of z/os.  The reason I asked was to compare with VMS since the
two are often compared in terms of security, the difference is in the
implementation in which IBM uses a string safe language, with stringrange
checking as an inherenty part of the language, PLS.


-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/18/2008 6:59:47 PM
On Aug 18, 7:59 pm, "Tom Linden" <t...@kednos.company> wrote:
> On Mon, 18 Aug 2008 09:20:19 -0700, <b...@signedness.org> wrote:
> > On Aug 18, 4:23 pm, "Tom Linden" <t...@kednos.company> wrote:
> >> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <t...@kednos.company>
> >> wrote:
> >> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert
> >> > <rgilber...@comcast.net> wrote:
>
> >> >> b...@signedness.org wrote:
> >> >>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
> >> >>> wrote:
> >> >>>> Hi Heine,
>
> >> >>>> Well done!
>
> >> >>>> Regards Richard Maher
>
> >> >>>> PS. Not that it is important, but what I am sceptical about is how
> >>
> >> >>>> "bugs"
> >> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone
> >>
> >> >>>> post the
> >> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege
> >> >>>> vulnerability
> >> >>>> that occurs everyday in Windows/*nix yet no-one has found on VMS
> >> >>>> before,
> >> >>>> without the help of a few days "generic" hacking, or perhaps the
> >> help
> >> >>>> of a
> >> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times,
> >> wave a
> >> >>>> dead-chicken over your head and howl at the moon - standard stuff
> >> for
> >> >>>> hackers?)
>
> >> >>>  No disgruntled deap-throat, no dead chickens or magic wands... The
> >> >>> simple truth is very few people have bothered looking at VMS because
> >> >>> it is "secure". If nobody is looking for bugs then no bugs are
> >> found.
> >> >>> How many times have we heard "many eyes makes all bugs shallow"?
> >> Well
> >> >>> still we see really dumb bugs popping up in some of the most popular
> >> >>> open source applications so it is really that surprising that simple
> >> >>> bugs are found in an operating system that I would assume very few
> >> >>> have looked for bugs in since the 80s? (that being said, still a
> >> nice
> >> >>> find by cmn :))
> >> >>>  The finger client bugs are good examples, more or less anyone would
> >> >>> have found them if they bothered looking for security bugs. The
> >> >>> seriousness of format string vulnerabilities has been widely known
> >> for
> >> >>> almost 10 years and still there it is (of course it was probably +15
> >> >>> years since anybody had a serious go at owning VMS).. Speaking of 20
> >> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone
> >> remember
> >> >>> Morris worm? Almost exactly 20 year old bug...
>
> >> >> Hell, yes!  There may be some newbies around who haven't heard of it
> >>
> >> >> but I was there while it was happening.  Fortunately, I was
> >> responsible
> >> >> only for some VMS systems which were not affected.  Most of the Unix
> >>
> >> >> systems in the world were affected.  For those newbies who missed
> >> it,
> >> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg", that
> >> >> touches the subject briefly.  I'd say it's a "must read" for anyone
> >> >> interested in system security.  It's the only first person account
> >> that
> >> >> I know of but there may be others.
>
> >> >> VMS System Managers are probably aware of a list of forbidden
> >> passwords
> >> >> maintained by the system.  500 or so of the entries are Robert
> >> Morris'
> >> >> list of commonly used passwords!  His worm used them to attempt to
> >> log
> >> >> on to his target systems.  He also abused a buffer overflow
> >> >> vulnerability in the finger daemon.  The systems the worm penetrated
> >>
> >> >> promptly started trying to subvert other systems. . . .  It was an
> >> >> interesting two or three days for the Unix system administrators.
> >>  VMS
> >> >> systems were largely unaffected.
>
> >> >> Difficult as it may be to believe, hackers are STILL exploiting
> >> buffer
> >> >> overflows.  There is still a lot of code around that will cheerfully
> >>
> >> >> attempt to put ten pounds of shit in a five pound bag!
>
> >> > Just curious, have you looked at z/os?
>
> >> That was meant to be asked of Bugs, got out of sync.
>
> >> --
> >> PL/I for OpenVMSwww.kednos.com
>
> > No, nobody asked us to look at it yet. Buying our own system to find
> > bugs just for the fun of doing it would probably be a bit too
> > expensive. It would be fun to try, so if someone got a spare machine
> > let us know....
>
> You could run the Hercules emulator, I bet you might even get IBM to loan
> you a copy of z/os.  The reason I asked was to compare with VMS since the
> two are often compared in terms of security, the difference is in the
> implementation in which IBM uses a string safe language, with stringrange
> checking as an inherenty part of the language, PLS.
>
> --
> PL/I for OpenVMSwww.kednos.com

"a string safe language, with stringrange checking as an inherenty
part of the language"

You mean like VMS languages/compilers with built-in descriptor support
for string variables (BASIC, Fortran, Pascal, others?) have had pretty
much since they were invented, and still have? Should I have included
VMS PL/I on that list (I'm thinking yes, but not confident)?
0
8/18/2008 7:08:49 PM
On Aug 18, 2:59 pm, "Tom Linden" <t...@kednos.company> wrote:
> On Mon, 18 Aug 2008 09:20:19 -0700, <b...@signedness.org> wrote:
> > On Aug 18, 4:23 pm, "Tom Linden" <t...@kednos.company> wrote:
> >> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <t...@kednos.company>
> >> wrote:
> >> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert
> >> > <rgilber...@comcast.net> wrote:
>
> >> >> b...@signedness.org wrote:
> >> >>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
> >> >>> wrote:
> >> >>>> Hi Heine,
>
> >> >>>> Well done!
>
> >> >>>> Regards Richard Maher
>
> >> >>>> PS. Not that it is important, but what I am sceptical about is how
> >>
> >> >>>> "bugs"
> >> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone
> >>
> >> >>>> post the
> >> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege
> >> >>>> vulnerability
> >> >>>> that occurs everyday in Windows/*nix yet no-one has found on VMS
> >> >>>> before,
> >> >>>> without the help of a few days "generic" hacking, or perhaps the
> >> help
> >> >>>> of a
> >> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times,
> >> wave a
> >> >>>> dead-chicken over your head and howl at the moon - standard stuff
> >> for
> >> >>>> hackers?)
>
> >> >>>  No disgruntled deap-throat, no dead chickens or magic wands... The
> >> >>> simple truth is very few people have bothered looking at VMS because
> >> >>> it is "secure". If nobody is looking for bugs then no bugs are
> >> found.
> >> >>> How many times have we heard "many eyes makes all bugs shallow"?
> >> Well
> >> >>> still we see really dumb bugs popping up in some of the most popular
> >> >>> open source applications so it is really that surprising that simple
> >> >>> bugs are found in an operating system that I would assume very few
> >> >>> have looked for bugs in since the 80s? (that being said, still a
> >> nice
> >> >>> find by cmn :))
> >> >>>  The finger client bugs are good examples, more or less anyone would
> >> >>> have found them if they bothered looking for security bugs. The
> >> >>> seriousness of format string vulnerabilities has been widely known
> >> for
> >> >>> almost 10 years and still there it is (of course it was probably +15
> >> >>> years since anybody had a serious go at owning VMS).. Speaking of 20
> >> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone
> >> remember
> >> >>> Morris worm? Almost exactly 20 year old bug...
>
> >> >> Hell, yes!  There may be some newbies around who haven't heard of it
> >>
> >> >> but I was there while it was happening.  Fortunately, I was
> >> responsible
> >> >> only for some VMS systems which were not affected.  Most of the Unix
> >>
> >> >> systems in the world were affected.  For those newbies who missed
> >> it,
> >> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg", that
> >> >> touches the subject briefly.  I'd say it's a "must read" for anyone
> >> >> interested in system security.  It's the only first person account
> >> that
> >> >> I know of but there may be others.
>
> >> >> VMS System Managers are probably aware of a list of forbidden
> >> passwords
> >> >> maintained by the system.  500 or so of the entries are Robert
> >> Morris'
> >> >> list of commonly used passwords!  His worm used them to attempt to
> >> log
> >> >> on to his target systems.  He also abused a buffer overflow
> >> >> vulnerability in the finger daemon.  The systems the worm penetrated
> >>
> >> >> promptly started trying to subvert other systems. . . .  It was an
> >> >> interesting two or three days for the Unix system administrators.
> >>  VMS
> >> >> systems were largely unaffected.
>
> >> >> Difficult as it may be to believe, hackers are STILL exploiting
> >> buffer
> >> >> overflows.  There is still a lot of code around that will cheerfully
> >>
> >> >> attempt to put ten pounds of shit in a five pound bag!
>
> >> > Just curious, have you looked at z/os?
>
> >> That was meant to be asked of Bugs, got out of sync.
>
> >> --
> >> PL/I for OpenVMSwww.kednos.com
>
> > No, nobody asked us to look at it yet. Buying our own system to find
> > bugs just for the fun of doing it would probably be a bit too
> > expensive. It would be fun to try, so if someone got a spare machine
> > let us know....
>
> You could run the Hercules emulator, I bet you might even get IBM to loan
> you a copy of z/os.  The reason I asked was to compare with VMS since the
> two are often compared in terms of security, the difference is in the
> implementation in which IBM uses a string safe language, with stringrange
> checking as an inherenty part of the language, PLS.
>
> --
> PL/I for OpenVMSwww.kednos.com

I've been attempting to land an "academic version" of z/os, which
apparently exist - as shown here:

http://en.wikipedia.org/wiki/Image:ZOS_welcome_screen.png


0
jferraro (20)
8/18/2008 7:33:12 PM
In article <g8bree$23k$1@news-01.bur.connect.com.au>, "Richard Maher" <maher_rj@hotspamnotmail.com> writes:
>It's amazing how many people can *now* get the egg to stand on its end once
>they've been shown how :-( Oh, but your egg stands so much prouder.

I realize you've got some hair up your ass for VMS or VMS management or
what have you.  I do not, however, understand what I've done to you to
warrant your ilk and disparagement?  My ENTIRE contribution to this has
stemmed from trying to get a reported "CLI" stack dump to occur using
the scant and flawed description provided.  FWIW, HP has this patched
and I've received an email from Andy G. about it.  The bug has NOTHING
to do with the CLI, BTW.

Now, if you want to side with Mr. bugs and his common everyday security
lexicon, go ahead and do so.  However, the tossing about of terminology
rooted in unixdom in a VMS forum using the coherence of a Kerouac novel
does not indicate that I was shown how to exploit this bug.  The *only*
thing I was missing was the SET TERMINAL/UNKNOWN.  The causes the escape
in the UP-ARROW (doesn't matter how many, the *first* escape is what is
import) to not be interpretted by the terminal driver but is, instead,
passes along.

The video, to me, explains nothing.  I see AAAs being typed while some
'shellcode' has launched the INSTALL utility.  Have YOU watched them?

FWIW, their method obfuscated a very very very simple implementation. 
There's no need for the FILE.EXE red-herring; there's no need to write
a command interpreter to run INSTALL; there's no reason they could NOT
have cleanly returned from injecting their code.  They somehow figured
out HOW to feign a linkage pointer (and I'd wager I know WHERE they've
learned that technique ;) ) from a code address.  This is on an Alpha
and one cannot invoke a system routine (SYS$CREPRC as they've reported
or any code for that matter) without a linkage pointer.  If they COULD
figure that out, the should have been able to figure out a very simple
clean implementation that would have CLEARLY implemented the problem.

At least, I'm vindicated by Mr. Robinson's post about the video codec.
I doubt, however, that "bugs" will come back and apologise to me for 
his outlash.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/18/2008 7:41:13 PM
On Mon, 18 Aug 2008 12:08:49 -0700, <johnwallace4@yahoo.co.uk> wrote:

> On Aug 18, 7:59 pm, "Tom Linden" <t...@kednos.company> wrote:
>> On Mon, 18 Aug 2008 09:20:19 -0700, <b...@signedness.org> wrote:
>> > On Aug 18, 4:23 pm, "Tom Linden" <t...@kednos.company> wrote:
>> >> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <t...@kednos.company>
>> >> wrote:
>> >> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert
>> >> > <rgilber...@comcast.net> wrote:
>>
>> >> >> b...@signedness.org wrote:
>> >> >>> On Aug 18, 12:09 pm, "Richard Maher"  
>> <maher...@hotspamnotmail.com>
>> >> >>> wrote:
>> >> >>>> Hi Heine,
>>
>> >> >>>> Well done!
>>
>> >> >>>> Regards Richard Maher
>>
>> >> >>>> PS. Not that it is important, but what I am sceptical about is  
>> how
>> >>
>> >> >>>> "bugs"
>> >> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can  
>> someone
>> >>
>> >> >>>> post the
>> >> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege
>> >> >>>> vulnerability
>> >> >>>> that occurs everyday in Windows/*nix yet no-one has found on VMS
>> >> >>>> before,
>> >> >>>> without the help of a few days "generic" hacking, or perhaps the
>> >> help
>> >> >>>> of a
>> >> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times,
>> >> wave a
>> >> >>>> dead-chicken over your head and howl at the moon - standard  
>> stuff
>> >> for
>> >> >>>> hackers?)
>>
>> >> >>>  No disgruntled deap-throat, no dead chickens or magic wands...  
>> The
>> >> >>> simple truth is very few people have bothered looking at VMS  
>> because
>> >> >>> it is "secure". If nobody is looking for bugs then no bugs are
>> >> found.
>> >> >>> How many times have we heard "many eyes makes all bugs shallow"?
>> >> Well
>> >> >>> still we see really dumb bugs popping up in some of the most  
>> popular
>> >> >>> open source applications so it is really that surprising that  
>> simple
>> >> >>> bugs are found in an operating system that I would assume very  
>> few
>> >> >>> have looked for bugs in since the 80s? (that being said, still a
>> >> nice
>> >> >>> find by cmn :))
>> >> >>>  The finger client bugs are good examples, more or less anyone  
>> would
>> >> >>> have found them if they bothered looking for security bugs. The
>> >> >>> seriousness of format string vulnerabilities has been widely  
>> known
>> >> for
>> >> >>> almost 10 years and still there it is (of course it was probably  
>> +15
>> >> >>> years since anybody had a serious go at owning VMS).. Speaking  
>> of 20
>> >> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone
>> >> remember
>> >> >>> Morris worm? Almost exactly 20 year old bug...
>>
>> >> >> Hell, yes!  There may be some newbies around who haven't heard of  
>> it
>> >>
>> >> >> but I was there while it was happening.  Fortunately, I was
>> >> responsible
>> >> >> only for some VMS systems which were not affected.  Most of the  
>> Unix
>> >>
>> >> >> systems in the world were affected.  For those newbies who missed
>> >> it,
>> >> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg",  
>> that
>> >> >> touches the subject briefly.  I'd say it's a "must read" for  
>> anyone
>> >> >> interested in system security.  It's the only first person account
>> >> that
>> >> >> I know of but there may be others.
>>
>> >> >> VMS System Managers are probably aware of a list of forbidden
>> >> passwords
>> >> >> maintained by the system.  500 or so of the entries are Robert
>> >> Morris'
>> >> >> list of commonly used passwords!  His worm used them to attempt to
>> >> log
>> >> >> on to his target systems.  He also abused a buffer overflow
>> >> >> vulnerability in the finger daemon.  The systems the worm  
>> penetrated
>> >>
>> >> >> promptly started trying to subvert other systems. . . .  It was an
>> >> >> interesting two or three days for the Unix system administrators.
>> >>  VMS
>> >> >> systems were largely unaffected.
>>
>> >> >> Difficult as it may be to believe, hackers are STILL exploiting
>> >> buffer
>> >> >> overflows.  There is still a lot of code around that will  
>> cheerfully
>> >>
>> >> >> attempt to put ten pounds of shit in a five pound bag!
>>
>> >> > Just curious, have you looked at z/os?
>>
>> >> That was meant to be asked of Bugs, got out of sync.
>>
>> >> --
>> >> PL/I for OpenVMSwww.kednos.com
>>
>> > No, nobody asked us to look at it yet. Buying our own system to find
>> > bugs just for the fun of doing it would probably be a bit too
>> > expensive. It would be fun to try, so if someone got a spare machine
>> > let us know....
>>
>> You could run the Hercules emulator, I bet you might even get IBM to  
>> loan
>> you a copy of z/os.  The reason I asked was to compare with VMS since  
>> the
>> two are often compared in terms of security, the difference is in the
>> implementation in which IBM uses a string safe language, with  
>> stringrange
>> checking as an inherenty part of the language, PLS.
>>
>> --
>> PL/I for OpenVMSwww.kednos.com
>
> "a string safe language, with stringrange checking as an inherenty
> part of the language"
>
> You mean like VMS languages/compilers with built-in descriptor support
> for string variables (BASIC, Fortran, Pascal, others?) have had pretty
> much since they were invented, and still have? Should I have included
> VMS PL/I on that list (I'm thinking yes, but not confident)?

Close, but a bit more, e.g.,
In your code you would include following which is inherited by all  
contained
scopes to which you would jump (pushing a new stack frame) upon the  
condition
being signaled.
....
ON SUBSCRIPTRANGE BEGIN;
    <recovery code>
    END;

ON SUBSCRIPTRANGE BEGIN;
    <recovery code>
    END;

....

etc.
descriptors, or dope vectors are used by the compiler, the programmer  
doesn't
have to explicitly use them, making coding a bit more streamlined.  In PL/I
you can code your own signals, called condtions, which is a valid data  
type.

END returns to statement following where condition was signaled.
-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/18/2008 8:32:51 PM
bugs@signedness.org wrote:

> WE said nothing about DCL.. Our terminology misleading? Funny..

A lot of people here were initially under the impression that you were
talking about DCL. I think it was Sampsa L who came in and added that
this was for utilities that had command recall, not for DCL.

If you had started with "utilities that used command recall", there
would have been no confusion.




> because it is a security issue, it was presented at a security
> conference, everyone there seemed to get it, and other people in this
> group got it too...

Since probably less than 0.000001% of the people at your security
convention knew VMS, they would understand the concepts because they
spoke your langage, but wouldn't understand what goes on under the hood
because they wouldn't understand VMS.

The lesson for you is that when you barge in a new community, you cannot
assume that they will speak your language, especially for an OS you are
not overly familiar about. And IBM mainframe guy coming here and talking
about DASD would get blank stares. We use "disk drives" here.

Now we know what your use of "shellcode" means. But it took a while to
get it cleared up.

It wasn't just "shellcode" that confused people here, it was a
collection of things, such as your irrelevant FILE.EXE discussion, the
finger stuff, mention of CLI (when in fact it wasn't CLU, it was SMG
with command recall) which made it very hard for many to see the big
picture which would have been explained very simply from the get go:

Within utilities that support command recall, entering a 511 byte
command, followed by 3 up arrows, followed by 4 bytes will cause that
utillity to branch to the address specified by those 4 bytes.

This would have provided a clear, concise and easily understood issue.

You could have then proceeded to explain how to tested this with your
code stored in a logical name (known memory location you could branch
to), and that code calling SYS$CREPRC to create a subprocess that
inherited the privileges of the installed utility.

There were *many* here who were confused by your terminology. So perhaps
you should reviuew your assumption that everyone in the IT industry
knows your DEFCON terminology.


> If you don't understand what shellcode means,

To many, we interpreted "shellcode" as code that runs in a shell. AKA:
DCL commands in a VMS command procedure , Unix commands in a unix
script, DOS commands in a .BAT file etc. This provided great amount of
confusion to your explanations.

You assumed that everyone n the IT business would have the same
interpretation of the term "shellcode". This assumption was proven wrong
in this newsgroup. Perhaps we are an isolated bunch, perhaps your
"shellcode" definition isn't as widely known as you think it is. I don't
know. But next time, you jump into a newsgroup of an unfamiliar OS, keep
this in mind.
0
8/18/2008 9:10:01 PM
johnwallace4@yahoo.co.uk wrote:

> VMS these days may be obscure vs its heyday, but traditionally VMS
> *is* also relatively secure, especially when managed properly (default
> passwords and similar daftness taken as read). Things like
> descriptors, STR$ and $FAO and their friends when used properly make
> it harder for programs to do daft things 


Existance of descriptors is neat, but it didn't prevent this particular
buffer overflow.

Existance of ACME routines for intrusion signaling/detection is neat,
but if POP, IMAP and others doN't use them, it allows hackers to use
brute force to guess passwords and go undetected.

VMS *used* to be secure. But software that was added in the last decade
tends to not use those security measures and makes VMS no so secure anymore.

Anyone remember the POP server problem when you could manually start the
POP server interfactively and specify a log filename and the image,
being privileged, would create that log wherever you specified it , even
though you didn't have access to that directory/file ?
0
8/18/2008 9:16:41 PM
Tom Linden schrieb:

> In your code you would include following which is inherited by all  
> contained
> scopes to which you would jump (pushing a new stack frame) upon the  
> condition
> being signaled.
> ...
> ON SUBSCRIPTRANGE BEGIN;
>    <recovery code>
>    END;

> 
> etc.
> descriptors, or dope vectors are used by the compiler, the programmer  
> doesn't
> have to explicitly use them, making coding a bit more streamlined.  

My memory may be a bit rusty, but AFAIR the *RANGE conditions
are usually disabled in production code.
Moreover, descriptors can be trashed as well since they are passed
by reference, as are all parameters in PL/I.

0
M.Kraemer (2048)
8/18/2008 9:22:22 PM
On Sun, 17 Aug 2008 20:03:51 -0700 (PDT), FrankS <sapienza@noesys.com> wrote:

> >The bug has probably been in the
> > code longer than DEFCONs have been around.
> 
> I just reproduced the problem on VMS v6.2 (VAX).
> 
> Anybody got a v5.5-2 or earlier running?

VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug. This is the
actual image identification information for SMGSHR.EXE found in V5.5-2:

                image name: "SMGSHR"
                image file identification: "V05-003"
                link date/time:  8-JUL-1992 00:50:52.33
                linker identification: "05-13"

Instead, the all mighty VAX/VMS V4.7 has NO bug! This is the actual image
indentification information for SMGSHR.EXE found in V4.7:

                image name: "SMGSHR"
                image file identification: "V04-006"
                link date/time: 22-MAY-1987 23:19:57.76
                linker identification: "04-00"

This has been patched with security update V2.0 and V3.0, but none of them
ever modified the SMGSHR.EXE originally shipped with V4.7.

Proof:

ATHENA::RPT$ set host florry

Username: SYSTEM
Password:
        Welcome to VAX/VMS version V4.7 on node FLORRY
    Last interactive login on Monday, 18-AUG-2008 22:35

$ sho sys
VAX/VMS V4.7  on node FLORRY 18-AUG-2008 22:48:30.85   Uptime    0 00:35:24
  Pid    Process Name    State  Pri      I/O       CPU       Page flts Ph.Mem
00000100 NULL            COM      0        0   0 00:35:03.80         0      0
00000101 SWAPPER         HIB     16        0   0 00:00:00.05         0      0
(...)

$ set term/dev=unknown
$ sho term
Terminal: _RTA2:      Device_Type: Unknown       Owner: _RTA2:
(...)

$ mail

MAIL> 12345678901234567890123456789012345678901234567890123456789012(...)
5678901234567890123456789012345678901(up, up, up, @@@@)

It stops here. No error message and no ACCVIO, nothing. And it doesn't appear
to be on loop as per the following CTRL/T output:

FLORRY::_RTA2: 22:51:31 MAIL      CPU=00:00:05.05 PF=2887 IO=2113 MEM=421
FLORRY::_RTA2: 22:51:32 MAIL      CPU=00:00:05.05 PF=2887 IO=2114 MEM=421
FLORRY::_RTA2: 22:51:36 MAIL      CPU=00:00:05.05 PF=2887 IO=2115 MEM=421
FLORRY::_RTA2: 22:52:06 MAIL      CPU=00:00:05.05 PF=2887 IO=2116 MEM=421
FLORRY::_RTA2: 22:57:03 MAIL      CPU=00:00:05.05 PF=2887 IO=2117 MEM=421

Obviously MAIL.EXE uses SMGSHR.EXE, I've checked it:

$ ana/ima sys$system:mail.exe /out=ana_mail.tmp
%ANALYZE-I-ERRORS, SYS$SYSROOT:[SYSEXE]MAIL.EXE;1              0 errors
$ search ana_mail.tmp smgshr
                        global section name: "SMGSHR_001"
                2)  "SMGSHR"
$

Maybe the bug comes from V5.x "improvements"?

Bye,
G.


-- 
Italian Hobbyist DECnet Network - http://decnet.ipv7.net
0
gerry77 (72)
8/18/2008 9:35:42 PM
On Mon, 18 Aug 2008 14:22:22 -0700, Michael Kraemer <M.Kraemer@gsi.de>  
wrote:

> Tom Linden schrieb:
>
>> In your code you would include following which is inherited by all   
>> contained
>> scopes to which you would jump (pushing a new stack frame) upon the   
>> condition
>> being signaled.
>> ...
>> ON SUBSCRIPTRANGE BEGIN;
>>    <recovery code>
>>    END;
>
>>  etc.
>> descriptors, or dope vectors are used by the compiler, the programmer   
>> doesn't
>> have to explicitly use them, making coding a bit more streamlined.
>
> My memory may be a bit rusty, but AFAIR the *RANGE conditions
> are usually disabled in production code.
> Moreover, descriptors can be trashed as well since they are passed
> by reference, as are all parameters in PL/I.
>
I have always kept them in production code, I try to write failsafe code,
don't always succeed, but that is the goal.   Don't use descriptors, pass
by value if you are concerned about refrence  (By value in PL/I means that
a copy of the object is made in local store and a pointer to that is  
passed)


-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/18/2008 9:50:18 PM
OK, the presentation slides are at:

<http://deathrow.vistech.net/defcon16>

Follow up there or here...
0
BRAD77 (76)
8/18/2008 10:03:16 PM
Tom Linden schrieb:

> I have always kept them in production code, I try to write failsafe code,
> don't always succeed, but that is the goal.   Don't use descriptors, pass
> by value if you are concerned about refrence  (By value in PL/I means that
> a copy of the object is made in local store and a pointer to that is  
> passed)

Of course one *can* do all that,
but it depends on the good will of the programmer
(just as avoiding buffer overflows in other languages).
It is not inherent to the language.

0
M.Kraemer (2048)
8/18/2008 10:25:48 PM
On Aug 18, 7:59=A0pm, "Tom Linden" <t...@kednos.company> wrote:
> On Mon, 18 Aug 2008 09:20:19 -0700, <b...@signedness.org> wrote:
> > On Aug 18, 4:23=A0pm, "Tom Linden" <t...@kednos.company> wrote:
> >> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <t...@kednos.company> =
=A0
> >> wrote:
> >> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert =A0
> >> > <rgilber...@comcast.net> wrote:
>
> >> >> b...@signedness.org wrote:
> >> >>> On Aug 18, 12:09 pm, "Richard Maher" <maher...@hotspamnotmail.com>
> >> >>> wrote:
> >> >>>> Hi Heine,
>
> >> >>>> Well done!
>
> >> >>>> Regards Richard Maher
>
> >> >>>> PS. Not that it is important, but what I am sceptical about is ho=
w =A0
> >> =A0
> >> >>>> "bugs"
> >> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can someon=
e =A0
> >> =A0
> >> >>>> post the
> >> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege =A0
> >> >>>> vulnerability
> >> >>>> that occurs everyday in Windows/*nix yet no-one has found on VMS =
=A0
> >> >>>> before,
> >> >>>> without the help of a few days "generic" hacking, or perhaps the =
=A0
> >> help =A0
> >> >>>> of a
> >> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, =
=A0
> >> wave a
> >> >>>> dead-chicken over your head and howl at the moon - standard stuff=
 =A0
> >> for
> >> >>>> hackers?)
>
> >> >>> =A0No disgruntled deap-throat, no dead chickens or magic wands... =
The
> >> >>> simple truth is very few people have bothered looking at VMS becau=
se
> >> >>> it is "secure". If nobody is looking for bugs then no bugs are =A0
> >> found.
> >> >>> How many times have we heard "many eyes makes all bugs shallow"? =
=A0
> >> Well
> >> >>> still we see really dumb bugs popping up in some of the most popul=
ar
> >> >>> open source applications so it is really that surprising that simp=
le
> >> >>> bugs are found in an operating system that I would assume very few
> >> >>> have looked for bugs in since the 80s? (that being said, still a =
=A0
> >> nice
> >> >>> find by cmn :))
> >> >>> =A0The finger client bugs are good examples, more or less anyone w=
ould
> >> >>> have found them if they bothered looking for security bugs. The
> >> >>> seriousness of format string vulnerabilities has been widely known=
 =A0
> >> for
> >> >>> almost 10 years and still there it is (of course it was probably +=
15
> >> >>> years since anybody had a serious go at owning VMS).. Speaking of =
20
> >> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone =A0
> >> remember
> >> >>> Morris worm? Almost exactly 20 year old bug...
>
> >> >> Hell, yes! =A0There may be some newbies around who haven't heard of=
 it =A0
> >> =A0
> >> >> but I was there while it was happening. =A0Fortunately, I was =A0
> >> responsible =A0
> >> >> only for some VMS systems which were not affected. =A0Most of the U=
nix =A0
> >> =A0
> >> >> systems in the world were affected. =A0For those newbies who missed=
 =A0
> >> it, =A0
> >> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg", that=
 =A0
> >> >> touches the subject briefly. =A0I'd say it's a "must read" for anyo=
ne =A0
> >> >> interested in system security. =A0It's the only first person accoun=
t =A0
> >> that =A0
> >> >> I know of but there may be others.
>
> >> >> VMS System Managers are probably aware of a list of forbidden =A0
> >> passwords =A0
> >> >> maintained by the system. =A0500 or so of the entries are Robert =
=A0
> >> Morris' =A0
> >> >> list of commonly used passwords! =A0His worm used them to attempt t=
o =A0
> >> log =A0
> >> >> on to his target systems. =A0He also abused a buffer overflow =A0
> >> >> vulnerability in the finger daemon. =A0The systems the worm penetra=
ted =A0
> >> =A0
> >> >> promptly started trying to subvert other systems. . . . =A0It was a=
n =A0
> >> >> interesting two or three days for the Unix system administrators. =
=A0
> >> =A0VMS
> >> >> systems were largely unaffected.
>
> >> >> Difficult as it may be to believe, hackers are STILL exploiting =A0
> >> buffer =A0
> >> >> overflows. =A0There is still a lot of code around that will cheerfu=
lly =A0
> >> =A0
> >> >> attempt to put ten pounds of shit in a five pound bag!
>
> >> > Just curious, have you looked at z/os?
>
> >> That was meant to be asked of Bugs, got out of sync.
>
> >> --
> >> PL/I for OpenVMSwww.kednos.com
>
> > No, nobody asked us to look at it yet. Buying our own system to find
> > bugs just for the fun of doing it would probably be a bit too
> > expensive. It would be fun to try, so if someone got a spare machine
> > let us know....
>
> You could run the Hercules emulator, I bet you might even get IBM to loan
> you a copy of z/os. =A0The reason I asked was to compare with VMS since t=
he
> two are often compared in terms of security, the difference is in the
> implementation in which IBM uses a string safe language, with stringrange
> checking as an inherenty part of the language, PLS.
>
> --
> PL/I for OpenVMSwww.kednos.com

Any idea who you would ask at IBM for that?

I would not be surprised if this language I never heard of had its own
set of problems with strings though.. Other "safe" languages, maybe
most notably python and php have had some really bad bugs in their
interpretors dealing with this if I remember correctly.

0
bugs6 (57)
8/18/2008 10:42:21 PM
On Aug 18, 5:35=A0pm, gerr...@no.spam.mail.com wrote:
> VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.

Interesting.  That's something like 16 years that the bug has been
around and never been spotted?

I guess that shows that there aren't many people working on VMS that
spend their days keying in 511+ characters looking for buffer
overflows.

:-)
0
sapienza (410)
8/18/2008 10:55:57 PM
In article <981bad40-b598-435c-92a1-4e8b0ffe344c@59g2000hsb.googlegroups.com>, 
FrankS wrote:
>On Aug 18, 5:35�pm, gerr...@no.spam.mail.com wrote:
>> VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.
>
>Interesting.  That's something like 16 years that the bug has been
>around and never been spotted?
>
>I guess that shows that there aren't many people working on VMS that
>spend their days keying in 511+ characters looking for buffer
>overflows.
>
>:-)

I think that one can argue that the vendor could have (should have?) had such a
person (or small team) doing something like that.  I imagine periodic 
full-blown code reviews or in-house hackers could be seen as money wasted, but
I think there is some value in efforts along those lines.
0
BRAD77 (76)
8/18/2008 11:01:53 PM
bugs@signedness.org wrote:
> On Aug 18, 1:21 pm, VAXman-  @SendSpamHere.ORG wrote:
> 
>>In article <fd91dcfd-933d-495b-8f35-f4d3aaccb...@26g2000hsk.googlegroups.com>, b...@signedness.org writes:
>>
>>
>>
>>
>>>On Aug 17, 10:09 pm, VAXman-  @SendSpamHere.ORG wrote:
>>
>>>>>It was pointed to you that the codecs used in the videos are
>>>>>non-standard and cannot be watched by everyone. I also didn't even
>>>>>bother to download them.
>>>
>>>It is a VMWare recording for heavens sake (http://www.vmware.com)!
>>>If you have bothered to download the videos you would probably not
>>>have
>>>played around with DCL commands and asked about FILE.EXE in the first
>>>place.
>>
>>>>A cohesive explaination of reproducing the stack dump would have been
>>>>better than some video of a terminal session.  There was also a report
>>>>of no audio explaining what was happening in the video.
>>>
>>>It is a VMWare recording (http://www.vmware.com/), it has no sound.
>>>We used the videos in our presentation (and yes, we did actually
>>>talk while playing them).
>>
>>>>>Your introduction of FILE.EXE was absolutely confusing. This was not
>>>>>necessary. And reduced your credibility because it put the focus on the
>>>>>"file.exe" instead of on the actual vulnerability.
>>
>>>>Another valid point.
>>>
>>>Again, you did not watch the videos, i.e. you did not input all data
>>>before computing.
>>
>>>You continue to claim that we have done things wrong when trying to
>>>explain the vulnerability that you tried to wave away as a hoax. Your
>>>attitude strongly imply that this has nothing to do with terminology
>>>and codecs, but that your ego got bumped really hard, and you can not
>>>handle it.
>>
>>There's no need for you to be so condescending.
>>
>>It's not about ego.  I, and others here, were trying to determine if
>>this truly was a vulnerability.  The first reports were that this was
>>a vulnerability in the DCL CLI easily exploited with a buffer over-
>>flow.  The published instructions to cause the overflow did NOT pro-
>>duce the results reported.  _Your_ terminology was misleading -- not
>>the 'shellcode' thing either!
>>
>>As for your VIDEO...  I did, this past weekend, view the one called:
>>openvms_local_install_exploit.avi.  
>>
>>1. You telnet into a VMS system.
>>   (this command sting alone is confusing)
>>2. delete PRIVS.TXT
>>3. run FILE.EXE
>>4. type PRIVS.TXT
>>   (privs output)
>>5. delete PRIVS.TXT
>>6. then you run LOADCODE leaving a prompt SHELLCODE>>
>>7. from this point you execute INSTALL... etc., etc., etc.
>>
>>To me, it looks like you wrote your own CLI which is being used in
>>the spawned subprocess.  Again, this obfuscates the reality.
>>
>>
>>>There is a bug for you to analyze.
>>
>>One the missing bits were properly explained, I was able to produce the
>>stack dump.
>>
>>I've written my OWN 'shellcode' now.  I load about 150 bytes of code to
>>P1 via a supported and documented user invokable mechanism!  This code
>>sets the AUTHPRIVs in the PHD and it returns cleanly via a SYS$EXIT with
>>SS$_NORMAL.  All of this executed in a normal DECwindows terminal.
>>
>>NOW, had you, perhaps:
>>
>>1. not changed your prompt
>>2. executed INSTALL from DCL
>>3. not returned the BADPARAM stack
>>4. explained, after the long string of AAAs, about the unseen I/O
>>
>>there would have been more and immediate credence placed in your claim.
>>
>>My question still is *WHY* FILE.EXE when SHOW PROCESS/PRIVILEGES would
>>have sufficed???  Your claim was something about output capturing.  I
>>fail to see why you can capture normal terminal I/O from a TYPE command
>>but not from SHOW PROCESS/PRIVILEGES.  This is the type of thing that's
>>caused much of the confusion, doubt and distrust here.  I have no issue
>>invoking my SHOW PROCESS/PRIVILEGES before and after loading my code to
>>P1.  I don't need to SPAWN a sub-process; albeit, for testing, I did to
>>allow quick cleanup of P1 space with a logout.
>>
>>And, for the record, I did not proclaim this to be a hoax.  However, in
>>light of your, and others, instuctions which were muddled, incomplete,
>>and riddled with misleading jargon, I would expect that the good folks
>>of comp.os.vms would be dubious.
>>
>>FWIW, I have been in contact with a number of people working independ-
>>ently on patches to thwart this attack.  Interim fixes until a patch or
>>fix is released by HP.
>>
>>--
>>VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM
>>
>>... pejorative statements of opinion are entitled to constitutional protection
>>no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
>>
>>Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
>>of usenet _must_ include its contents in its entirety including this copyright
>>notice, disclaimer and quotations.
> 
> 
> Well congratulations, now you pissed me off too and not just cmn..
> 
> WE said nothing about DCL.. Our terminology misleading? Funny..
> because it is a security issue, it was presented at a security
> conference, everyone there seemed to get it, and other people in this
> group got it too... If you don't understand what shellcode means,
> don't google it, or ask and then make the wrong assumptions that is
> hardly our fucking fault now is it?

This is complete bullshit.  People here asked *repeatedly* for you to define
your terms, including the term "shellcode" and you just blew them off.

This is like a bad tourist using an unfamiliar or misprounced word and
just shouting it louder when the person they are trying to communicate
with says "What?"

> 
> 
> OH AND CONDESCENDING????? GIVE ME A FUCKING BREAK! Remember the "1337
> haxOrz" Comment? What do you call that? Yeah we may not be old enough
> to remember the dinosaurs or having written code on punch cards...
> Well guess what, we still found and exploited multiple vulnerabilities
> in VMS.. even if we are not in the right little click of superior
> beings such as yourself..
> 
> Then you say discussing how to "weaponize" this exploit is not a good
> idea for public discussion.... We seem to recall demands that we
> release our exploit.... Double standards??? Oh and talking about your
> shellcode is ok? oh wait... it can't be that you still are trying to
> prove that you are superior to us for using a different method, can
> it?
> 
> Or as another poster so elegantly put it:-
> 
> "It's amazing how many people can *now* get the egg to stand on its
> end once they've been shown how :-( Oh, but your egg stands so much
> prouder."
> 
> 



-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
0
john5 (550)
8/18/2008 11:49:27 PM
On Mon, 18 Aug 2008 15:25:48 -0700, Michael Kraemer <M.Kraemer@gsi.de>  
wrote:

> Tom Linden schrieb:
>
>> I have always kept them in production code, I try to write failsafe  
>> code,
>> don't always succeed, but that is the goal.   Don't use descriptors,  
>> pass
>> by value if you are concerned about refrence  (By value in PL/I means  
>> that
>> a copy of the object is made in local store and a pointer to that is   
>> passed)
>
> Of course one *can* do all that,
> but it depends on the good will of the programmer
> (just as avoiding buffer overflows in other languages).
> It is not inherent to the language.
>
Well, in a way it is the language.  Of course, you can write safe code in
most langugaes, but soem make it easier to not do so. And since most people
are lazy, particularly since it more arduous in languages like C.





-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/19/2008 12:45:09 AM
On Mon, 18 Aug 2008 15:42:21 -0700, <bugs@signedness.org> wrote:

> On Aug 18, 7:59�pm, "Tom Linden" <t...@kednos.company> wrote:
>> On Mon, 18 Aug 2008 09:20:19 -0700, <b...@signedness.org> wrote:
>> > On Aug 18, 4:23�pm, "Tom Linden" <t...@kednos.company> wrote:
>> >> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden <t...@kednos.company>  
>> �
>> >> wrote:
>> >> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert �
>> >> > <rgilber...@comcast.net> wrote:
>>
>> >> >> b...@signedness.org wrote:
>> >> >>> On Aug 18, 12:09 pm, "Richard Maher"  
>> <maher...@hotspamnotmail.com>
>> >> >>> wrote:
>> >> >>>> Hi Heine,
>>
>> >> >>>> Well done!
>>
>> >> >>>> Regards Richard Maher
>>
>> >> >>>> PS. Not that it is important, but what I am sceptical about is  
>> how �
>> >> �
>> >> >>>> "bugs"
>> >> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can  
>> someone �
>> >> �
>> >> >>>> post the
>> >> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege �
>> >> >>>> vulnerability
>> >> >>>> that occurs everyday in Windows/*nix yet no-one has found on  
>> VMS �
>> >> >>>> before,
>> >> >>>> without the help of a few days "generic" hacking, or perhaps  
>> the �
>> >> help �
>> >> >>>> of a
>> >> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, �
>> >> wave a
>> >> >>>> dead-chicken over your head and howl at the moon - standard  
>> stuff �
>> >> for
>> >> >>>> hackers?)
>>
>> >> >>> �No disgruntled deap-throat, no dead chickens or magic wands...  
>> The
>> >> >>> simple truth is very few people have bothered looking at VMS  
>> because
>> >> >>> it is "secure". If nobody is looking for bugs then no bugs are �
>> >> found.
>> >> >>> How many times have we heard "many eyes makes all bugs shallow"?  
>> �
>> >> Well
>> >> >>> still we see really dumb bugs popping up in some of the most  
>> popular
>> >> >>> open source applications so it is really that surprising that  
>> simple
>> >> >>> bugs are found in an operating system that I would assume very  
>> few
>> >> >>> have looked for bugs in since the 80s? (that being said, still a  
>> �
>> >> nice
>> >> >>> find by cmn :))
>> >> >>> �The finger client bugs are good examples, more or less anyone  
>> would
>> >> >>> have found them if they bothered looking for security bugs. The
>> >> >>> seriousness of format string vulnerabilities has been widely  
>> known �
>> >> for
>> >> >>> almost 10 years and still there it is (of course it was probably  
>> +15
>> >> >>> years since anybody had a serious go at owning VMS).. Speaking  
>> of 20
>> >> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone �
>> >> remember
>> >> >>> Morris worm? Almost exactly 20 year old bug...
>>
>> >> >> Hell, yes! �There may be some newbies around who haven't heard of  
>> it �
>> >> �
>> >> >> but I was there while it was happening. �Fortunately, I was �
>> >> responsible �
>> >> >> only for some VMS systems which were not affected. �Most of the  
>> Unix �
>> >> �
>> >> >> systems in the world were affected. �For those newbies who missed  
>> �
>> >> it, �
>> >> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg",  
>> that �
>> >> >> touches the subject briefly. �I'd say it's a "must read" for  
>> anyone �
>> >> >> interested in system security. �It's the only first person  
>> account �
>> >> that �
>> >> >> I know of but there may be others.
>>
>> >> >> VMS System Managers are probably aware of a list of forbidden �
>> >> passwords �
>> >> >> maintained by the system. �500 or so of the entries are Robert �
>> >> Morris' �
>> >> >> list of commonly used passwords! �His worm used them to attempt  
>> to �
>> >> log �
>> >> >> on to his target systems. �He also abused a buffer overflow �
>> >> >> vulnerability in the finger daemon. �The systems the worm  
>> penetrated �
>> >> �
>> >> >> promptly started trying to subvert other systems. . . . �It was  
>> an �
>> >> >> interesting two or three days for the Unix system administrators.  
>> �
>> >> �VMS
>> >> >> systems were largely unaffected.
>>
>> >> >> Difficult as it may be to believe, hackers are STILL exploiting �
>> >> buffer �
>> >> >> overflows. �There is still a lot of code around that will  
>> cheerfully �
>> >> �
>> >> >> attempt to put ten pounds of shit in a five pound bag!
>>
>> >> > Just curious, have you looked at z/os?
>>
>> >> That was meant to be asked of Bugs, got out of sync.
>>
>> >> --
>> >> PL/I for OpenVMSwww.kednos.com
>>
>> > No, nobody asked us to look at it yet. Buying our own system to find
>> > bugs just for the fun of doing it would probably be a bit too
>> > expensive. It would be fun to try, so if someone got a spare machine
>> > let us know....
>>
>> You could run the Hercules emulator, I bet you might even get IBM to  
>> loan
>> you a copy of z/os. �The reason I asked was to compare with VMS since  
>> the
>> two are often compared in terms of security, the difference is in the
>> implementation in which IBM uses a string safe language, with  
>> stringrange
>> checking as an inherenty part of the language, PLS.
>>
>> --
>> PL/I for OpenVMSwww.kednos.com
>
> Any idea who you would ask at IBM for that?

Had you asked me that 20 years ago I could have given you an answer
>
> I would not be surprised if this language I never heard of had its own
> set of problems with strings though.. Other "safe" languages, maybe
> most notably python and php have had some really bad bugs in their
> interpretors dealing with this if I remember correctly.

I am not claiming tha code written in PL/I is safe, just that it is far  
easier
to do so.  Strings are well treated in the language and null is a perfectly
valid lexeme with no special significance, strings are either fixed length  
or
variable with a 2-byte length prefix, checking for a variety conditions is
wealthy.  The reference manual is online at the below site, and you can get
a hobbyist license for no charge.






-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/19/2008 1:00:45 AM
On Mon, 18 Aug 2008 16:49:27 -0700, John Santos <john@egh.com> wrote:

> This is like a bad tourist using an unfamiliar or misprounced word and
> just shouting it louder when the person they are trying to communicate
> with says "What?"
>

Oh, you mean like the bellman in Faulty Towers?


-- 
PL/I for OpenVMS
www.kednos.com
0
tom298 (792)
8/19/2008 1:03:18 AM
Tom Linden schrieb:

> Well, in a way it is the language.  Of course, you can write safe code in
> most langugaes, but soem make it easier to not do so. And since most people
> are lazy, particularly since it more arduous in languages like C.

If safety features are disabled by default (as it was in PL/I
as I know it) they are of limited value. PL/I has some merits
of its own, but increased safety is not among them, IMHO.
Looking back to my old PL/I days I had as many crashes
back then as later on with C programs.
And we haven't discussed yet the mess you can cause
in both languages with trashed pointers.

0
M.Kraemer (2048)
8/19/2008 8:30:41 AM
In article 
<2e2b8a4a-c12d-4c73-b4db-9b2a7036efc6@f36g2000hsa.googlegroups.com>,
 bugs@signedness.org wrote:

> On Aug 18, 7:59�pm, "Tom Linden" <t...@kednos.company> wrote:

> >
> > You could run the Hercules emulator, I bet you might even get IBM to loan
> > you a copy of z/os. �The reason I asked was to compare with VMS since the
> > two are often compared in terms of security, the difference is in the
> > implementation in which IBM uses a string safe language, with stringrange
> > checking as an inherenty part of the language, PLS.
> >
> 
> Any idea who you would ask at IBM for that?
> 

I don't know how to get the IBM software, but the best place to start 
will be the Hercules emulator web site. The folks there will surely know.

http://www.hercules-390.org/

> I would not be surprised if this language I never heard of had its own
> set of problems with strings though.. Other "safe" languages, maybe
> most notably python and php have had some really bad bugs in their
> interpretors dealing with this if I remember correctly.

Why not take a look?

-- 
Paul Sture
0
8/19/2008 8:36:06 AM
In article <g8cp5d$af9$02$1@news.t-online.com>,
 Michael Kraemer <M.Kraemer@gsi.de> wrote:

> Tom Linden schrieb:
> 
> > In your code you would include following which is inherited by all  
> > contained
> > scopes to which you would jump (pushing a new stack frame) upon the  
> > condition
> > being signaled.
> > ...
> > ON SUBSCRIPTRANGE BEGIN;
> >    <recovery code>
> >    END;
> 
> > 
> > etc.
> > descriptors, or dope vectors are used by the compiler, the programmer  
> > doesn't
> > have to explicitly use them, making coding a bit more streamlined.  
> 
> My memory may be a bit rusty, but AFAIR the *RANGE conditions
> are usually disabled in production code.
> Moreover, descriptors can be trashed as well since they are passed
> by reference, as are all parameters in PL/I.

That reminds me of my experience with VAX COBOL. In order to diagnose 
problems at remote sites (in the days before we had access to this 
internet thingy), I compiled production code with the COBOL equivalent 
/check=bounds. The resulting traceback in the event of an error gave 
enough information to go straight to the offending line of code.

The application in question was mainly I/O bound, so the overhead was 
negligible.

-- 
Paul Sture
0
8/19/2008 8:45:21 AM
In article <paul.sture.nospam-247E7B.10452119082008@mac.sture.ch>, "P. Sture" <paul.sture.nospam@hispeed.ch> writes:
>In article <g8cp5d$af9$02$1@news.t-online.com>,
> Michael Kraemer <M.Kraemer@gsi.de> wrote:
>
>> Tom Linden schrieb:
>> 
>> > In your code you would include following which is inherited by all  
>> > contained
>> > scopes to which you would jump (pushing a new stack frame) upon the  
>> > condition
>> > being signaled.
>> > ...
>> > ON SUBSCRIPTRANGE BEGIN;
>> >    <recovery code>
>> >    END;
>> 
>> > 
>> > etc.
>> > descriptors, or dope vectors are used by the compiler, the programmer  
>> > doesn't
>> > have to explicitly use them, making coding a bit more streamlined.  
>> 
>> My memory may be a bit rusty, but AFAIR the *RANGE conditions
>> are usually disabled in production code.
>> Moreover, descriptors can be trashed as well since they are passed
>> by reference, as are all parameters in PL/I.
>
>That reminds me of my experience with VAX COBOL. In order to diagnose 
>problems at remote sites (in the days before we had access to this 
>internet thingy), I compiled production code with the COBOL equivalent 
>/check=bounds. The resulting traceback in the event of an error gave 
>enough information to go straight to the offending line of code.

I'm not familiar with everything that may do to implement checks in COBOL
but the same in Fortran used the INDEX instruction on array bounds.  This
didn't cause significant overhead unless an array was accessed heavily in
the application.  In most of the Fortran apps I worked on, array accesses
were excessive!  Removing the /BOUNDS checking resulted in a SIGNIFICANT
performance increase.



>The application in question was mainly I/O bound, so the overhead was 
>negligible.

The typical YMMV disclaimer applies.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/19/2008 11:47:00 AM
P. Sture wrote:
> In article <g8cp5d$af9$02$1@news.t-online.com>,
>  Michael Kraemer <M.Kraemer@gsi.de> wrote:
> 
>> Tom Linden schrieb:
>>
>>> In your code you would include following which is inherited by all  
>>> contained
>>> scopes to which you would jump (pushing a new stack frame) upon the  
>>> condition
>>> being signaled.
>>> ...
>>> ON SUBSCRIPTRANGE BEGIN;
>>>    <recovery code>
>>>    END;
>>> etc.
>>> descriptors, or dope vectors are used by the compiler, the programmer  
>>> doesn't
>>> have to explicitly use them, making coding a bit more streamlined.  
>> My memory may be a bit rusty, but AFAIR the *RANGE conditions
>> are usually disabled in production code.
>> Moreover, descriptors can be trashed as well since they are passed
>> by reference, as are all parameters in PL/I.
> 
> That reminds me of my experience with VAX COBOL. In order to diagnose 
> problems at remote sites (in the days before we had access to this 
> internet thingy), I compiled production code with the COBOL equivalent 
> /check=bounds. The resulting traceback in the event of an error gave 
> enough information to go straight to the offending line of code.

ISTR that there was a /CHECK=ALL for the FORTRAN compiler, and perhaps 
others as well.  Your code runs slower with /CHECK=ALL but it will find 
some of the instances of your being too clever for your own good.  It 
won't find uninitialized variables but it catches most of the other 
common coding errors.
0
rgilbert88 (4439)
8/19/2008 11:49:08 AM
Not that it matters at this point, but I did get the dump on VMS/VAX
7.3 (earlier, I said I had not)... I'm sure I've missed the post where
someone has made it known how far back this "bug" goes...

MAIL>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@xxxxxxxxxxx
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual
address=62626262, PC=80000010, PSL=03C00004

  Improperly handled condition, image exit forced.

        Signal arguments              Stack contents

        Number = 00000005                83403663
        Name   = 0000000C                00000002
                 00000001                7FEC66B8
                 62626262                7FEC66A0
                 80000010                00000004
                 03C00004                7FEC69E0
                                         00000000
                                         415B1B41
                                         00000000
                                         05000001

        Register dump

        R0 = 03C00000  R1 = 62626262  R2 = 00015000  R3 = 00000020
        R4 = 00000001  R5 = 00000001  R6 = 0003C8F0  R7 = 00000001
        R8 = 7FFECA00  R9 = 7FFECC01  R10= 00000001  R11= 00000001
        AP = 7FEC6654  FP = 7FEC6614  SP = 7FEC6690  PC = 80000010
        PSL= 03C00004
0
jferraro (20)
8/19/2008 2:26:15 PM
In article <00A7E558.3A52B403@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
> 
> I'm not familiar with everything that may do to implement checks in COBOL
> but the same in Fortran used the INDEX instruction on array bounds.

   Was that only when you compiled with /check=bounds, or was it just
   a later version of the compiler?  I recall when Fortran didn't
   generate the INDEX instruction because it wasn't in the FP780.

0
koehler2 (8314)
8/19/2008 3:01:45 PM
In article <slrngajsd3.8sv.BRAD@rabbit.turquoisewitch.com>,
 BRAD@rabbit.turquoisewitch.com (Brad Hamilton) wrote:

> OK, the presentation slides are at:
> 
> <http://deathrow.vistech.net/defcon16>
> 
> Follow up there or here...

If anyone is confused by page 55 of the PDF there, I believe that the 
line

  $ set terminal /nointerrupt

is misleading and should read 

  $ set terminal /nointeractive

Doing a show terminal before and after this command shows that it is 
equivalent to

  $ set terminal /passall

-- 
Paul Sture
0
8/19/2008 3:07:11 PM
On Aug 19, 11:07=A0am, "P. Sture" <paul.sture.nos...@hispeed.ch> wrote:
> In article <slrngajsd3.8sv.B...@rabbit.turquoisewitch.com>,
> =A0B...@rabbit.turquoisewitch.com (Brad Hamilton) wrote:
>
> > OK, the presentation slides are at:
>
> > <http://deathrow.vistech.net/defcon16>
>
> > Follow up there or here...
>
> If anyone is confused by page 55 of the PDF there, I believe that the
> line
>
> =A0 $ set terminal /nointerrupt
>
> is misleading and should read
>
> =A0 $ set terminal /nointeractive
>
> Doing a show terminal before and after this command shows that it is
> equivalent to
>
> =A0 $ set terminal /passall

That would make sense, since setting the terminal to "passall" would
mean that the escape sequences aren't being interpreted.

Also, it's obvious from reading the slides that the presenter, "bugs",
thought he found 3 different vulnerabilities in 3 different programs
(telnet, install, telnet), when he had really found just one.

Ken
0
kenrbnsn4 (250)
8/19/2008 3:56:44 PM
In article <JTluh5OBXuXT@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <00A7E558.3A52B403@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>> 
>> I'm not familiar with everything that may do to implement checks in COBOL
>> but the same in Fortran used the INDEX instruction on array bounds.
>
>   Was that only when you compiled with /check=bounds, or was it just
>   a later version of the compiler?  I recall when Fortran didn't
>   generate the INDEX instruction because it wasn't in the FP780.

Why would INDEX be _in_ the FP780?  It's not a FP instruction.  It basically
performs lower <= x <= upper.
  

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/19/2008 4:29:28 PM
<VAXman- @SendSpamHere.ORG> wrote in message news:00A7E57F.B0031080@SendSpamHere.ORG...

> Why would INDEX be _in_ the FP780?  It's not a FP instruction.  It basically
> performs lower <= x <= upper.

Early VAX FPUs used to offload some wierd things; I don't think the circuit
designers worried overmuch about architectural purity. 


0
R.Brodie (551)
8/19/2008 5:03:55 PM
On Aug 19, 4:56=A0pm, Ken Robinson <kenrb...@gmail.com> wrote:
> On Aug 19, 11:07=A0am, "P. Sture" <paul.sture.nos...@hispeed.ch> wrote:
>
>
>
> > In article <slrngajsd3.8sv.B...@rabbit.turquoisewitch.com>,
> > =A0B...@rabbit.turquoisewitch.com (Brad Hamilton) wrote:
>
> > > OK, the presentation slides are at:
>
> > > <http://deathrow.vistech.net/defcon16>
>
> > > Follow up there or here...
>
> > If anyone is confused by page 55 of the PDF there, I believe that the
> > line
>
> > =A0 $ set terminal /nointerrupt
>
> > is misleading and should read
>
> > =A0 $ set terminal /nointeractive
>
> > Doing a show terminal before and after this command shows that it is
> > equivalent to
>
> > =A0 $ set terminal /passall
>
> That would make sense, since setting the terminal to "passall" would
> mean that the escape sequences aren't being interpreted.
>
> Also, it's obvious from reading the slides that the presenter, "bugs",
> thought he found 3 different vulnerabilities in 3 different programs
> (telnet, install, telnet), when he had really found just one.
>
> Ken

Sigh, Obvious huh? Are you refering to the slide with multiple targets
(tcpip, install, telnet)?  It says multiple targets, as in the
vulnerability can be triggered / exploited in multiple targets (and
there are more than those 3 too btw). It doesn't say 3 different
vulnerabilities. The slides does deal with 3 different vulnerabilities
though, two in finger and the overflow.

0
bugs6 (57)
8/19/2008 5:25:00 PM
In article <g8euds$mmt$1@south.jnrs.ja.net>, "Richard Brodie" <R.Brodie@rl.ac.uk> writes:
>
><VAXman- @SendSpamHere.ORG> wrote in message news:00A7E57F.B0031080@SendSpamHere.ORG...
>
>> Why would INDEX be _in_ the FP780?  It's not a FP instruction.  It basically
>> performs lower <= x <= upper.
>
>Early VAX FPUs used to offload some wierd things; I don't think the circuit
>designers worried overmuch about architectural purity. 

The Fortran work I did was for the Navy on 11/780s.  The INDEX instruction
was what Fortran used to check bounds.  


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/19/2008 8:08:04 PM
FrankS wrote:
> On Aug 18, 5:35 pm, gerr...@no.spam.mail.com wrote:
>> VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.
> 
> Interesting.  That's something like 16 years that the bug has been
> around and never been spotted?
> 
> I guess that shows that there aren't many people working on VMS that
> spend their days keying in 511+ characters looking for buffer
> overflows.
> 
> :-)


Automation would be handy.
0
eccm (54)
8/20/2008 3:15:07 AM
In article <5%Lqk.34991$co7.28070@nlpi066.nbdc.sbc.com>,
	patrick jankowiak <eccm@swbell.net> writes:
> FrankS wrote:
>> On Aug 18, 5:35 pm, gerr...@no.spam.mail.com wrote:
>>> VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.
>> 
>> Interesting.  That's something like 16 years that the bug has been
>> around and never been spotted?
>> 
>> I guess that shows that there aren't many people working on VMS that
>> spend their days keying in 511+ characters looking for buffer
>> overflows.
>> 
>> :-)
> 
> 
> Automation would be handy.

If any of the hacker community really cared about VMS there would already
be a script the script-kiddies could run.  But.........

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
8/20/2008 11:43:09 AM
In article <00A7E57F.B0031080@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
> In article <JTluh5OBXuXT@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>In article <00A7E558.3A52B403@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>>> 
>>> I'm not familiar with everything that may do to implement checks in COBOL
>>> but the same in Fortran used the INDEX instruction on array bounds.
>>
>>   Was that only when you compiled with /check=bounds, or was it just
>>   a later version of the compiler?  I recall when Fortran didn't
>>   generate the INDEX instruction because it wasn't in the FP780.
> 
> Why would INDEX be _in_ the FP780?  It's not a FP instruction.  It basically
> performs lower <= x <= upper.

   The FP780 included FP, integer, and addressing mode calculations.
   So using addressing modes to step through an array was faster than
   using INDEX.

0
koehler2 (8314)
8/20/2008 12:43:55 PM
In article <6h2eadFia6svU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>In article <5%Lqk.34991$co7.28070@nlpi066.nbdc.sbc.com>,
>	patrick jankowiak <eccm@swbell.net> writes:
>> FrankS wrote:
>>> On Aug 18, 5:35 pm, gerr...@no.spam.mail.com wrote:
>>>> VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.
>>> 
>>> Interesting.  That's something like 16 years that the bug has been
>>> around and never been spotted?
>>> 
>>> I guess that shows that there aren't many people working on VMS that
>>> spend their days keying in 511+ characters looking for buffer
>>> overflows.
>>> 
>>> :-)
>> 
>> 
>> Automation would be handy.
>
>If any of the hacker community really cared about VMS there would already
>be a script the script-kiddies could run.  But.........

How do you know there isn't?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/20/2008 12:50:52 PM
In article <00A7E62A.50A45B7B@sendspamhere.org>,
	VAXman-  @SendSpamHere.ORG writes:
> In article <6h2eadFia6svU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>In article <5%Lqk.34991$co7.28070@nlpi066.nbdc.sbc.com>,
>>	patrick jankowiak <eccm@swbell.net> writes:
>>> FrankS wrote:
>>>> On Aug 18, 5:35 pm, gerr...@no.spam.mail.com wrote:
>>>>> VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.
>>>> 
>>>> Interesting.  That's something like 16 years that the bug has been
>>>> around and never been spotted?
>>>> 
>>>> I guess that shows that there aren't many people working on VMS that
>>>> spend their days keying in 511+ characters looking for buffer
>>>> overflows.
>>>> 
>>>> :-)
>>> 
>>> 
>>> Automation would be handy.
>>
>>If any of the hacker community really cared about VMS there would already
>>be a script the script-kiddies could run.  But.........
> 
> How do you know there isn't?

Because if there were, these would have been uncovered long ago and
people here wouldn't have been able to make their claim that VMS was
never hacked.  Primos is just as secure as VMS and for the same reason. :-)
The only remaining question now is which has a bigger installed base.  :-)

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
billg999 (2588)
8/20/2008 1:03:04 PM
In article <n3qD5em$JLqf@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <00A7E57F.B0031080@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>> In article <JTluh5OBXuXT@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>>In article <00A7E558.3A52B403@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>>>> 
>>>> I'm not familiar with everything that may do to implement checks in COBOL
>>>> but the same in Fortran used the INDEX instruction on array bounds.
>>>
>>>   Was that only when you compiled with /check=bounds, or was it just
>>>   a later version of the compiler?  I recall when Fortran didn't
>>>   generate the INDEX instruction because it wasn't in the FP780.
>> 
>> Why would INDEX be _in_ the FP780?  It's not a FP instruction.  It basically
>> performs lower <= x <= upper.
>
>   The FP780 included FP, integer, and addressing mode calculations.
>   So using addressing modes to step through an array was faster than
>   using INDEX.

INDEX only checked the array index against up and lower bounds.  It didn't
do the array access.   For example, the base address of an array is moved
to R1.  Assume an integer array, its contents can be accessed with (R1)[Rx]
where Rx is a register with the array element index number.  If an integer
array, you've access it as, for example, MOVL (R1)[R2],R3 and R2 is multi-
plied by 4 because it's an integer array.  Enabling the bounds checking in
Fortran woudl cause R2 to be bounds verify using an INDEX instruction prior
to the MOVL.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.
0
VAXman
8/20/2008 1:40:04 PM
In article <6h2j08Fi0it1U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>In article <00A7E62A.50A45B7B@sendspamhere.org>,
>	VAXman-  @SendSpamHere.ORG writes:
>> In article <6h2eadFia6svU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>>>In article <5%Lqk.34991$co7.28070@nlpi066.nbdc.sbc.com>,
>>>	patrick jankowiak <eccm@swbell.net> writes:
>>>> FrankS wrote:
>>>>> On Aug 18, 5:35 pm, gerr...@no.spam.mail.com wrote:
>>>>>> VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.
>>>>> 
>>>>> Interesting.  That's something like 16 years that the bug has been
>>>>> around and never been spotted?
>>>>> 
>>>>> I guess that shows that there a