[Info-vax] An old VMS vulnerability, was: Re: Calling standards, was: Re: Byte range locking - was Re: Oracle

[VAXman- at SendSpamHere.ORG]

In article <o1i312$vle$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2016-11-28, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
>> In article <o1htcj$do1$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>>>[1] It's been 8 years so I assume by now VMS Engineering have
>>>released patches to make the address space occupied by the logicals
>>>non-executable so that if another privileged process is compromised
>>>then a logical cannot be used to hold the shellcode.
>>
>> It had NOTHING to do with logicals other than the fact that the DEFCON group
>> didn't know VMS programming.  In fact, having seen their exploit code, I have
>> been skeptical that they even discovered the vulnerability.  I'll leave it at
>> that.
>>
>
>They were not using logical name services to actually trigger their
>shellcode but their DEFCON presentation made it very clear that
>they were using the address space allocated to a specific logical
>to store their shellcode.
>
>When you think about it, that's a clever way to allow code injected
>into an address space to survive activation of a privileged image
>and to become part of the address space of that privileged image.

That's where we differ.  Yes, they did store their code in the memory that is
the tranlation of the logical name.  They didn't show an understanding of how
one would locate that memory once the code was written there.  Their methods
were empirical and kludgy.

My demo used a pseudo-terminal to fill the buffer of the INSTALL image with
511 characters and then the "up-arrows" which trigger the execution of the
so-called shell code.  I stored my shell code using LIB$PUT_COMMON which has 
a well-known location in P1.  That address is written by the pseudo-terminal
code as well.



>One way to stop that as an attack vector is to make sure that the
>memory pages allocated to the logical name tables are marked as
>no-execute. I don't know where you stored the shellcode in your
>version, but I also hope that those memory pages are now no-execute
>in VMS as well.
>
>And yes, given the clear lack of knowledge they showed in some areas
>in their presentation I can easily believe that their code was not up
>to the same standards as an experienced VMS person, but PoC code is
>just that, a proof of concept.
>
>I also picked up on some other things they said such as using binutils
>compiled for an Alpha target to generate their shellcode. That's easily
>something I could have seen even myself doing as well, given that
>I know the GNU toolchain but not the Alpha assembler, especially
>when you are generating a small bit of standalone shellcode.

Given the clear lack of knowledge they showed...
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.