[Info-vax] DCL vulnerability write up on The Register

Simon Clubley clubley at remove_me.eisner.decus.org-Earth.UFP
Sun Feb 18 09:18:55 EST 2018


On 2018-02-18, Richard Maher <maher_rjSPAMLESS at hotmail.com> wrote:
>
> All good thanks for explaining. The bit I'm interested in is how you get 
> to EXEC/KRNL from SUPER but more importantly how do you get DCL to 
> execute code at the COMMON address.
>

The first bit will be explained at the beginning of March.

The second bit is already public knowledge because I released it
before I knew how bad the first bit is.

The second bit is a due to a combined screwup in CDU and DCL that
has survived since the mid 1980s.

Basically, for the second bit, CDU does not properly validate the
length of a prompt string in a DEFINE VERB definition. This allows an
oversized prompt string to be written to the DCL tables and causes
DCL to overflow a fixed sized buffer when it displays the prompt
string.

If you get the length of the prompt string just right and put the
address of your shellcode at just at the right place in the prompt
string, then hitting Return in response to the prompt will cause DCL
to jump to your shellcode.

This assumes you have previously loaded your shellcode into one of the
user writable memory areas in process space.

So basically, when you combine the two bits together, a bug in the CDU
parser, combined with a lack of proper checking in DCL, has basically
allowed any interactive user with shell access to totally compromise
a VAX or Alpha system since the mid 1980s.

IMHO, things simply should not be that fragile.

> My contention/hope is that this is a bug that can be plugged rather than 
> a fundamental unpluggable attack vector due to dicky memory page protection?

VSI are working on a redesign of the part of VMS that allows you
to compromise the system from supervisor mode. That will take care
of DCL.

The related problem is that non-privileged users should not be able
to load data into persistant memory areas in the process address space
that can then later be executed. Marking these areas as non-executable
will make it harder to compromise a privileged program.

Simon.

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



More information about the Info-vax mailing list