On Aug 14, 10:18 am, davi...@alpha2.mdx.ac.uk wrote:
> In article , Bob Gezelter 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 writes:
> >> >>On Aug 13, 9:17 am, Mark Daniel 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 bull**** 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 ****, 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
> >> >>
>
> >> >>$ 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

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.

In article , "Tim E. Sneddon" 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.

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.

In article , "Tim E. Sneddon" 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

On Aug 14, 11:05 am, "Tim E. Sneddon" 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

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!

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 writes:
>>>> On Aug 13, 9:17 am, Mark Daniel 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 bull**** 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 ****, 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
>>>>
>>>> $ 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!!

On Aug 14, 2:42*am, "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 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 bull**** 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 bull****. 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 bull**** and
never exploitable? Well if you are talking about our bugs then you may
want to watch these videos:

http://www.signedness.org/misc/openv...ll_exploit.avi
http://www.signedness.org/misc/openv...ip_exploit.avi
http://www.signedness.org/misc/openv...et_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

bugs@signedness.org wrote:
[...]
> Well if you are talking about our bugs then you may
> want to watch these videos:
>
> http://www.signedness.org/misc/openv...ll_exploit.avi
> http://www.signedness.org/misc/openv...ip_exploit.avi
> http://www.signedness.org/misc/openv...et_exploit.avi
>

There is no sound on the videos. I can't reproduce these "exploits"
because I don't have access to FILE.EXE.

> 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.

Like this (on an Alpha)?

brad@coyote:~$ finger brad@xxx.xxx.xxx
[xxx.xxx.xxx]
BRAD brad 20A18427 *DCL* FTA1680ssh/x.x.x.x.

Plan:

mangiD kcirtaP
regnaD kciN
Humphrey Chimpden Earwicker
Anna Livia Plurabelle
%n%n%n%n%n%n%n

Sorry, I'm not impressed, at least not without more detail than has been
provided so far.

In article <488fbb7a-2459-4753-904a-7ecd5193bdc4@2g2000hsn.googlegroups.com>, bugs@signedness.org writes:
>On Aug 14, 2:42=A0am, "Tim E. Sneddon" 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 bull**** 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 bull****. 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 bull**** and
>never exploitable? Well if you are talking about our bugs then you may
>want to watch these videos:
>
>http://www.signedness.org/misc/openv...ll_exploit.avi
>http://www.signedness.org/misc/openv...ip_exploit.avi
>http://www.signedness.org/misc/openv...et_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.

bugs@signedness.org wrote:
> On Aug 14, 2:42 am, "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 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 bull**** 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 bull****. 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 bull**** 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 ****, 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.

On Aug 15, 3:12 am, "Tim E. Sneddon" wrote:
> b...@signedness.org wrote:
> > On Aug 14, 2:42 am, "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 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 bull**** 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 bull****. 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 bull**** 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 ****, 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

bugs@signedness.org wrote:
[...]
>
> 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

Thanks for the additional information. I was curious as to why you ran
FILE.EXE, as opposed to a simple "show proc/priv" before and after your
exploit.

I can see that you have gained privilege after the "exploit", but the
"exploit" itself seems to be another EXE (SHELLCODE?) itself. Why all
the "mystery"? Without the source code, we can't "see" what's going on,
and reproduce it ourselves; we are left to trusting that you are not
playing some kind of bizarre, behind-the-scenes tricks to pretend that
you are elevating privileges. Sorry to be so mistrustful, but that's
just a common attitude here.

I was able to "view" the videos on a linux laptop using "Movie Player".
I tried to view the videos on an XP box, but both Media Player and
Quicktime show dark screens, as reported by Brian. Media player claims
that a codec is corrupt (I assume that this is the vmware codec referred
to above).

As for the finger "exploit", can you be more specific? As I've shown,
seven "%n" in my plan file is not enough to trigger bizarre, unwanted
behavior.

bugs@signedness.org wrote:
> On Aug 15, 3:12 am, "Tim E. Sneddon" wrote:
>> b...@signedness.org wrote:
>>> On Aug 14, 2:42 am, "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 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 bull**** 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 bull****. 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 bull**** 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 ****, 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.

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

On Aug 15, 3:03*am, patrick jankowiak 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 bull****ting 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 bull**** about OpenVMS bugs or maybe it
is possible that VMS is pretty exploitable..

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 bull**** 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 bull****. 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
>> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>>
>> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBB
>>
>> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCC
>>
>> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDDDDDDDDDDDDDDDDDDDDDDDDDD
>>
>> EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEE
>>
>> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFF
>>
>> 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

$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFGGGGGGGGGGGGGGGGGGGG GGGGGGGGGGGGGGGGG

up three times, and down three times, nothing.. but this shows now:
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$


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:



$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
%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

bugs@signedness.org wrote:
> On Aug 15, 3:03 am, patrick jankowiak 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 bull****ting 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 bull**** 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

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.