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

[VAXman- at SendSpamHere.ORG]

In article <o1jurj$mjd$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 <o1i312$vle$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>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.
>>
>
>Yes, that's a much better approach.
>
>I hope that sometime over the last 8 years a patch has now made the
>memory area containing that buffer (as well as the logical name table
>memory) no-execute...

<ROLLEYES>


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

I speak to machines with the voice of humanity.