DEFCON 16 and Hacking OpenVMS - VMS

This is a discussion on DEFCON 16 and Hacking OpenVMS - VMS ; > 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 ...

+ Reply to Thread
Page 2 of 35 FirstFirst 1 2 3 4 12 ... LastLast
Results 21 to 40 of 691

Thread: DEFCON 16 and Hacking OpenVMS

  1. Re: DEFCON 16 and Hacking OpenVMS

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


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

    Sampsa


  2. Re: DEFCON 16 and Hacking OpenVMS

    sampsal@gmail.com wrote:
    >> 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.


    Sorry - I can't reproduce this the way it is described here on my V8.3
    Alpha. After entering the characters, and pressing the up arrow three
    times, I am returned to the "$", without a dump. I have reproduced this
    technique on two different Alphas, both running V8.3, and have not
    reproduced the reported behavior.

    It will be interesting to see the slides.


  3. Re: DEFCON 16 and Hacking OpenVMS

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

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

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



  5. Re: DEFCON 16 and Hacking OpenVMS

    On Wed, Aug 13, 2008 at 7:56 AM, 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'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
    >
    >
    >

    There are people in Engineering with whom I can check...

    WWWebb


  6. Re: DEFCON 16 and Hacking OpenVMS

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

    >>
    >>I know you didn't make the claim but you should first test it out before
    >>brandishing 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]

  7. Re: DEFCON 16 and Hacking OpenVMS

    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

  8. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 13, 7:02 pm, jferraro wrote:
    > 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 - shorte


    Also tried with elevated and from a com file:

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

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



    ~~~

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

    Joe Ferraro


  9. Re: DEFCON 16 and Hacking OpenVMS

    On Wed, 13 Aug 2008 16:02:36 -0700, jferraro wrote:

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


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

    --
    PL/I for OpenVMS
    www.kednos.com

  10. Re: DEFCON 16 and Hacking OpenVMS

    In article <995d1554-09f0-489d-904b-150a9ed48f83@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.

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

  11. Re: DEFCON 16 and Hacking OpenVMS

    I tried on Alpha VMS 8.3 on the system account no less. From a DECterm
    window.

    511 characters, no spaces. Up arrow 3 times, nothing special happened.

  12. Re: DEFCON 16 and Hacking OpenVMS

    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.

    Tim.

  13. Re: DEFCON 16 and Hacking OpenVMS

    On Wed, Aug 13, 2008 at 9:42 PM, Tim E. Sneddon wrote:

    > VAXman- @SendSpamHere.ORG wrote:
    >
    >> In article <
    >> 9781c047-761a-4923-9aab-8c1a32ff7c67...oglegroups.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.
    >
    > Tim.



    Hi, Tim-

    Still got the Multia?

    Best regards,

    WWWebb


  14. Re: DEFCON 16 and Hacking OpenVMS

    In article <00A7E113.29A29520@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
    >In article <995d1554-09f0-489d-904b-150a9ed48f83@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.


  15. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 13, 9:22 pm, VAXman- @SendSpamHere.ORG wrote:
    > 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.
    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >
    > ... pejorative statements of opinion are entitled to constitutional protection
    > no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >
    > Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    > of usenet _must_ include its contents in its entirety including this copyright
    > notice, disclaimer and quotations.


    Sorry... that was the point... its *not* a core-dump or
    exploitation... only posting to remove any doubts from those who may
    impose the theory on "older" openVMS instances...

  16. Re: DEFCON 16 and Hacking OpenVMS

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

    >>
    >> I know you didn't make the claim but you should first test it out before
    >> brandishing 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.


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


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

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

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  17. Re: DEFCON 16 and Hacking OpenVMS

    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]

  18. Re: DEFCON 16 and Hacking OpenVMS

    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.

  19. Re: DEFCON 16 and Hacking OpenVMS

    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

  20. Re: DEFCON 16 and Hacking OpenVMS

    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


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