DEFCON 16 and Hacking OpenVMS - VMS

This is a discussion on DEFCON 16 and Hacking OpenVMS - VMS ; 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 , VAXman- @SendSpamHere.ORG writes: > >> >In article , jferraro writes: > >> ...

+ Reply to Thread
Page 3 of 35 FirstFirst 1 2 3 4 5 13 ... LastLast
Results 41 to 60 of 691

Thread: DEFCON 16 and Hacking OpenVMS

  1. Re: DEFCON 16 and Hacking OpenVMS

    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

  2. Re: DEFCON 16 and Hacking OpenVMS

    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.

  3. Re: DEFCON 16 and Hacking OpenVMS

    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.

  4. Re: DEFCON 16 and Hacking OpenVMS

    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.

  5. Re: DEFCON 16 and Hacking OpenVMS

    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


  6. Re: DEFCON 16 and Hacking OpenVMS

    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

  7. Re: DEFCON 16 and Hacking OpenVMS

    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!

  8. Re: DEFCON 16 and Hacking OpenVMS

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

  9. Re: DEFCON 16 and Hacking OpenVMS

    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




  10. Re: DEFCON 16 and Hacking OpenVMS

    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.

  11. Re: DEFCON 16 and Hacking OpenVMS

    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.

  12. Re: DEFCON 16 and Hacking OpenVMS

    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.

  13. Re: DEFCON 16 and Hacking OpenVMS

    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

  14. Re: DEFCON 16 and Hacking OpenVMS

    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.


  15. Re: DEFCON 16 and Hacking OpenVMS

    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.

  16. Re: DEFCON 16 and Hacking OpenVMS


    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

  17. Re: DEFCON 16 and Hacking OpenVMS

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




  18. Re: DEFCON 16 and Hacking OpenVMS

    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

  19. Re: DEFCON 16 and Hacking OpenVMS

    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

  20. Re: DEFCON 16 and Hacking OpenVMS

    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.

+ Reply to Thread
Page 3 of 35 FirstFirst 1 2 3 4 5 13 ... LastLast