Re: Buffer overflows on Netware 4x and 5x

[thegnome () NMRC ORG (Simple Nomad)]

> So my question is this: are there any know buffer overflow exploits/possibilities
> on Netware boxes? Netware is capable of running more than just file and print
> services. In our environment we run almost everything on them.
> Is the Netware architecture vulnerable to buffer overflow attacks? Just like in
> NT and Unix there is a console that can be compromised. Netware also supports
> the XCONSOLE.NLM (telnet daemon) which makes itself a potential hacking
> target.
> Does anyone know if any such exploits exist on Netware? I have never seen them
> but that doesn't mean they aren't there. Is it possible?

Netware has a really odd architecture in memory. As each driver and NLM is
loaded, it is "registered" with the kernel who hands out memory allocation
and then notes where in memory each item is loaded. The advantage is that
say for LIBC.NLM my new NLM I've written can simply call the various
subroutines with LIBC.NLM without knowing where they are located.

Since I can only do this from within routines that are registered with the
kernel, it is possible to overflow and then jump to another location.
However you are constrained by a couple of factors. First, depending on
where you are overflowing, you may not have very much room to work with,
so you usually have to get done what you are doing within just a few
bytes. Second, I was unable to come up with a method for remotely
determining the start of the table that told where everything was -- which
means that you had to hard-code in the first jump address (minimally) and
hope you got it right. You see, the location of that jump area is after
the drivers, so depending on what kind of drivers you are loading, the
location could vary. In fact, loading the drivers in a different order
could throw things off.

I was able to get *some* overflow stuff to happen, but it was very
primitive and was completely dependent on knowing *exactly* where that
table started.

Next caveat - this applies to 4.x, they changed things and started
disallowing one NLM to arbitrarily access another NLM's memory area in
5.x, as an obvious attempt to help stablize the environment.

On the plus side, Netware comes with a built in debugger, which apart from
the fact you can't disassemble to a file you *can* disassemble anything in
RAM, which is a lot of fun to play with if you know assembler. Eventually
I plan to look back into this for Netware 5. In anyone comes up with
anything else in this area, let me know.

-         Simple Nomad          -  No rest for the Wicca'd  -
-      thegnome () nmrc org        -        www.nmrc.org       -
-  thegnome () razor bindview com  -     razor.bindview.com    -