DEFCON 16 and Hacking OpenVMS - VMS

This is a discussion on DEFCON 16 and Hacking OpenVMS - VMS ; sampsal@gmail.com wrote: > [...snip...] > I think what they do (more or less) is to inject some shellcode into a > logical before running the exploit, then insert some other code after > the overflow that executes the code in ...

+ Reply to Thread
Page 5 of 35 FirstFirst ... 3 4 5 6 7 15 ... LastLast
Results 81 to 100 of 691

Thread: DEFCON 16 and Hacking OpenVMS

  1. Re: DEFCON 16 and Hacking OpenVMS

    sampsal@gmail.com wrote:

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


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

    I'm a skeptic and proud of it, but I'm beginning to suspect that
    this is all a hoax.

  2. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 15, 3:35*pm, "R.A.Omond" wrote:
    > samp...@gmail.com wrote:
    > Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
    > but I actually didn't understand what that is meant to mean.
    >
    > I'm a skeptic and proud of it, but I'm beginning to suspect that
    > this is all a hoax.


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

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

    Sampsa


  3. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 15, 3:35 pm, "R.A.Omond" wrote:
    > samp...@gmail.com wrote:
    > > [...snip...]
    > > I think what they do (more or less) is to inject some shellcode into a
    > > logical before running the exploit, then insert some other code after
    > > the overflow that executes the code in the logical. Signedness guys
    > > care to comment, I didn't see the demo, just have the notes second
    > > hand?

    >
    > Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
    > but I actually didn't understand what that is meant to mean.
    >
    > I'm a skeptic and proud of it, but I'm beginning to suspect that
    > this is all a hoax.


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

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

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

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

    I'm reserving judgement on whether I've seen proof.

  4. Re: DEFCON 16 and Hacking OpenVMS

    On Fri, 15 Aug 2008 04:02:24 -0700, Graham Burley
    wrote:

    > In article <48A55B5C.60807@comcast.net>, bradhamilton
    > writes:
    >
    >> OK, now *please*, someone show us how to "properly" format the .plan
    >> (plan.txt) file to produce this result.

    >
    > And which finger (TCP/IP Services, Multinet, ...)
    >

    Previous post indicated multinet
    http://www.securityfocus.com/archive/1/495207


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

  5. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 15, 4:51*pm, "Tom Linden" wrote:
    > Previous post indicated multinethttp://www.securityfocus.com/archive/1/495207
    >
    > --
    > PL/I for OpenVMSwww.kednos.com


    That's a different flaw, I've verified the client bug on a stock
    OpenVMS 8.3 install with TCPIP V5.6-9ECO2.

    Sampsa


  6. Re: DEFCON 16 and Hacking OpenVMS

    In article , sampsal@gmail.com writes:
    >On Aug 15, 3:35=A0pm, "R.A.Omond" wrote:
    >> samp...@gmail.com wrote:
    >> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
    >> but I actually didn't understand what that is meant to mean.
    >>
    >> I'm a skeptic and proud of it, but I'm beginning to suspect that
    >> this is all a hoax.

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


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


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

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

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

  7. Re: DEFCON 16 and Hacking OpenVMS

    > In article , "Tom Linden" writes:

    >> And which finger (TCP/IP Services, Multinet, ...)
    >>

    >Previous post indicated multinet
    >http://www.securityfocus.com/archive/1/495207


    That finger bug's been fixed, Process released the FINGER-010_A052
    patch for Multinet on 8th August. This appears to be something else.


  8. Re: DEFCON 16 and Hacking OpenVMS

    johnwallace4@yahoo.co.uk wrote:
    > On Aug 15, 3:35 pm, "R.A.Omond" wrote:


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


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

    Jan-Erik.

  9. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 15, 5:56 pm, VAXman- @SendSpamHere.ORG wrote:
    > In article , samp...@gmail.com writes:
    >
    >
    >
    > >On Aug 15, 3:35=A0pm, "R.A.Omond" wrote:
    > >> samp...@gmail.com wrote:
    > >> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
    > >> but I actually didn't understand what that is meant to mean.

    >
    > >> I'm a skeptic and proud of it, but I'm beginning to suspect that
    > >> this is all a hoax.

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

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

    >
    > I've mucked around quite a bit in DCL and I don't see how you get some
    > command or command procedure (shellcode) stored in a logical to be ex-
    > ecuted by DCL when you ACCVIO an image.
    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >
    > ... pejorative statements of opinion are entitled to constitutional protection
    > no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >
    > Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    > of usenet _must_ include its contents in its entirety including this copyright
    > notice, disclaimer and quotations.


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

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

  10. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 15, 7:42 pm, Jan-Erik Söderholm
    wrote:
    > johnwalla...@yahoo.co.uk wrote:
    > > On Aug 15, 3:35 pm, "R.A.Omond" wrote:
    > > If all this is done correctly you don't see an ACCVIO, you just end up
    > > with unintended code being silently executed, potentially in the
    > > context of an exploitable program. I haven't watched the videos but
    > > the ACCVIOs here aren't what I'd expect to see as part of a successful
    > > exploit;

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


    Yeah right .... You should probably get a book about exploit
    development as well.

  11. Re: DEFCON 16 and Hacking OpenVMS

    bugs@signedness.org wrote:
    > On Aug 15, 7:42 pm, Jan-Erik Söderholm
    > wrote:
    >> johnwalla...@yahoo.co.uk wrote:
    >>> On Aug 15, 3:35 pm, "R.A.Omond" wrote:
    >>> If all this is done correctly you don't see an ACCVIO, you just end up
    >>> with unintended code being silently executed, potentially in the
    >>> context of an exploitable program. I haven't watched the videos but
    >>> the ACCVIOs here aren't what I'd expect to see as part of a successful
    >>> exploit;

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

    >
    > Yeah right .... You should probably get a book about exploit
    > development as well.


    OK, The process ACCVIO's *after* your code has run.
    If so, there might be a "problem"...

  12. Re: DEFCON 16 and Hacking OpenVMS

    In article <2970caa7-7806-4278-996e-79af773dc750@r66g2000hsg.googlegroups.com>, bugs@signedness.org writes:
    > On Aug 15, 5:56 pm, VAXman- @SendSpamHere.ORG wrote:
    >>
    >> I've mucked around quite a bit in DCL and I don't see how you get some
    >> command or command procedure (shellcode) stored in a logical to be ex-
    >> ecuted by DCL when you ACCVIO an image.
    >>

    >
    > You really don't get it. At all.


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

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

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980's technology to a 21st century world

  13. Re: DEFCON 16 and Hacking OpenVMS

    In article <2970caa7-7806-4278-996e-79af773dc750@r66g2000hsg.googlegroups.com>, bugs@signedness.org writes:
    >On Aug 15, 5:56 pm, VAXman- @SendSpamHere.ORG wrote:
    >> In article , samp...@gmail.com writes:
    >>
    >>
    >>
    >> >On Aug 15, 3:35=A0pm, "R.A.Omond" wrote:
    >> >> samp...@gmail.com wrote:
    >> >> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
    >> >> but I actually didn't understand what that is meant to mean.

    >>
    >> >> I'm a skeptic and proud of it, but I'm beginning to suspect that
    >> >> this is all a hoax.

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

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

    >>
    >> I've mucked around quite a bit in DCL and I don't see how you get some
    >> command or command procedure (shellcode) stored in a logical to be ex-
    >> ecuted by DCL when you ACCVIO an image.
    >>
    >> --
    >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >>
    >> ... pejorative statements of opinion are entitled to constitutional protection
    >> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >>
    >> Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    >> of usenet _must_ include its contents in its entirety including this copyright
    >> notice, disclaimer and quotations.

    >
    >You really don't get it. At all.


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



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


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



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


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



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


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

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

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

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

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

  14. Re: DEFCON 16 and Hacking OpenVMS

    bugs@signedness.org wrote:

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


    Does FILE.EXE need to be installed with privileges and/or executed from
    an account with elevated privileges ?

  15. Re: DEFCON 16 and Hacking OpenVMS

    VAXman- @SendSpamHere.ORG wrote:

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


    $HELP SPAWN
    $HELP RUN process

    and to the original poster:

    $HELP SHOW PROCESS /OUTPUT

  16. Re: DEFCON 16 and Hacking OpenVMS

    sampsal@gmail.com wrote:

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



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

    For an application to execute the content of a logical name, it would
    need to first extract those contents into memory, and then declare that
    area of memory to be executable and then branch to it. This doesn't
    happen by mistake/luck.

  17. Re: DEFCON 16 and Hacking OpenVMS

    In article <48a5dcd2$0$1847$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >VAXman- @SendSpamHere.ORG wrote:
    >
    >> OK. I'm most confused. How do you invoke SYS$CREPRC from DCL?

    >
    >$HELP SPAWN
    >$HELP RUN process


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



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


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

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

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

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

  18. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 15, 8:49*pm, JF Mezei wrote:
    > samp...@gmail.com wrote:
    > > 3. It is possible to execute shellcode stored in logicals, however.
    > > 4. Therefore the code injected after the overflow executes some other
    > > code stored in a logical.

    >
    > Since there is no such thing as "shellcode" in VMS, it would greatly
    > help if you use terminology native to VMS so we could understand it.
    >
    > For an application to execute the content of a logical name, it would
    > need to first extract those contents into memory, and then declare that
    > area of memory to be executable and then branch to it. This doesn't
    > happen by mistake/luck.


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

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

    Bugs, can you verify my explanation is correct?

    Sampsa


  19. Re: DEFCON 16 and Hacking OpenVMS

    bugs@signedness.org wrote:

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


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

    Those are fully documented. No exploit there.

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


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



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


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



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


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


    For instance, if Mr VAXman had found this exploit, he would have given
    an explanation using terminology that is native to VMS because we know
    he has a lot of experience with VMS.

  20. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 15, 9:03 pm, JF Mezei wrote:
    > b...@signedness.org wrote:
    > > since the exploit take advantage of an error to take control of the
    > > execution flow.

    >
    > You mean you have discovered error handlers in VMS where you can
    > register a subroutine to execute when errors/access violations happen in
    > an executable program ?
    >
    > Those are fully documented. No exploit there.
    >
    > > Since the PC is controlled in the CLI bug we simply jump to the
    > > address of a logical that contains the
    > > shellcode that we want to run.

    >
    > How do you obtain the address of that logical ? This is pretty critical
    > to knowing if you can jump to it or not.
    >
    > > However, we did not bother
    > > to add a clean exit after the create process shellcode so the process
    > > crashes when FILE.EXE
    > > has been executed.

    >
    > You mean you don't know about the "exit(1);" statement in C ?
    >
    > > Please pick up some book on exploit development and think a little
    > > before doing statements
    > > about things that you obviously don't know anything about.

    >
    > For someone to find such an exploit, one would need a fair amount of VMS
    > experience. And since you use terminology that is completely foreign to
    > VMS, it is hard to understand how you could have enough experience with
    > VMS to find such an exploit.
    >
    > For instance, if Mr VAXman had found this exploit, he would have given
    > an explanation using terminology that is native to VMS because we know
    > he has a lot of experience with VMS.


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

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

    One thing that anyone who's ever done "customer support" work (which
    is a lot of contributors here, I think) should understand is the well-
    known concept of "a simple reproducer", with minimal obfuscation and
    clutter. Language difficulties apart, have we got one of those here
    yet?

+ Reply to Thread
Page 5 of 35 FirstFirst ... 3 4 5 6 7 15 ... LastLast