Re: DEFCON 16 and Hacking OpenVMS

On Aug 15, 3:35 pm, "R.A.Omond" <Roy.Om...@xxxxxxxxxxxxxxxxx> wrote:
samp...@xxxxxxxxx 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.
.

Relevant Pages

  • Re: Alpha remembrance day
    ... DEC's disk drive business, they were starting to catch on, but since ... to integrate a TCP/IP stack into on OS? ... UNIX Server/Workstation. ... IBM courted him for a long while ...
    (comp.os.vms)
  • Re: Signs of Maccie desperation!
    ... they cannot be implemented in UNIX? ... Network mapping magically detects what your ... Same with the new stack. ... interface, and a ton load of new technologies in the file system, kernel, ...
    (comp.sys.mac.advocacy)
  • Re: Scheme Virtual Machine
    ... Minimal c/c++ made core for the executable file everything else in the ... I had a similar idea in mind when writing my Implementation of scheme ... The VM uses a stack to pass arguments. ... executes an if operation with a 'then' and an 'else' branch. ...
    (comp.lang.scheme)
  • Re: automatic vs allocated attempts
    ... allocations of allocated storage will never fail, ... malloc can potentially give you access to the full memory resources ... whereas stack space is ``artificially'' limited. ...
    (comp.lang.c)
  • Re: How can I detect a carriage return using java.net
    ... The stack used by DEC Unix on the alphaserver did the same - and that was a Mach based implementation. ... If you got an error you can report it, but this doesn't affect the logic unless it was EAGAIN or EINTR, which both indicate that the recv() returned without reading any valid data but the connection is still intact. ...
    (comp.lang.java.programmer)