[12646] in bugtraq
Re: hard-coded windows exploits
daemon@ATHENA.MIT.EDU (Simple Nomad)
Thu Nov 18 12:44:31 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.3.96.991117220319.93F-100000@vortex.nmrc.org>
Date: Wed, 17 Nov 1999 22:46:36 -0600
Reply-To: Simple Nomad <thegnome@NMRC.ORG>
From: Simple Nomad <thegnome@NMRC.ORG>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
> > Just a general note concerning Windows overflows - most (if not all) of the
> > publicly available exploits I have seen floating around are still using
> > hard-coded addresses for system calls.
> >
> > Is this the only way to do this? Note that this method has been around for a
> > while, but I haven't seen any public releases of it. If anyone knows of any
> > other ways....
>
> I don't think that this is the only way to do it, what about
> using direct
> system calls? you don't need addresses for that, just call INT 2e/2c/2b
> with the
> correct registers...
>
> I can add to this, that it may be a little harder to do, but
> anyway,
> kernel32.dll calls INTs or calls ntdll.dll that uses INT 2e/2c/2b to
> talk with NT's kernel, so everithing looks like possible with INTs.
Ah but often it is the *timing* of the direct system call that counts.
Invoking a call to adjust (or capture) needed register values followed by
an INT is one aspect of this. Internal race conditions between system
calls are another. I've worked long and hard trying to do remote buffer
overflows in Netware for example, and while it can be done due to the
nature of how memory is used and NLMs are "registered" with the OS during
the load, it dictates direct addressing. But then you end up with an
exploit that works with a specific configuration, such as 64MB ram with
only these drivers and specific version of NLMs loaded in a certain
order, etc.
Actually I'd prefer the "viral" approach in these situations. Exploit code
that does more than simply overwrite areas of memory and/or pokes in
values to registers. Exploit code that becomes a part of the operating
environment "legally", and then exploits conditions within that area.
Dildog's KnownDLL hack from February of this year is a good example of
this, as it is based upon how things actually work vs. how things are
*supposed* or *should* work.
Ideally your kernel has some smarts about it, and compartmentalizes itself
to prevent processes from accessing various sections without permission.
But since most OSes have monolithic operating environments....
Simple Nomad //
thegnome@nmrc.org // ....no rest for the Wicca'd....
www.nmrc.org //
